[issue13626] Python SSL stack doesn't support DH ciphers

2011-12-18 Thread naif 

New submission from naif :

Python SSL doesn't support DH ciphers in in all version tested.

This is a serious security issue because it's not possible to use as a server 
or client Perfect Forward Secrecy [1] security provided by DHE and ECDH ciphers 
.

In order to enable DH ciphers the SSL implementation the in the file 
Modules/_ssl.c, it must issue a DH_generate_parameters() if a cipher is DH.

For example PHP handling of DH ciphers, look php-5.3.8/ext/openssl/openssl.c : 

#if !defined(NO_DH)
case OPENSSL_KEYTYPE_DH:
{
DH *dhpar = 
DH_generate_parameters(req->priv_key_bits, 2, NULL, NULL);
int codes = 0;

if (dhpar) {
DH_set_method(dhpar, 
DH_get_default_method());
if (DH_check(dhpar, &codes) && 
codes == 0 && DH_generate_key(dhpar)) {
if 
(EVP_PKEY_assign_DH(req->priv_key, dhpar)) {
return_val = 
req->priv_key;
}
} else {
DH_free(dhpar);
}
}
}
break;
#endif
default:


An important security fix, to support and enable by default DH ciphers has to 
be done.

[1] http://en.wikipedia.org/wiki/Perfect_forward_secrecy

--
components: Library (Lib)
messages: 149749
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support DH ciphers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue13626>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

2011-12-18 Thread naif 

New submission from naif :

Python SSL doesn't support Elliptic Curve ciphers in in all version tested.

This is a serious performance issue because it's not possible to use as a 
server or as client the performance improvement provided by ECC based ciphers.
Nowdays ECC are supported by all latests browsers.

ECC provide a strong performance improvements (even x3) also when used with 
Perfect Forward Secrecy enabled ciphers like described on:
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

In order to enable ECC ciphers (and eventually ECC keys) the SSL implementation 
the in the file Modules/_ssl.c must be modified.

For example apache had several modifications to support ECC on their SSL 
(openssl based) stack:
https://issues.apache.org/bugzilla/show_bug.cgi?id=40132
https://build.opensuse.org/package/view_file?file=httpd-ssl-ecc-ecdh.patch&package=apache2&project=home%3Aelvigia%3Atls1.2&rev=2

So Python SSL module should introduce similar modifications to fully support 
Elliptic Curve ciphers for SSL in order to:

- Provide performance improvements
- Provide cryptography security improvements
- Allow writing of applications compliant with NSA Suite-B standard

--
components: Library (Lib)
messages: 149755
nosy: naif
priority: normal
severity: normal
status: open
title: Python  SSL stack doesn't support Elliptic Curve ciphers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

2011-12-18 Thread naif 

naif  added the comment:

Other example for DH and ECC from:
https://github.com/bumptech/stud/blob/master/stud.c

#ifndef OPENSSL_NO_DH
static int init_dh(SSL_CTX *ctx, const char *cert) {
DH *dh;
BIO *bio;

assert(cert);

bio = BIO_new_file(cert, "r");
if (!bio) {
  ERR_print_errors_fp(stderr);
  return -1;
}

dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
BIO_free(bio);
if (!dh) {
ERR("{core} Note: no DH parameters found in %s\n", cert);
return -1;
}

LOG("{core} Using DH parameters from %s\n", cert);
SSL_CTX_set_tmp_dh(ctx, dh);
LOG("{core} DH initialized with %d bit key\n", 8*DH_size(dh));
DH_free(dh);

#ifdef NID_X9_62_prime256v1
EC_KEY *ecdh = NULL;
ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
SSL_CTX_set_tmp_ecdh(ctx,ecdh);
EC_KEY_free(ecdh);
LOG("{core} ECDH Initialized with NIST P-256\n");
#endif

return 0;
}
#endif /* OPENSSL_NO_DH */



#ifndef OPENSSL_NO_DH
init_dh(ctx, OPTIONS.CERT_FILE);
#endif /* OPENSSL_NO_DH */

--

___
Python tracker 
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

2011-12-18 Thread naif 

naif  added the comment:

Other example for DH and ECC from:
https://github.com/bumptech/stud/blob/master/stud.c

