Author dstufft
Recipients Arfrever, alex, benjamin.peterson, christian.heimes, dstufft, ezio.melotti, lemburg, ncoghlan, pitrou, r.david.murray, vstinner
Date 2014-03-21.13:09:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1395407371.51.0.359585676169.issue20995@psf.upfronthosting.co.za>
In-reply-to
Content
> It shows the effect of the additional !DSS - which I don't understand;
> DSA is part of the X.509 standard, so it's removing support will break
> compatibility. Could you perhaps explain you're reasoning ?

Well DSA has problems with weak RNGs and consequently no CA that I'm aware of
will even issue a DSS cert and I've never seen nor heard of anyone actually
using them in practice. If it makes you feel better I can add DSS back in.

> It also shows that by removing DEFAULT, you are not allowing other
> ciphers.

> PSK and SRP are not likely to be used by web servers. SEED doesn't appear
> to have wide spread use either, so leaving it out probably won't matter.
> Leaving those in doesn't hurt either.

I'm pretty sure you can't even use PSK or SRP using the stdlib ssl module, I
didn't explicitly exclude them though. It's just a side effect of specifying
ECDH, DH, and RSA explicitly.

> So modulo the DSS question I see your point about compatibility :-)

I've uploaded a new patch that removes the !DSS from the default ciphers.

Here's the diff from the original default string (with the added !MD5) and
my new patch's default string

> DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
> DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
> IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
> PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
> PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
> PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
> PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
> SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
> SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
> SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(128)  Mac=SHA1
> SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(256)  Mac=SHA1
> SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
> SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
> SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1

> Still, OpenSSL might add more ciphers or modes in the future
> and you'd automatically get those by using DEFAULT in the cipher
> string, so I'd opt for just adding !MD5 to the default cipher list,
> i.e.

> DEFAULT:!aNULL:!eNULL:!MD5:!LOW:!EXPORT:!SSLv2

> With such a string, both servers and client get good compatibility,
> while keeping Python users reasonably safe per default and
> keeping the maintenance burden out of Python.

The (newly uploaded) cipher string is still better because it includes a
priority that is import. It prioritizes:

PFS > Non PFS but Secure > Non PFS Secure Slow > Security Problematic but for Compatibility

This is important especially in the modern age of bulk data collection. It will
still pick up new HIGH ciphers added by OpenSSL without any changes made to
Python itself. This is better than a blacklist approach because it'd be easy
for OpenSSL to add something else bad to DEFAULT that didn't get caught by
!aNULL:!eNULL:!MD5:!LOW:!EXPORT:!SSLv2.
History
Date User Action Args
2014-03-21 13:09:31dstufftsetrecipients: + dstufft, lemburg, ncoghlan, pitrou, vstinner, christian.heimes, benjamin.peterson, ezio.melotti, Arfrever, alex, r.david.murray
2014-03-21 13:09:31dstufftsetmessageid: <1395407371.51.0.359585676169.issue20995@psf.upfronthosting.co.za>
2014-03-21 13:09:31dstufftlinkissue20995 messages
2014-03-21 13:09:31dstufftcreate