Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

BPO	13636
Nosy	@gpshead, @jcea, @pitrou, @vstinner
Files	default_ciphers.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-01-04.01:31:56.181>
created_at = <Date 2011-12-19.11:00:07.422>
labels = ['type-security', 'library']
title = "Python SSL Stack doesn't have a Secure Default set of ciphers"
updated_at = <Date 2012-01-04.01:31:56.180>
user = 'https://bugs.python.org/naif'

bugs.python.org fields:

activity = <Date 2012-01-04.01:31:56.180>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2012-01-04.01:31:56.181>
closer = 'pitrou'
components = ['Library (Lib)']
creation = <Date 2011-12-19.11:00:07.422>
creator = 'naif'
dependencies = []
files = ['24051']
hgrepos = []
issue_num = 13636
keywords = ['patch']
message_count = 33.0
messages = ['149839', '149842', '149844', '149845', '149846', '149847', '149849', '149853', '149856', '149857', '149858', '149859', '149860', '149861', '149862', '149863', '149866', '149977', '150008', '150009', '150015', '150018', '150020', '150021', '150023', '150025', '150034', '150076', '150081', '150086', '150539', '150540', '150566']
nosy_count = 6.0
nosy_names = ['gregory.p.smith', 'jcea', 'pitrou', 'vstinner', 'python-dev', 'naif']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue13636'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

[naif]

By default the Python SSL/TLS Stack (client/server) expose unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).

This ticket is about defining a set of secure ciphers that should also provide maximum performance and compatibility, in order to allow any Python coder to use a Secure SSL/TLS stack without the need to became a Crypto Experts.

The discussion come from ticket http://bugs.python.org/issue13627 .

The proposal is to involve a discussion from the Tor Project (mailing list Tor-Talk & Tor-Dev) to define rationally a default set of ciphers/protocol for Python SSL/TLS from the Cryptography point of view .

[pitrou]

As I said, I don't think maintaining an explicit list of ciphers ourselves is reasonable, since there are no crypto experts (AFAICT) amongst the Python core developers.

Also, maintaining an explicit list of ciphers means people wouldn't benefit automatically from new ciphers unless Python itself is modified.

However, as I've proposed on bpo-13627, we could call set_ciphers("HIGH") by default. This excludes legacy ciphers (such as RC4, DES) without having us maintain an explicit list.

[naif]

From Antoine Pitrou (pitrou):

Why don't you simple define your own default ciphers and call the
set_ciphers() method?
That said, we could perhaps call set_ciphers("HIGH") by default. This
excludes legacy ciphers (such as RC4, DES) without having us maintain an
explicit list.

I would suggest to follow a future proof approach that would consider:

• Disable SSLv2 (no one support it anymore)

• Enable Elliptic Curve Crypto and provide it as a priority (maximum security with strong performance gain)

• Enable Perfect Forward Secrecy ciphers first (DH ephemeral DHE)

• Provide an ordered cipher list for TLSv1

• First ECC/DHE ciphers (Future Proof, PFS, with maximum performance)
• Second DHE ciphers (Non-future proof, PFS, less performance)
• Third TLSv1 AES ciphers (AES-128/AES-256, max compatibility, max performance)

• Then provide an ordered cipher list for SSLv3 (No AES support)

• First 3DES DHE ciphers (PFS security)
  SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA

• Second 3DES non-DHE cipher
  SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA

• Third RC4 based encryption
  SSL_RSA_WITH_RC4_128_SHA

That way (but this is an approach to be discussed) we will pick-up a set of widely secure ciphers, high performance ciphers, highly compatible ciphers, but with a selection logic that's optimized for existing set of application and servers.

Or eventually hide that complexity for the Python developers by providing a set of "pre-configured" profiles to be used?

I always find ppl having difficulties in dealing with SSL/TLS, as a result SSL/TLS configuration it's often "by default" .

[pitrou]

Actually, it seems we want 'HIGH:!aNULL:!eNULL' to avoid non-encrypted and non-authenticated ciphers.

That way (but this is an approach to be discussed) we will pick-up
a set of widely secure ciphers

Please read my message above and understand this faces us with a number of maintenance problems which can actually *decrease* security.

[pitrou]

Here is a possible patch for 3.2.
Probably needs a doc addition as well.

[naif]

Ok for:
'HIGH:!aNULL:!eNULL'

but also:

• Disable SSLv2
• Enable ECC/ECDHE by default
• Enable DH/DHE by default

With this in place, i would then suggest to see which is the "Default ordered list of ciphers" with an SSL cipher scanner/wireshark.

