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
SSLContext.post_handshake_auth implicitly enables cert validation #81609
Comments
Enabling TLS 1.3 post handshake auth also enables cert chain validation. OpenSSL documents SSL_VERIFY_POST_HANDSHAKE as ignored for client side. However tls_process_server_certificate in the client state machine code does not ignore the flag and checks for a correct cert chain. see openssl/openssl#9259 and https://github.com/openssl/openssl/blob/743694a6c29e5a6387819523fad5e3b7e613f1ee/ssl/statem/statem_clnt.c#L1899-L1918 |
Christian, just confirming that, since you have not set this as a "release blocker", 3.7.4 will go out without it. |
This issue breaks some stuff at work. I would appreciate if we can get the fix into 3.7.4. I wasn't aware that we are so close to cut-off to 3.7.4 release. What does the fix do? For a server-side socket, the SSL_VERIFY_POST_HANDSHAKE verify flag is now only set when the server socket is configured to verify client certs. Server sockets without SSL_VERIFY_PEER flag don't set the option. The presence of SSL_VERIFY_POST_HANDSHAKE without SSL_VERIFY_PEER sometimes triggers handshake errors like "extension not received". The official documentation says "This flag must be used together with SSL_VERIFY_PEER.". The ssl.CERT_OPTIONAL and ssl.CERT_REQURED both set SSL_VERIFY_PEER. SSL_set_post_handshake_auth() is not enabled for server-side sockets. For client side sockets, PHA is only enabled with SSL_set_post_handshake_auth(ssl, 1). The SSL_VERIFY_POST_HANDSHAKE flag is no longer set. https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_post_handshake_auth.html |
"Assuming no critical problems are found prior to 2019-06-28, no code changes are planned between these release candidates and the final releases." We were planning to start producing the final release artifacts in a couple of hours so we need to make a decision very quickly. If you think this is necessary, we can delay the release a bit. In the worst case, we could do a second release candidate but I *really* do not want to do that unless it is absolutely necessary. Also note that with 3.7.4, we have updated the Windows and macOS installers to use OpenSSL 1.1.1 (c) instead of 1.1.0. |
There are currently two issues with TLS 1.3 in Python. The issue https://bugs.python.org/issue37440 can be worked around easily with a custom SSLContext. This issue is a bigger problem because there is no possible workaround. The bug is going to break applications that verify clients with a certificate but accept untrusted server certificates. It's not a common scenario, but I just happen to run into this issue for a project at work. I'm sorry for the mess. :( I noticed the bug a couple of days ago. It took me a while to understand the root cause. |
Christian, do you have an estimate for when these issues will be resolved? We are holding 3.7.4 right now. |
Should this be closed? |
3.7 to 3.9 are fixed. Benjamin, do you want the fix in 2.7? |
Yes, please. |
Can this be closed? 2.7 is no longer relevant. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: