homepage

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 .

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 issue13627, we could call set_ciphers("HIGH") by default. This excludes legacy ciphers (such as RC4, DES) without having us maintain an explicit list.

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" .

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.

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

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?

> - 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?

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

> 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.

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"?

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 

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).

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

> MD5 has been disabled for SSL use due to it's weakness by:
Apparently MD5 is already disabled by "HIGH:!SSLv2".

> 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.
However, this will also divide performance by a large factor (from 2x to
4x apparently).
> Maybe also DH/EDH stuff can be done "in memory"?
Yes, there are also APIs for that, but you still have to provide magic
numbers (or have Python provide them).

I confirm, tested "HIGH:!SSLv2" and MD5 cannot be negotiated.

> About ECDHE use as a default, prioritized key exchange method, google
> is using it along with RC4:
Hmmm... do note that RC4 is disabled with "HIGH".

I think we should relax the constraints a bit (RC4 seems ok for TLS/SSL use (*)) and therefore suggest we settle on "DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2".
(OpenSSL's default is "DEFAULT:!aNULL:!eNULL", so we're really disabling weak ciphers)
(*) Wikipedia even notes: "RC4, being a stream cipher, is the only common cipher which is immune[7] to the 2011 BEAST attack on TLS 1.0, which exploits a known weakness in the way cipher block chaining mode is used with all of the other ciphers supported by TLS 1.0, which are all block ciphers"

Well, if you do:
"DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2" ciphers enabled are
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
If we want to start from the "DEFAULT" than we should probably disable:
- PSK
- CAMELLIA
- MD5
- IDEA
- SEED
That way:
openssl ciphers -v 'DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2:!PSK:!CAMELLIA:!MD5:!IDEA!SEED'
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
What do you think?

> If we want to start from the "DEFAULT" than we should probably disable:
> - PSK
> - CAMELLIA
> - MD5
> - IDEA
> - SEED
Why do you want to disable all these?

