Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-29136: Add TLS 1.3 cipher suites and OP_NO_TLSv1_3 #1363

Merged
merged 3 commits into from
Sep 8, 2017

Conversation

tiran
Copy link
Member

@tiran tiran commented Apr 30, 2017

TLS 1.3 introduces a new, distinct set of cipher suites. The TLS 1.3
cipher suites don't overlap with cipher suites from TLS 1.2 and earlier.
Since Python sets its own set of permitted ciphers, TLS 1.3 handshake
will fail as soon as OpenSSL 1.1.1 is released. Let's enable the common
AES-GCM and ChaCha20 suites.

Additionally the flag OP_NO_TLSv1_3 is added. It defaults to 0 (no op) with
OpenSSL prior to 1.1.1. This allows applications to opt-out from TLS 1.3
now.

Signed-off-by: Christian Heimes [email protected]

https://bugs.python.org/issue29136

@mention-bot
Copy link

@tiran, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Yhg1s, @benjaminp and @serhiy-storchaka to be potential reviewers.

@@ -189,13 +190,16 @@
# * Disable NULL authentication, NULL encryption, 3DES and MD5 MACs
# for security reasons
_DEFAULT_CIPHERS = (
'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:'
'TLS13-AES-128-GCM-SHA256:'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this just be expressed as TLS13? Should it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can't :( I tried it with latest master:

Error in cipher list
0:error:2506906C:DSO support routines:DSO_pathbyaddr:functionality not supported:crypto/dso/dso_lib.c:315:
0:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2303:

Prevents a TLSv1.3 connection. This option is only applicable in conjunction
with :const:`PROTOCOL_TLS`. It prevents the peers from choosing TLSv1.3 as
the protocol version. TLS 1.3 is available with OpenSSL 1.1.1 or later.
With older versions, the flag defaults to *0*.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't currently expose OP_NO_TLSv1_2 if your OpenSSL is old enough to not have TLS1.2. Why is this flag special? Should we just change all of them for consistency?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applications may use hasattr() to detect if TLS 1.1 and 1.2 are available. I'd wish we could change the values to default to 0. It's awkward to require a getattr() call.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS: OP_NO_TLSv1_1 and OP_NO_TLSv1_2 are going to be available as soon as we remove support for OpenSSL versions that are no longer supported by upstream.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these are specialized options (most people should stick to whatever create_default_context() returns), so the need to call getattr() doesn't sound much of a problem IMHO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pitrou The PROTOCOL constants with fixed version number are going away. OpenSSL has deprecated them in favor of auto-negotiation. The OP_NO_* constants are the only API that is both available with OpenSSL 1.0.x and 1.1.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, other modules don't follow this pattern either, i.e. optional flags are not set to zero when they are not provided by the OS, they are simply not exposed at all. If Twisted wants to be CentOS-compatible, the best thing they can do is to have actual CI on a CentOS system. That's of course complicating things a bit, but it's the only reliable way to reach that goal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pitrou: note that in this specific case, the flag being zero means it exactly implements the standard semantics (it successfully disables the feature, because the feature is always disabled). That's not the case for most other flags.

I don't really care that much; obviously the other way has worked fine too. But @tiran's approach has some mild but nice benefits and I'm not sure why this is a point of contention at all – AFAICT all your arguments have been that it doesn't matter either way; I haven't seen a single argument for why having these flags always available is harmful?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't mind if this is the first such flag we exposed. But other flags already exist and they don't work the same way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With OpenSSL 1.1, OP_NO_SSLv2 is 0.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. If OpenSSL is playing such games, then I guess it's acceptable for us to do it too...

@brettcannon brettcannon added the type-feature A feature request or enhancement label May 1, 2017
@tiran tiran force-pushed the bpo-29136-tls13 branch 2 times, most recently from 2512c9f to 0c22c7f Compare September 5, 2017 20:13
@@ -206,6 +206,8 @@ instead.
.. rubric:: Footnotes
.. [1] :class:`SSLContext` disables SSLv2 with :data:`OP_NO_SSLv2` by default.
.. [2] :class:`SSLContext` disables SSLv3 with :data:`OP_NO_SSLv3` by default.
.. [3] TLS 1.3 protocol is will be available with :data:`PROTOCOL_TLS` in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: "is will be".

@@ -206,6 +206,8 @@ instead.
.. rubric:: Footnotes
.. [1] :class:`SSLContext` disables SSLv2 with :data:`OP_NO_SSLv2` by default.
.. [2] :class:`SSLContext` disables SSLv3 with :data:`OP_NO_SSLv3` by default.
.. [3] TLS 1.3 protocol is will be available with :data:`PROTOCOL_TLS` in
OpenSSL >= 1.1.1. There is no dedicated PROTOCOL for just TLSv1.3.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For clarity, I suggest "There is no dedicated PROTOCOL constant for just TLS 1.3".

TLS 1.3 introduces a new, distinct set of cipher suites. The TLS 1.3
cipher suites don't overlap with cipher suites from TLS 1.2 and earlier.
Since Python sets its own set of permitted ciphers, TLS 1.3 handshake
will fail as soon as OpenSSL 1.1.1 is released. Let's enable the common
AES-GCM and ChaCha20 suites.

Additionally the flag OP_NO_TLSv1_3 is added. It defaults to 0 (no op) with
OpenSSL prior to 1.1.1. This allows applications to opt-out from TLS 1.3
now.

Signed-off-by: Christian Heimes <[email protected]>
Copy link
Member

@gpshead gpshead left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me. one comment on some documentation wording for clarity.

Prevents a TLSv1.3 connection. This option is only applicable in conjunction
with :const:`PROTOCOL_TLS`. It prevents the peers from choosing TLSv1.3 as
the protocol version. TLS 1.3 is available with OpenSSL 1.1.1 or later.
With older versions, the flag defaults to *0*.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggesting wording clarification:

"With older versions, the flag defaults to 0." -> "When Python has been compiled against an older version of OpenSSL, the flag defaults to 0."

@tiran tiran merged commit cb5b68a into python:master Sep 8, 2017
@miss-islington
Copy link
Contributor

🐍🍒⛏🤖 Thanks @tiran for the PR, and @tiran for merging it 🌮🎉.I'm working now to backport this PR to: 2.7, 3.6.

@tiran tiran deleted the bpo-29136-tls13 branch September 8, 2017 01:07
tiran added a commit to tiran/cpython that referenced this pull request Sep 8, 2017
…H-1363)