Then we would be able to know if the "default order" for the ciphers is reasonable or if we would need to manually organize it to have a preferred selection that consider security and performance, while keeping always compatibility.

What do you think of an approach like this?

[pitrou]

• Disable SSLv2

It should be disabled automatically since the SSLv2 cipher suites are not part of "HIGH": see http://www.openssl.org/docs/apps/ciphers.html#SSL_v2_0_cipher_suites_

• Enable ECC/ECDHE by default
• Enable DH/DHE by default

These both require parameters. I think adding simple instructions in the documentation would go a long way towards helping users. It would also probably be more instructive than silently choosing default values.

(after all, for ECDHE it's a one-line addition; DHE needs a separate file so it's less immediate)

With this in place, i would then suggest to see which is the "Default
ordered list of ciphers" with an SSL cipher scanner/wireshark.

I'm not really able to do that. Perhaps you can help?

[naif]

To disable SSLv2 you must specifically disable it.

Look, i tried a server we're working on http://github.com/hellais/tor2web that's running on:

privacyresearch.infosecurity.ch port 8888

With 'HIGH:!aNULL:!eNULL' SSLv2 can connect:

openssl s_client -connect privacyresearch.infosecurity.ch:8888 -ssl2

SSLv2, Cipher is DES-CBC3-MD5

So it negotiated SSLv2 with 3DES that's not a good choice, SSLv2 must be disabled.

We must disable SSLv1 with !SSLv2, for example i am using just now 'HIGH:!aNULL:!eNULL:!SSLv2:@strength' .

Trying to connect with SSLv2 fail:
openssl s_client -connect privacyresearch.infosecurity.ch:8888 -ssl2
140735092141340:error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list:s2_clnt.c:450:

Trying to connect by default, it select a strong cipher (i still didn't setup the dh/stuff):

openssl s_client -connect privacyresearch.infosecurity.ch:8888

Connect with: TLSv1/SSLv3, Cipher is AES256-SHA

[pitrou]

We must disable SSLv1 with !SSLv2, for example i am using just now
'HIGH:!aNULL:!eNULL:!SSLv2:@strength' .

Ok, thanks for the investigation. I think "HIGH:!aNULL:!eNULL:!SSLv2" is
sufficient.

[naif]

Yes, i can do the test for the ordered set of ciphers with all the patches in-place, can build a custom python 3.2 with the patch applied.

I would suggest to try to keep ECC/ECDH/ECDHE enabled, conceptually we would like to have ECDHE as the first ciphers because it's the most modern, performance and secure.

For DH, you say that it require some file, but looking at mod_ssl Changelog it say:
The reason was that mod_ssl's temporary RSA keys and DH parameters
were stored in the persistent memory pool directly as OpenSSL's
RSA and DH structures.

I mean, when i install Apache with SSL, from the system administrator point of view, i never have to create a file somewhere in order to have that ciphers.

Maybe also DH/EDH stuff can be done "in memory"?

[naif]

About ECDHE use as a default, prioritized key exchange method, google is using it along with RC4:
http://www.julianevansblog.com/2011/11/https-encryption-increased-for-gmail-and-google.html

[naif]

We could also disable all the ciphers that use MD5 for authentication:

MD5 has been disabled for SSL use due to it's weakness by:

• Firefox (All mozilla products now refuse any MD5 ciphers)
  https://www.thesslstore.com/blog/index.php/firefox-to-stop-supporting-md5-based-ssl/
• Duracon by Jacob Appelbaum (Tor Project)
  https://github.com/ioerror/duraconf

"HIGH:!aNULL:!eNULL:!SSLv2:!MD5" would do the magic, so we update the default to a modern, yet compatible set of SSL ciphers supported.

I don't want in any case to break compatibilities, but by default a software, should not support vulnerable, weak ciphers and this seems a good compromise.

Then the last fine tuning would be have the right preferred orders of ciphers to always prefer ECDHE (if available).

[naif]

It would be also useful to "Sort" the order of ciphers by it's strength.

This is done by the parameter @strength" :

From http://www.openssl.org/docs/apps/ciphers.html

"Additionally the cipher string @strength can be used at any point to sort the current cipher list in order of encryption algorithm key length."

In that case the default cipher string would become:
"HIGH:!aNULL:!eNULL:!SSLv2:!MD5:@strength"

The logic for third party developers could be explained as:

Only =>128bit ciphers
Disable unauthenticated ciphers
Disable SSLv2 protocol
Disable weak MD5 hash as authentication
Sort the cipher preferences by it's strength