Well,
with your latest proposal 'HIGH:!aNULL:!eNULL:!SSLv2' :
- MD5 was disabled
- IDEA was disabled
- SEED was disabled
Then we realized that RC4 could be a cipher to be leaved enabled, so the new proposal starting from 'DEFAULT'.
While i don't like RC4 because it's not FIPS-140 compliant (https://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html) i understand that we may want to keep it.
I would suggest by default to keep disabled also CAMELIA and PSK because almost no one use it, they are just into the standard like many ciphers.
Generally speaking, as a concept to define a default we could:
- Start from a FIPS-140 compliant SSL stack
- Open some additional ciphers for compatibility reason (for example RC4-SHA)
What do you think about such approach?
-naif

Why make this decision ourselves at all? Copy what Mozilla and Chromium do
by default.

> Why make this decision ourselves at all? Copy what Mozilla and Chromium do
> by default.
If that translates to an explicit list of ciphers it will be a pain to
maintain. Using a generic OpenSSL string such as "DEFAULT:!LOW:[etc.]"
means OpenSSL mostly does the maintenance for us.

> with your latest proposal 'HIGH:!aNULL:!eNULL:!SSLv2' :
> - MD5 was disabled
> - IDEA was disabled
> - SEED was disabled
That was the consequence of it, but that wasn't an explicit goal.
> Generally speaking, as a concept to define a default we could:
> - Start from a FIPS-140 compliant SSL stack
> - Open some additional ciphers for compatibility reason (for example
> RC4-SHA)
> 
> What do you think about such approach?
As I already said, the more sophisticated the approach, the more tedious
the maintenance.

Well, my concept is that it would be reasonable to use what people consider secure.
SSL/TLS are security protocol.
Some combination of the protocol configuration (ciphers/hash/key exchange) are:
- known to be insecure
- known to be secure
- known to be unused (like SEED, only used in South Korea by military applications) or PSK with almost no adoption
- Unknown (like CAMELIA, i don't find a single software using it)
The concept i would propose is to choose the ciphers that "known to be secure" by disabling everything else.

> The concept i would propose is to choose the ciphers that "known to be
> secure" by disabling everything else.
I hate repeating myself, but who will maintain it?

> By default the Python SSL/TLS Stack (client/server) expose
> unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).
If there is a problem, it should not be fixed in Python, but in the underlying library (OpenSSL) or in applications. Python only exposes features of the OpenSSL library. You should not see Python as an application but as a language: Python doesn't know what is your use case, or if you write a client or a server.
I suppose that OpenSSL has good reasons to still support weak algorithms like MD4 or SSLv2. Some operating systems, like Debian Sid, disable SSLv2 in the OpenSSL at the compilation.
If you consider that it is too complex to change the cipher list in a high level API (like http.client?), we may a ssl.DEFAULT_CIPHERS to allow an application to change the *default* cipher list.
SSLContext() requires a protocol, I suppose that the protocol is also by OpenSSL used in the negociation of the cipher list.
If we change the default behaviour, we should allow the user to get back the old behaviour (e.g. mark ssl._DEFAULT_CIPHERS as public in default_ciphers.patch).
--
IMO this issue is more a documentation issue: we should add a warning in the ssl module documentation, and maybe also in the documentation of modules using the ssl module (as we done for certificates for HTTPS).

> > By default the Python SSL/TLS Stack (client/server) expose
> > unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).
> 
> If there is a problem, it should not be fixed in Python, but in the
> underlying library (OpenSSL) or in applications. Python only exposes
> features of the OpenSSL library.
The ssl module's theoretical goal is to provide access to SSL features;
that it wraps OpenSSL APIs is mostly an implementation detail, although
it is true that the APIs resemble OpenSSL's in some places.
This is where we can have different policies: OpenSSL is a low-level
library with an exhaustive (if poorly documented) API; the ssl module is
more synthetic and slightly higher-level, and likely to be used by
crypto novices. As such, we can have a different set of default ciphers.
> You should not see Python as an application but as a language: Python
> doesn't know what is your use case, or if you write a client or a
> server.
This is why I would like to stay conservative when disabling ciphers:
disable the really weak ones, but avoid being too opinionated.
> If you consider that it is too complex to change the cipher list in a
> high level API (like http.client?), we may a ssl.DEFAULT_CIPHERS to
> allow an application to change the *default* cipher list.
Changing higher-level APIs means there are more places where the change
has to be done.
> SSLContext() requires a protocol, I suppose that the protocol is also
> by OpenSSL used in the negociation of the cipher list.
There are weak ciphers even in TLS1.
> If we change the default behaviour, we should allow the user to get
> back the old behaviour (e.g. mark ssl._DEFAULT_CIPHERS as public in
> default_ciphers.patch).
set_ciphers("something") is how you change ciphers. It is a public API.
But I wouldn't expect anyone to re-enable 56-bit DES ciphers: if we are
conservative with our choice of default ciphers, nobody should have
issues with it.
> IMO this issue is more a documentation issue: we should add a warning
> in the ssl module documentation, and maybe also in the documentation
> of modules using the ssl module (as we done for certificates for
> HTTPS).
Most ssl-using modules won't give the user access to such settings.
Besides, you can't expect someone using urllib.request() to know which
ciphers should be disabled. The library (either ssl or urllib or
http.client) should choose the right defaults.
I agree about documenting it in any case. But that doesn't mean we
shouldn't *also* set a reasonable default.

For the record, here are the default ciphers in our Windows OpenSSL build:
Z:\openssl-1.0.0a>out64\openssl.exe ciphers -v
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1
EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1
DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export
EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export

Regarding the mainteneance i expect that, if we make a future-proof choice, it would take at least 5 years before that someone will need to have other ciphers added.
Consider that a new cipher is standardized once every X year, and typically, if it get diffused/adopted (and not abbandoned or marginally used), it will happen in few other years.
The new ciphers will get into OpenSSL, so the proposed approach to:
- Start from default
- Disable anything that's
 - Unsecure/Weak
 - Not used/widely used
Would still means that, when OpenSSL library will add a new cipher because a new RFC will get out, for sure it will not be unsecure/weak. There are chance that it will not get used/widely used, in that case in some other year, we'll update the default disabled ciphers.
But such approach would provide very "low maintenance" because "not doing anything" can only create a situation where "more ciphers" get added by default (included in newer OpenSSL / new TLS RFC).
But those new ciphers will not be weak, even if not maintained.

New changeset 25c2d24e1b11 by Antoine Pitrou in branch '3.2':
Issue #13636: Weak ciphers are now disabled by default in the ssl module
http://hg.python.org/cpython/rev/25c2d24e1b11
New changeset ace54f5e75d7 by Antoine Pitrou in branch 'default':
Issue #13636: Weak ciphers are now disabled by default in the ssl module
http://hg.python.org/cpython/rev/ace54f5e75d7 

New changeset f9122975fd80 by Antoine Pitrou in branch '2.7':
Issue #13636: Weak ciphers are now disabled by default in the ssl module
http://hg.python.org/cpython/rev/f9122975fd80 

I've committed a conservative version of the patch, plus a test.