Mark Kubacki added the comment:
The cipher strings rely too much on AES for my taste. Imagine that
ChaCha20Poly1305 or any other strong cipher suite is introduced to OpenSSL in
the future.
Enabling using general, and demoting using narrow terms, seems IMHO a better
approach. For example:
Donald Stufft added the comment:
The cipher string includes HIGH, so if ChaCha20Poly1305 or another cipher suite
is added to OpenSSL it'll get included in the cipher string by default.
So the major difference of what you suggest would be no longer prioritizing
ciphers. However I would argue
Antoine Pitrou added the comment:
For any device that has hardware support for AES (AES-NI) AES-GCM is
hands down a better choice of cipher. It is secure, has no issues in
the spec itself, and it is *fast*, like 900MB/s for AES-128-GCM on a
Sandy Bridge Xeon w/ AES-NI (ChaCha20Poly1305 got
Donald Stufft added the comment:
I think performance isn't really relevant, except perhaps on very busy
servers. A smartphone acting as a *client* certainly shouldn't need to
download 20 MB/s of encrypted data.
Well, if you factor out performance then ChaCha20Poly1305 and AES-GCM are more
or
Mark Kubacki added the comment:
Thanks for the detailed insight, Donald! And I certainly love the progress
these changes here bring. :-)
Perhaps limiting the scope to ChaCha20Poly1305 (»CCP«) has been a wrong
approach of mine to explain my concerns:
We should not refer to any particular
Alex Gaynor added the comment:
It would be great if we could rely on OpenSSL's ordering. It would be seriously
fantastic. OpenSSL is best positioned to be able to do the right things, it's
updated at the right times. It should be where we do this.
Unfortunately the OpenSSL maintainers have
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
___
Python-bugs-list mailing list
Roundup Robot added the comment:
New changeset 869277faf3dc by Antoine Pitrou in branch '3.4':
Issue #21015: SSL contexts will now automatically select an elliptic curve for
ECDH key exchange on OpenSSL 1.0.2 and later, and otherwise default to
prime256v1.
Donald Stufft added the comment:
Yes
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
___
Antoine Pitrou added the comment:
The buildbot failures should have been fixed by #21015, should we close this
one?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
Marc-Andre Lemburg added the comment:
On 21.03.2014 00:10, Donald Stufft wrote:
We shouldn't do this in Python for the same reason we're not including
a predefined set of CA root certificates with the distribution.
The difference here is that there are properly maintained alternatives to
Donald Stufft added the comment:
We shouldn't do this in Python for the same reason we're not including
a predefined set of CA root certificates with the distribution.
The difference here is that there are properly maintained alternatives to
Python including a predefined set of CA
Donald Stufft added the comment:
Updated the patch to change the priority slightly to ensure that all the secure
PFS ciphers come first and that non PFS AES comes before the other Non PFS HIGH
ciphers
--
Added file: http://bugs.python.org/file34546/better-ciphers-better-priority.diff
Marc-Andre Lemburg added the comment:
On 21.03.2014 12:42, Donald Stufft wrote:
If we enforce a specific set of ciphers per default and a user finds
that a server he wants to communicate with for example only supports
RC4 ciphers, because that's the server admins were told to use after
the
Donald Stufft added the comment:
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
Antoine Pitrou added the comment:
I think the proposed cipher string is still overly complicated and tedious to
maintain. The following seems to achieve similar results:
'EECDH+AESGCM:DH+AESGCM:ECDH:DH:HIGH:!aNULL:!eNULL:!MD5:!DSS:!LOW:!EXPORT'
Also, as Marc-André points out, we probably
Antoine Pitrou added the comment:
I'm pretty sure you can't even use PSK or SRP using the stdlib ssl
module, I
didn't explicitly exclude them though.
This is true. There are issues open, though: issue 11943 and issue 19084.
--
___
Python tracker
Antoine Pitrou added the comment:
(oh, I missed the part where Marc-André suggested not to drop DSS; this should
also be removed from my cipher string proposal)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
Donald Stufft added the comment:
As I said earlier Antoine, doing that puts PFS RC4 before non PFS AES. That
isn't good because RC4 key stream bias makes it extremely fragile. RC4 needs to
be in the default ciphers for compatibility sake but it should be dead last so
that it's only used as a
Donald Stufft added the comment:
With regard to PSK and SRP. Seeing as how Python doesn't currently support
them, SRP had a patch that hasn't been worked on since 2011 and PSK doesn't
have a patch at all that this cipher string shouldn't concern itself with
something that Python might someday
Antoine Pitrou added the comment:
With regard to PSK and SRP. Seeing as how Python doesn't currently
support them, SRP had a patch that hasn't been worked on since 2011 and
PSK doesn't have a patch at all that this cipher string shouldn't
concern itself with something that Python might someday
Donald Stufft added the comment:
Yup :) Just being explicit in that!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
___
Antoine Pitrou added the comment:
Ok, so I think the latest patch is mostly good but I don't understand why the
restricted ciphers (again, misnomer) would ban RC4 (and DSS?). These are the
ciphers used by higher-level client libs, and connection failures will confuse
the hell out of people.
Donald Stufft added the comment:
Note: The RC4 and DSS exclusion existed previously on the restricted ciphers so
we'd have to ask Christian why he did that. For me personally the restricted
ciphers are intended to be best practice ciphers and that means no RC4. DSS
here I'm kind of meh about
Donald Stufft added the comment:
Forgot to add! If you think splitting between restricted server and client
ciphers I can split them like that and upload a new patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
Antoine Pitrou added the comment:
Forgot to add! If you think splitting between restricted server and
client ciphers I can split them like that and upload a new patch.
I was about to open a separate issue for the server side. How about
restricting this issue to client usage?
--
Donald Stufft added the comment:
Not sure what you mean by client issue. Do you mean to keep RC4?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
Antoine Pitrou added the comment:
Which client issue? Sorry, I've lost track :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
___
Donald Stufft added the comment:
Er, I typed issue and meant usage. Right now the only difference between
restricted ciphers and the default ciphers is restricted ciphers have no RC4
and no DSS. You wanted this issue limited to client changes and I'm not sure
how to do that without enabling
Antoine Pitrou added the comment:
Er, I typed issue and meant usage. Right now the only difference
between restricted ciphers and the default ciphers is restricted
ciphers have no RC4 and no DSS. You wanted this issue limited to
client changes and I'm not sure how to do that without enabling
Nick Coghlan added the comment:
Shall we commit the new string for 3.5 for the time being? I'm currently
working on a PEP to help define a policy for dealing with network security
related issues/enhancements in maintenance branches, so I don't think we should
touch those until we have that
Antoine Pitrou added the comment:
(for the record and for the sake of comparison, Postfix's high security
setting is ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
Antoine Pitrou added the comment:
The patch will also need updating the Cipher selection paragraph in ssl.rst,
I think.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
Donald Stufft added the comment:
I can add that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
___
Python-bugs-list mailing list
Donald Stufft added the comment:
Hmm, I'm not sure what needs updated. The docs only say that ssl module
disabled certain weak ciphers by default which is still the case. Was there
some specific place or wording you were looking for?
--
___
Python
Antoine Pitrou added the comment:
Well, the doc currently says:
Starting from Python 3.2.3, the
ssl module disables certain weak ciphers by default, but you may want
to further restrict the cipher choice. For example::
context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
Donald Stufft added the comment:
Ah yes, I skipped over that looking for a place where we were detailing what
ciphers were picked. Ok Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
Donald Stufft added the comment:
Added the docs changes
--
Added file: http://bugs.python.org/file34558/better-ciphers-with-docs.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
Roundup Robot added the comment:
New changeset e9749a7aa958 by Donald Stufft in branch '3.4':
Issue #20995: Enhance default ciphers used by the ssl module
http://hg.python.org/cpython/rev/e9749a7aa958
--
nosy: +python-dev
___
Python tracker
Roundup Robot added the comment:
New changeset 60f696488c4f by Donald Stufft in branch 'default':
Merge changes from 3.4 to bring in fixes for Issue #20995
http://hg.python.org/cpython/rev/60f696488c4f
--
___
Python tracker rep...@bugs.python.org
New submission from Donald Stufft:
As of right now the default cipher list for the ssl module is
DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2, additionally on Python 3.4 when you
use create_default_context() then you also additionally get
HIGH:!aNULL:!RC4:!DSS.
I think we should change this to
Changes by Alex Gaynor alex.gay...@gmail.com:
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
___
Python-bugs-list mailing
Antoine Pitrou added the comment:
I really don't think hardcoding specific ciphers is a good idea.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
Marc-Andre Lemburg added the comment:
On 20.03.2014 15:11, Donald Stufft wrote:
The compatibility of this is pretty good. The only time this should cause a
connection to *fail* is if a server is using an insecure cipher and in that
case you can re-enable it by simply passing the original
R. David Murray added the comment:
create_default_context is about best practices, though, so it seems to me it
wouldn't be crazy to do it there.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
Antoine Pitrou added the comment:
create_default_context is about best practices, though, so it seems to
me it wouldn't be crazy to do it there.
Agreed, but the real problem here is maintenance. Hardcoding a list of
specific ciphers means someone must follow closely the introduction of
new
Alex Gaynor added the comment:
That's because of the set of ciphersuites offered by the server (see
https://www.ssllabs.com/ssltest/analyze.html?d=linuxfr.org), it's not an
inevitable property of TLS. For example jenkins.cryptography.io (see
Donald Stufft added the comment:
Yea I noticed that, so I was doing some more testing, here's what I think we
should be using (It Adds back in RC4):
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
Nick Coghlan added the comment:
In terms of following closely, I'd be willing to encourage Red Hat's SRT to
keep an eye on this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
Donald Stufft added the comment:
Another bit of maintenance here:
If a new cipher suite is added to OpenSSL it won' be generally available for a
long while so very few if any services are going to be willing to depend on
*only* it. For the very rare and unlikely case that somebody does setup
Alex Gaynor added the comment:
It's also worth noting that users appear to be FAR more likely to have an up to
date Python than they are an up to date OpenSSL, meaning that if a change needs
to be made, we're much better situated to get that disseminated to actual users
than OpenSSL is
Antoine Pitrou added the comment:
The string I'm proposing has been carefully crafted in order to get
the ciphers in a very particular order. That order is basically - 1)
Security of the cipher itself 2) PFS 3) Performance while also
maintaining compatibility both forwards and backwards.
I
Antoine Pitrou added the comment:
See http://bugs.python.org/issue20995#msg214249
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
___
___
Antoine Pitrou added the comment:
By the way:
Using the default or the wide open strings are inherently more
dangerous because of the wide range of OpenSSL's that are in
production use. It's hard without auditing every version of OpenSSL to
figure out what ciphers will be available in what
Donald Stufft added the comment:
This doesn't parse. If the system OpenSSL isn't maintained properly, it's not
Python's job to workaround that. And we certainly don't have the required
knowledge and dedication anyway.
Please let's not have a repeat of
Antoine Pitrou added the comment:
Please let's not have a repeat of
https://bugs.ruby-lang.org/issues/9424, Python is in a better place to
workaround that than anyone else.
Please stop the FUD. I proposed an alternative, how is it insecure
according according to you?
--
Donald Stufft added the comment:
Oh and don't confuse me that I think Python's current situation is as bad as
Ruby's was, but that attitude is dangerous and wrong :/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20995
Donald Stufft added the comment:
I'm still looking into what HIGH entails across all the various OpenSSLs that
are in production that I can access. That FUD was responding to the attitude
that it's not Python's job to do this. Python is exposing a security sensitive
API, it is it's job.
Marc-Andre Lemburg added the comment:
On 20.03.2014 23:36, Donald Stufft wrote:
Donald Stufft added the comment:
I'm still looking into what HIGH entails across all the various OpenSSLs
that are in production that I can access. That FUD was responding to the
attitude that it's not
Marc-Andre Lemburg added the comment:
On 20.03.2014 21:52, Alex Gaynor wrote:
It's also worth noting that users appear to be FAR more likely to have an up
to date Python than they are an up to date OpenSSL, meaning that if a change
needs to be made, we're much better situated to get that
Donald Stufft added the comment:
I disagree. Python only provides an interface to OpenSSL, so the OpenSSL
system defaults should be used.
Python is already changing the OpenSSL defaults, also you're advocating that
Python should support 40bit encryption that can be brute forced in a matter of
Antoine Pitrou added the comment:
Again, Python is already forcing a set of ciphers. I don't know what sort of
Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
default set. Things like DES (not 3DES, DES) and 40bit RC4.
I wonder why RedHat doesn't bother changing
Donald Stufft added the comment:
Again, Python is already forcing a set of ciphers. I don't know what sort of
Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
default set. Things like DES (not 3DES, DES) and 40bit RC4.
I wonder why RedHat doesn't bother
Donald Stufft added the comment:
Ok Antoine I've looked around.
Using a string like this:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4:ECDH+HIGH:DH+HIGH:RSA+HIGH:!aNULL:!eNULL:!MD5:!DSS
The only
Donald Stufft added the comment:
Oh, additionally OpenSSL makes no promises what the meaning of HIGH will be
in the future. So you can only look at what it means now and what it means in
the past.
OpenSSL is not a good library and it's unfortunate that they don't attempt to
make people
Donald Stufft added the comment:
Oh, Additionally Marc:
Even if some system administrator or some system out there does patch their
OpenSSL to actually be safe by default Python changing it's cipher string only
adds to the potential security (or at worst does nothing). If even one system
(of
Antoine Pitrou added the comment:
However I still content that using HIGH in the cipherstring actually
adds additional maintenance burden. In order to know if that
cipherstring is still safe you must run it against every target
OpenSSL you want to make secure to ensure that it doesn't allow
Donald Stufft added the comment:
However I still content that using HIGH in the cipherstring actually
adds additional maintenance burden. In order to know if that
cipherstring is still safe you must run it against every target
OpenSSL you want to make secure to ensure that it doesn't
Antoine Pitrou added the comment:
The Python ssl module is used for servers and clients. Ideally servers will
have prefer server ciphers on, but that doesn't always happen and providing
a modern level of security for end users is preferable.
We should have specific defaults for servers in
Donald Stufft added the comment:
Again: the point is maintenance later, not breakage now.
Ok, well I don't agree that it's more maintenance later to be explicit and not
include HIGH, but whatever it's not insecure at the moment so.
Attached is a patch against 3.5 for folks to review.
71 matches
Mail list logo
