Bug 1025627

Summary: Recent versions can't connect to SSL SMTP server
Product: [Fedora] Fedora Reporter: Joshua Baker-LePain <joshua.bakerlepain>
Component: opensslAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-06 22:37:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Connection attempt using 1.0.1e-30
none
Successful connection using 1.0.1c-7 none

Description Joshua Baker-LePain 2013-11-01 06:23:56 UTC
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.

Comment 1 Joshua Baker-LePain 2013-11-01 06:26:26 UTC
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

Comment 2 Tomas Mraz 2013-11-01 08:50:34 UTC
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.

Comment 3 Joshua Baker-LePain 2013-11-01 17:23:27 UTC
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?

Comment 4 Joshua Baker-LePain 2013-11-06 22:37:02 UTC
I've taken this up with the server folks, who are in touch with the vendor.  Closing.