Bug 1126360 - Patch to disable SSLv2 / SSLv3 breaks sendmail / dovecot client connections
Summary: Patch to disable SSLv2 / SSLv3 breaks sendmail / dovecot client connections
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-04 09:27 UTC by AMM
Modified: 2014-08-11 07:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-11 07:48:15 UTC


Attachments (Terms of Use)

Description AMM 2014-08-04 09:27:57 UTC
Description of problem:

This patch here breaks connection from some clients to dovecot OR sendmail.

http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=646646611547dd7072b0562ed5f27861fbb12f48

After I implemented above patch, my 2-3 customers complained about not able to connect to server (Outlook gives error that server does not support encryption method). So had to reverse it.


Version-Release number of selected component (if applicable):
1.0.1h-6


How reproducible:
Always


Steps to Reproduce:
1. Install openssl-1.0.1h version
2. Restart sendmail and dovecot
3. openssl s_client -ssl3 -connect xxx.yyy.com:995
4. openssl s_client -ssl3 -connect xxx.yyy.com:25 -starttls smtp
5. Connection fails with handshake failure
6. Works if -ssl3 argument is removed from above

Actual results:
Results are as expected but see below.

Additional info:
Results are as expected but question is - is the patch really required?
Why not allow the calling program to decide if SSLv2 or SSLv3 should be disabled or not.

Disabling SSLv2 is probably ok but atleast SSLv3 should not be disabled by default.

Thank you.

Comment 1 Tomas Mraz 2014-08-04 10:36:31 UTC
The question is why these clients still require to use SSLv3 which is insecure.

Comment 2 AMM 2014-08-04 14:54:53 UTC
From security point of view you are 100% right. I completely agree.

That is the reason I applied your patch thinking lets deny SSLv3 and lower.

But later I realized that I can not simply keep debugging on customer end. People are simply too lazy or too busy!

So ultimately I had to undo the patch.

Plus SSLv3 is still widely use. I have feeling that once this is put to public its going to create issues.

And its not that this can not be achieved without above patch. Those who want to force only TLS can always add SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 in their config files.

Most server softwares now allow to specify SSL options in config file. Its better to put it in config files instead of hardcoding in library.

Comment 3 Tomas Mraz 2014-08-04 16:22:18 UTC
I mostly agree with you and especially in regards to SSLv3. I will probably undo the SSLv3 part of the patch. SSLv2 is a different beast though. I would even like to disable the SSLv2 support altogether as it just gives false impression of security but that would break ABI compatibility of the library.

Comment 4 Tomas Mraz 2014-08-11 07:48:15 UTC
For now I dropped the disablement of SSLv3.


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