* bpo-29136: Add TLS 1.3 support

TLS 1.3 introduces a new, distinct set of cipher suites. The TLS 1.3
cipher suites don't overlap with cipher suites from TLS 1.2 and earlier.
Since Python sets its own set of permitted ciphers, TLS 1.3 handshake
will fail as soon as OpenSSL 1.1.1 is released. Let's enable the common
AES-GCM and ChaCha20 suites.

Additionally the flag OP_NO_TLSv1_3 is added. It defaults to 0 (no op) with
OpenSSL prior to 1.1.1. This allows applications to opt-out from TLS 1.3
now.

Signed-off-by: Christian Heimes <[email protected]>.
(cherry picked from commit cb5b68a)
@bedevere-bot
Copy link

GH-3444 is a backport of this pull request to the 3.6 branch.

tiran added a commit to tiran/cpython that referenced this pull request Sep 8, 2017
…H-1363)

* bpo-29136: Add TLS 1.3 support

TLS 1.3 introduces a new, distinct set of cipher suites. The TLS 1.3
cipher suites don't overlap with cipher suites from TLS 1.2 and earlier.
Since Python sets its own set of permitted ciphers, TLS 1.3 handshake
will fail as soon as OpenSSL 1.1.1 is released. Let's enable the common
AES-GCM and ChaCha20 suites.

Additionally the flag OP_NO_TLSv1_3 is added. It defaults to 0 (no op) with
OpenSSL prior to 1.1.1. This allows applications to opt-out from TLS 1.3
now.

Signed-off-by: Christian Heimes <[email protected]>.
(cherry picked from commit cb5b68a)
@bedevere-bot
Copy link

GH-3446 is a backport of this pull request to the 2.7 branch.

tiran added a commit that referenced this pull request Sep 8, 2017
#3444)

* bpo-29136: Add TLS 1.3 support

TLS 1.3 introduces a new, distinct set of cipher suites. The TLS 1.3
cipher suites don't overlap with cipher suites from TLS 1.2 and earlier.
Since Python sets its own set of permitted ciphers, TLS 1.3 handshake
will fail as soon as OpenSSL 1.1.1 is released. Let's enable the common
AES-GCM and ChaCha20 suites.

Additionally the flag OP_NO_TLSv1_3 is added. It defaults to 0 (no op) with
OpenSSL prior to 1.1.1. This allows applications to opt-out from TLS 1.3
now.

Signed-off-by: Christian Heimes <[email protected]>.
(cherry picked from commit cb5b68a)
tiran added a commit that referenced this pull request Sep 8, 2017
#3446)

* bpo-29136: Add TLS 1.3 support

TLS 1.3 introduces a new, distinct set of cipher suites. The TLS 1.3
cipher suites don't overlap with cipher suites from TLS 1.2 and earlier.
Since Python sets its own set of permitted ciphers, TLS 1.3 handshake
will fail as soon as OpenSSL 1.1.1 is released. Let's enable the common
AES-GCM and ChaCha20 suites.

Additionally the flag OP_NO_TLSv1_3 is added. It defaults to 0 (no op) with
OpenSSL prior to 1.1.1. This allows applications to opt-out from TLS 1.3
now.

Signed-off-by: Christian Heimes <[email protected]>.
(cherry picked from commit cb5b68a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants