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
crypto/tls: TLS 1.3 client fails to connect to some servers #41910
Comments
Minor update: This reproduces with the www.inquirer.com homepage, so it's not route specific. |
Double update: Setting |
/cc @FiloSottile |
Curl appears to connect properly with TLS1.3 enabled by OpenSSL.
|
Is it possible this is related to #40521? |
@FiloSottile I was hoping this would be resolved by go 1.15.4, but it looks like no such luck:
|
cc @ianlancetaylor - possible release blocker? |
This has been broken in prod for the last month, so I don't think it's a release issue per se? |
Could still be faulty on Akamai's side, but it's strange that it works in Curl with TLSL1.3 turned on. |
Howdy @carlmjohnson, you mentioned that this issue has been around for a while per #41910 (comment). We’ve been swamped for Go1.16 development cycles, yet we are almost getting Go1.16 out the door. I shall move this to Go1.17, and when it gets looked at, we shall backport it. |
Yeah, it started Oct 10, presumably because of a change on Akamai’s side. I’m planning to upgrade to 1.16 right away so I’m fine with a fix coming mid-cycle in 1.16 or whenever. |
See also #43250 re TLS 1.3. |
This no longer reproduces with Go 1.15 or 1.16. I assume that whatever was going wrong has been fixed on the inquirer.com side, presumably by Akamai. |
What version of Go are you using (
go version
)?go version go1.15.2 darwin/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputBut it also happens on an AWS Lambda.
What did you do?
Attempted to get a URL from a certain server with net/http.
Here is an example URL: https://www.inquirer.com/resizer/LUs6Sqe2nxqwxVEe0NHgiLSh6i0=/arc-anglerfish-arc2-prod-pmn/public/GG5L3ZCM5JCOTDVPYIURDF3HHE.jpg
What did you expect to see?
The URL should load an image.
Interestingly, Slack fails to preview this URL, so I think that means they're using Go internally. The image should load in your browser.
What did you see instead?
The server sends an error message to net/http, but not to browsers, curl, or fasthttp.
It's unclear if Go is doing something weird and the server doesn't like it or vice versa. The server appears to be an Akamai CDN. (It's controlled by a friendly third party. I can ask for more details on Monday.) It's possible they've decided that Go is evil and are blocking it somehow, but changing the User-Agent does not help, so however they detect Go, it isn't in the obvious manner of banning a User-Agent or IP.
Here's a reproducer:
Output:
In other words, fasthttp gets the JPEG. Curl does as well.
The text was updated successfully, but these errors were encountered: