Created attachment 818143 [details] Connection attempt using 1.0.1e-30 Description of problem: Recently I became unable to send mail from my Fedora 18 system through a remote SMTP server over SSL. My MUA (alpine) fails (without ever asking for a password) with the message "SSL negotiation failed". I tracked this down to the openssl update to 1.0.1e-28. The problem persists with 1.0.1e-30. I was able to confirm the issue using the 'openssl' command. Version-Release number of selected component (if applicable): 1.0.1e-28 and 1.0.1e-30 How reproducible: Every time Steps to Reproduce: 1. openssl s_client -connect smtp.duke.edu:465 -debug Actual results: No connection Expected results: Connection Additional info: I've attached the (rather brief) output of the above command using openssl-1.0.1e-30.
Created attachment 818144 [details] Successful connection using 1.0.1c-7 Attached is the output of a successful connection using openssl-1.0.1c-7
This really looks like some bug on the server side. The -28 version was incorrect because the client advertised EC curves that it did not really support to the server. However -30 is fixed in this regard and the fix was verified that it works. Given the strange non-response from the server I really think it somehow mishandles the situation when the ECC support is advertised by the client at all.
I can confirm that the server responds correctly to openssl-1.0.1e-4.fc18, but not openssl-1.0.1e-4.fc18.1 (or any versions since). So it looks like the above is correct. Is there any further testing I could do, or should I just close this NOTABUG and take this up with the server folks?
I've taken this up with the server folks, who are in touch with the vendor. Closing.