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
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 som
Changes by naif :
--
type: -> security
___
Python tracker
<http://bugs.python.org/issue13655>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.p
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
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&#
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.
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
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
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
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 S
naif added the comment:
I confirm, tested "HIGH:!SSLv2" and MD5 cannot be negotiated.
--
___
Python tracker
<http://bugs.python.org/issue13636>
___
___
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 s
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-
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
<h
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
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:
opens
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.
T
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)
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/is
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
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/issue13
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.
I
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 Ci
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 troug
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/fo
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
<h
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
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/issue13
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 appro
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
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");
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");
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 suppor
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 ciphe
34 matches
Mail list logo
