Bug 537962 - openssl-1.0.0-0.12.beta4 clients do not interoperate with deployed servers
Summary: openssl-1.0.0-0.12.beta4 clients do not interoperate with deployed servers
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
: 538373 538456 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2009-11-17 00:00 UTC by Rex Dieter
Modified: 2009-11-20 05:22 UTC (History)
10 users (show)

Fixed In Version: 1.0.0-0.13.beta4.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-20 05:22:41 UTC

Attachments (Terms of Use)

Description Rex Dieter 2009-11-17 00:00:01 UTC
After installing

alpine no longer connects to my ssl'd imap server, reports

There was an SSL/TLS failure for the server ...
The reason for the failure was:  SSL negotiation failed

Server is a centos5 box, running uw-imap.

Comment 1 Rex Dieter 2009-11-17 00:06:36 UTC
rebuilding against the newer openssl-devel doesn't help either.

Bouncing to openssl for comment/feedback.

Comment 2 Rex Dieter 2009-11-17 00:11:19 UTC
In particular, I was using a cert signed by an in-house CA, so was using alpine's /novalidate-cert option:

Comment 3 Rex Dieter 2009-11-17 00:37:32 UTC
added CA to /etc/pki/tls/certs/ca-bundle.crt and dropped /no-validate, no change.

Reverted to openssl-1.0.0-0.10.beta3.fc12.x86_64 and it works again.

Comment 4 Andreas Bierfert 2009-11-17 14:57:01 UTC
Same problem with psi-0.13-1.fc12.x86_64

Comment 5 Tomas Mraz 2009-11-17 21:58:06 UTC
This is most probably caused by a fix for CVE-2009-3555. The failing clients most probably do not use SSL_OP_ALL flags to allow compatibility with buggy SSL/TLS servers. One of the flags included in the SSL_OP_ALL flags disables the extension which allows safe renegotiation.

The possible fixes are:


- change openssl so it allows servers not supporting the safe renegotiation extension even when the flag is not passed by the application

I'm inclined to the second possibility for now as the current default breaks too many things.

Tomas Hoger, what do you think about it?

Comment 6 Tomas Hoger 2009-11-18 07:48:50 UTC
1.0.0 beta4 does enforce reneg extension on the client side expecting it to be in each TLS1 server hello and failing if it does not.  As pointed out in the proposed reneg RFC, this has significant interoperability issues (section 4.1).

So while this bug mentions alpine and psi, similar problem is likely to exist for any client connecting to the server not supporting reneg extension (which currently means almost all servers).

IMO, current 'fail if no reneg extension in server hello' is not likely to be a viable default for clients for quite some time.  Before the extension is supported by the majority of servers, it may drive people to using SSL3 if that is configurable in the app.

Comment 7 Tomas Mraz 2009-11-18 12:41:11 UTC
*** Bug 538373 has been marked as a duplicate of this bug. ***

Comment 8 Fedora Update System 2009-11-18 14:42:16 UTC
openssl-1.0.0-0.13.beta4.fc12 has been submitted as an update for Fedora 12.

Comment 9 Tomas Mraz 2009-11-18 16:18:23 UTC
*** Bug 538456 has been marked as a duplicate of this bug. ***

Comment 10 Rex Dieter 2009-11-18 17:08:33 UTC
tested openssl-1.0.0-0.13.beta4.fc12 , works like a charm again with alpine.

Comment 11 Andreas Bierfert 2009-11-18 18:35:11 UTC
openssl-1.0.0-0.13.beta4.fc12 works fine with psi as well.

Comment 12 Jeffrey C. Ollie 2009-11-18 21:24:15 UTC
OpenVPN and exim are working again for me with openssl-1.0.0-0.13.beta4.fc12.

Comment 13 Fedora Update System 2009-11-20 05:22:31 UTC
openssl-1.0.0-0.13.beta4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.