Bug 1126360

Summary:	Patch to disable SSLv2 / SSLv3 breaks sendmail / dovecot client connections
Product:	[Fedora] Fedora	Reporter:	AMM <anon.amish>
Component:	openssl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	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:	2014-08-11 07:48:15 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:
Embargoed:

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.