#ifndef OPENSSL_NO_DH
static int init_dh(SSL_CTX *ctx, const char *cert) {
DH *dh;
BIO *bio;

assert(cert);

bio = BIO_new_file(cert, "r");
if (!bio) {
  ERR_print_errors_fp(stderr);
  return -1;
}

dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
BIO_free(bio);
if (!dh) {
ERR("{core} Note: no DH parameters found in %s\n", cert);
return -1;
}

LOG("{core} Using DH parameters from %s\n", cert);
SSL_CTX_set_tmp_dh(ctx, dh);
LOG("{core} DH initialized with %d bit key\n", 8*DH_size(dh));
DH_free(dh);

#ifdef NID_X9_62_prime256v1
EC_KEY *ecdh = NULL;
ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
SSL_CTX_set_tmp_ecdh(ctx,ecdh);
EC_KEY_free(ecdh);
LOG("{core} ECDH Initialized with NIST P-256\n");
#endif

return 0;
}
#endif /* OPENSSL_NO_DH */

--

___
Python tracker 
<http://bugs.python.org/issue13626>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

2011-12-18 Thread naif 

naif  added the comment:

Have a look also at DH related ticket: http://bugs.python.org/issue13626

There is a code example on how PHP manage the DH parameter setup with high 
level OpenSSL.

The code must check if the ciphers is EC or DH and in that case setup 
appropriate parameters by generating random data for DH operations.

--

___
Python tracker 
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

2011-12-18 Thread naif 

naif  added the comment:

Please look at how PHP implement the feature.
It doesn't use any PEM or any Key File, but just initiatlize the DH parameters.

Stud instead, ask the user to generate "offline" the DH parameters and save it 
into the PEM file.

I think that the PHP approach it's better than the STUD one:
It does not require any file or key to generate DH parameters.

This is the way to have supported ciphers such as DHE-RSA-AES256-SHA (
http://www.openssl.org/docs/apps/ciphers.html ) that now cannot be used because 
the Python SSL binding doesn't initialize the DH parameters.

--

___
Python tracker 
<http://bugs.python.org/issue13626>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

2011-12-18 Thread naif 

naif  added the comment:

This is how the Stud software enable also the use of ECC in OpenSSL TLS
https://github.com/bumptech/stud/pull/61

--

___
Python tracker 
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

2011-12-19 Thread naif 

naif  added the comment:

So, with this patch it should be possible to strictly enable ciphers such as:
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
ECDH-RSA-AES256-SHASSLv3 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

Which ciphers did you negotiated succesfully?


While with the implementation of http://bugs.python.org/issue13627 (DH/DHE 
ciphers) we should be able to negotiate:
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA (SSLv3)
 TLS_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA (TLSv1)
 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   EDH-DSS-DES-CBC3-SHA (TLSv1)
 TLS_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA (TLSv1)
 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA (TLSv1)
 TLS_DHE_DSS_WITH_AES_128_CBC_SHADHE-DSS-AES128-SHA
 TLS_DHE_DSS_WITH_AES_256_CBC_SHADHE-DSS-AES256-SHA
 TLS_DHE_RSA_WITH_AES_128_CBC_SHADHE-RSA-AES128-SHA
 TLS_DHE_RSA_WITH_AES_256_CBC_SHADHE-RSA-AES256-SHA

Do you expect it would be a difficult step to handle also the DH/DHE (non ECC) 
negotiation?

Additionally it would be imho very important if the Python language would 
provide a "default ciphers setup" that look at maximum compatibility, 
performance and security.

If it sounds fine for you, i would open another ticket to create a default 
cipherlist.

--

___
Python tracker 
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

2011-12-19 Thread naif 

naif  added the comment:

Wow, i saw your patch for ECC SSL ciphers on http://bugs.python.org/issue13627 .

Do you think we can use the same method/concept as ssl.OP_SINGLE_ECDH_USE but 
ssl.OP_SINGLE_DH_USE for DH?

--

___
Python tracker 
<http://bugs.python.org/issue13626>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13634] Python SSL stack doesn't support Compression configuration

2011-12-19 Thread naif 

New submission from naif :

TLSv1 support compression with gzip/deflate that can provide for a lot of 
protocols a great improvement (just think about SIP/TLS or IMAP) in terms of 
bandwidth.

Currenly Python SSL stack based on OpenSSL doesn't allow the configuration 
(enabling/disabling/forcing) of TLS compression.

This ticket is about suggesting to implement TLS compression configuration of 
OpenSSL as described on:
http://blog.dave.cridland.net/?p=73

--
components: Library (Lib)
messages: 149830
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support Compression configuration
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue13634>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

2011-12-19 Thread naif 

New submission from naif :

The list of Ciphers for Python SSL binding for OpenSSL cannot be ordered in a 
specific list of preference.

This is a requirement for strict security environment where the ordered cipher 
list it's very important.

Apache support the ordering of ciphers trough the configuration of 
SSLHonorCipherOrder:
http://www.carbonwind.net/blog/post/Setting-the-preferred-cipher-suite-on-Apache-22x.aspx

Also Internet Explorer 7 support Ciphers order configuration:
https://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx?Redirected=true

Not having the ordered cipher list doesn't allow Python SSL stack configuration 
to be compliant with high security environment, de-facto representing a 
security vulnerability.

We suggest to fix the issue of lacking that feature.

--
components: Library (Lib)
messages: 149831
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support ordering of Ciphers
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue13635>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

2011-12-19 Thread naif 

naif  added the comment:

In the meantime i added two other tickets on security and performance 
improvements of Python SSL support, to make it really complete and comparable 
to Apache/Dovecot/PHP in terms of configuration and capability: 

Python SSL stack doesn't support ordering of Ciphers
http://bugs.python.org/issue13635

Python SSL stack doesn't support Compression configuration
http://bugs.python.org/issue13634

--

___
Python tracker 
<http://bugs.python.org/issue13626>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

2011-12-19 Thread naif 

naif  added the comment:

The Tor Project is composed of Cryptography experts, thus i am opening that 
ticket cause with our group we're implementing Tor2web based on Python that 
require *strict* security requirements for crypto.

The Tor Project heavily use Python for most of tools.

If you want we can open a discussion within Tor Project to have a "rationale 
method" to define a set of "default ciphers" considering the ration of 
security/performance/compatibility.

That way anyone using Python SSL/TLS will be sure in using a "Secure system" 
without the risk of legacy protocol such as SSLv2 or insecure ciphers like 
Export 40bit DES that are nowdays enabled by default.

Today a Python coder approaching SSL/TLS will have an insecurely configured TLS 
connection that can be hijacked via SSLv2 protocol or cracked via 40bit DES. 

Even Firefox, Chrome, IE, Opera disable by default certain protocols and 
certain ciphers, so imho it would be valuable to have a "Secure default", 
obviously considering and maintaining compatibility.

What do you think?

--

___
Python tracker 
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

2011-12-19 Thread naif 

naif  added the comment:

Looking at the code from mod_ssl i would say that this is the preference 
required https://issues.apache.org/bugzilla/show_bug.cgi?id=28665

--

___
Python tracker 
<http://bugs.python.org/issue13635>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

New submission from 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 .

--
components: Library (Lib)
messages: 149839
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL Stack doesn't have a Secure Default set of ciphers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

2011-12-19 Thread naif 

naif  added the comment:

Created a ticket there for a default-setting:

Python SSL Stack doesn't have a Secure Default set of ciphers
http://bugs.python.org/issue13636

--

___
Python tracker 
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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?

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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 

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

openssl s_client -connect  privacyresearch.infosecurity.ch: -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: -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:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-19 Thread naif 

naif  added the comment:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-21 Thread naif 

naif  added the comment:

Well, if you do:
"DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2" ciphers enabled are
ECDHE-RSA-AES256-SHASSLv3 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-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHASSLv3 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-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHASSLv3 Kx=PSK  Au=PSK  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHASSLv3 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-SHASSLv3 Kx=DH   Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHASSLv3 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-SHASSLv3 Kx=RSA  Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(128) Mac=SHA1
IDEA-CBC-SHASSLv3 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-SHASSLv3 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-SHASSLv3 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-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHASSLv3 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-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHASSLv3 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)

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

2011-12-21 Thread naif 

naif  added the comment:

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

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-21 Thread naif 

naif  added the comment:

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.

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2011-12-22 Thread naif 

naif  added the comment:

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.

--

___
Python tracker 
<http://bugs.python.org/issue13636>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13647] Python SSL stack doesn't securely validate certificate (as client)

2011-12-22 Thread naif 

New submission from naif :

It has been noticed by the well known security researcher Dan Kaminsky (
http://dankaminsky.com/) that Python SSL binding doesn't securely validate a 
digital certificate while used.

There is a new 
"match_hostname"http://pypi.python.org/pypi/backports.ssl_match_hostname/ that 
doesn't implement all the required, standard SSL/TLS Client security checks 
that should be done.

Dan suggestion to properly implement implement default SSL/TLS Client security 
check is as follow:

===
Encryption without authentication offers little value; it is the canonical 
"secure in the absence of an attacker" state.  
Python's SSL/TLS code presently does not authenticate the connection by 
default.  

There are of course reasons for this:

1) Collecting and maintaining the appropriate SSL/TLS roots is difficult, 
assuming people are even connecting to globally trusted resources
2) Changing authentication policy silently threatens to break production apps

These are real problems that can't just be waved away.  
In the long run, a more scalable trust distribution system needs to be 
supported (DNSSEC, most likely) but the present state of affairs remain ugly.  

This is what I would recommend:

A) Integrate the Mozilla CA pack into Python, updating it with each security 
release.

B) Make certificate validation tristate.  B
y default, it merely emits to stderr an error similar to what happens if 
deprecated content is included.  
This is vaguely heretical but whatever.  
Then add a couple of API calls:
   a) ValidateCerts, a single call that enables the Mozilla CA pack
   b) AddCert, a single call that declares a particular cert as trusted
   c) AddRoot, a single call that declares a particular root as trusted
   d) DisableValidation, a single call that removes the error
C) Integrate a hooking mechanism to add or replace the certificate validation 
process.  
Please send this API the name of the host you're attempting to validate, and be 
sure to allow it to return "I don't know, try your normal validation procedure".

Be sure you include all the necessary checks, including:
A) Expiration
B) SAN/CN
C) Basic Constraints checking
D) Name Constraints

Possibly a future version of Python should _actually_ deprecate non-validating 
SSL/TLS, but certainly not a security patch.
Too high a risk of breakage.
===

It would be valuable to provide the default SSL/TLS Client verification exactly 
like Mozilla/Chrome/Curl/Wget does.

--
components: Library (Lib)
messages: 150094
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't securely validate certificate (as client)
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue13647>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13655] Python SSL stack doesn't have a default CA Store

2011-12-23 Thread naif 

New submission from naif :

For the certificate store:

Can we eventually agree to bind a default CA-store to a Mozilla verified one?
Mozilla in handling Firefox does a great job in keeping CA-store up-to-date.

Integrating default mozilla CA-store with Python builds could be a nice way, 
it's just a matter of integrating into the build-system the download/fetching 
of default Mozilla store.

At least the language base it's default on a trusted entity to manage, 
cross-platform, the CA-store for TLS/SSL.

The mainteinance of the CA-store would be delegated to Mozilla that has been 
demonstrated to be independent and very security conscious, removing dirty 
CA-store (like Diginotar after Iranian compromise).

That way 90% of case of of SSL/TLS certificate validation will be managed and 
by default it would be possible to enable secure SSL/TLS client checking like 
described in http://bugs.python.org/issue13647 .

--
components: Library (Lib)
messages: 150142
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't have a default CA Store
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue13655>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13647] Python SSL stack doesn't securely validate certificate (as client)

2011-12-23 Thread naif 

naif  added the comment:

Hi all,

i added a ticket on setting up a default CA-store for Python, eliminating the 
need of CA-Store mainteinance:
http://bugs.python.org/issue13655

This feature is a pre-requisite to implement by default SSL/TLS Client secure 
certificate verification.

--

___
Python tracker 
<http://bugs.python.org/issue13647>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13655] Python SSL stack doesn't have a default CA Store

2011-12-23 Thread naif 

Changes by naif :


--
type:  -> security

___
Python tracker 
<http://bugs.python.org/issue13655>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13647] Python SSL stack doesn't securely validate certificate (as client)

2011-12-23 Thread naif 

naif  added the comment:

 looking at OpenSSL command line, there is the "verify" that does a lot of 
checks on it's own:
http://www.openssl.org/docs/apps/verify.html

Dan, do you think that this apps does all the "best practice" verificati or 
it's missing something?

Antoine, in case it's useful, do you think that it would be possible to have 
something exactly-like the OpenSSL verify command?

--

___
Python tracker 
<http://bugs.python.org/issue13647>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13655] Python SSL stack doesn't have a default CA Store

2011-12-23 Thread naif 

naif  added the comment:

Mozilla CA are available on:

https://www.mozilla.org/projects/security/certs/

The warranty and security process of Mozilla handling of SSL CA root certs is 
described on:

https://wiki.mozilla.org/CA

I think that Python language could reasonably base it's default root CA on the 
Mozilla ones that are the most recognized for security and transparency in the 
world.

--

___
Python tracker 
<http://bugs.python.org/issue13655>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com