-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
With forced TLSv1.3, still TLSv1.0 Client Hello is sent #8478
Comments
Mh strange, I thought I tested it, and it did not work, but forcing the ssl context of aiohttp to use tls1.3 worked. Here is my code if anyone needs it (my sslhelper also allows some other options, but you do not need them for this task):
|
Ufff, this only works because I first make the request via requests (because I used the same cached context for both). If you comment out
it does not work |
Simplified test script, with forced tlsv1.3
|
After digging deeper, I found out, that the version fields are not the problem. Sorry for bothering you. |
For anyone who is interested, the problem is that no ALPN extension is used by aiohttp, thats why the (haproxy?) reverse proxy used by the university ignored the client hello. The requests library and curl default uses the ALPN extension. If you use the --no-alpn flag on curl it can also not connect. requests uses urllib3, that automatically sets the alpn correct, see https://github.com/search?q=repo%3Aurllib3%2Furllib3%20set_alpn_protocols&type=code If anyone needs to fix this too: We can get the same behavior if you set the alpn option in your ssl context like this: |
As far as I can see, ALPN is initiated by a client. So, it's a bug in the proxy that it won't work without ALPN at all. I wonder if it's worth setting this by default though? I'm not clear exactly what tradeoffs this might make, but from a quick read, I think the benefit is faster connection as the protocol is decided up-front without an extra roundtrip, while the drawback is advertising the protocol in cleartext (but, that doesn't really appear to be a security issue if we're just advertising HTTP versions). |
Describe the bug
It looks like https://bbb-lb.uni-paderborn.de only configured TLS1.3. But aiohttp is not able to connect to this site. Requests does the request without problem. In Wireshark I see that aiohttp sends a TLS Client Hello with version 1.0, but requests sends a Client hello with version 1.3. The same is the case for curl and wget, curl sends an TLSv1.3 Client Hello, wget not, and so wget can not connect to the website.
Forcing requests to use TLS1.2 (so that it sends an TLSv1.2 Client hello), then it also can not connect to the server.
Is this considered a bug, or is this expected because the
bbb-lb.uni-paderborn.de
server is misconfigured?To Reproduce
Simple Script for testing:
Expected behavior
Some option to allow aiohttp to connect to such misconfigured servers.
Logs/tracebacks
Python Version
aiohttp Version
multidict Version
yarl Version
OS
Arch Linux 6.8.9-arch1-1
Related component
Client
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: