http: TLS handshake error from <IP>:<PORT>: EOF

[einthusan]

I manage a site with very large traffic and using Go 1.8 beta in production. We moved over from a PHP implementation by re-writing everything from scratch in go. We saw a significant drop in our users, and seeing our logs flooding with http: TLS handshake error from <IP>:<PORT>: EOF errors. I am not sure if this is related to the issue being discussed here. Is there anything we can do to help test why these errors are happening? Every browser we tested seems to work fine. We used BrowerStack for our testing on various OS and browser versions. However, we are pretty sure something is problematic in either our code or our TLS certificates. Any help would be appreciated. The domain in question is einthusan.tv

[Tamás Gulácsi]

Minimal TLS protocol version? Is SSL3, TLS1.0 allowed on server side? AFAIK by default, no.

[eint...@paperboardinc.com]

We ran the SSL Labs test, shows that we do have TLS 1.0 … I don’t think anyone uses SSL3 anymore... Do they?

[Tamás Gulácsi]

No, but the Go default min is TLS1.0, not TLS1.1, that's why you need a custom TLSConfig!

[Einthusan Vigneswaran]

Are you suggesting to set the minimum to 1.1? Wouldn't that cause less compatibility? Maybe a typo in your reply?

Sent from iPhone

> On Dec 31, 2016, at 2:28 PM, Tamás Gulácsi <tgula...@gmail.com> wrote:
>
> No, but the Go default min is TLS1.0, not TLS1.1, that's why you need a custom TLSConfig!
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/yNOQqHPas9U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Gulácsi Tamás]

Yup, exchanged the values, sorry. The default is 1.1, so you need 1.0.

[Einthusan Vigneswaran]

But what I don’t get is why SSL Labs test shows that we do indeed support TLS 1.0?

https://www.ssllabs.com/ssltest/analyze.html?d=einthusan.tv&latest

 

 

[Matt Harden]

Probably because we do? It's just that the default minimum version is TLS1.1.

On Sat, Dec 31, 2016, 17:04 Einthusan Vigneswaran <eint...@paperboardinc.com> wrote:

But what I don’t get is why SSL Labs test shows that we do indeed support TLS 1.0?

https://www.ssllabs.com/ssltest/analyze.html?d=einthusan.tv&latest

 

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Matt Harden]

Oh sorry, I misunderstood the question.

[Einthusan Vigneswaran]

No worries J at least your trying to help. I think the minimum must be TLS 1.0 because I know I didn’t set the tls server config value, however, I do know exactly where to set it. I asked this question in the Go repo on Github, a core golang developer told me to use the forums for asking questions, I suppose he knows the answer since he wasn’t really surprised about the behavior. We have about 2 million people using the site on a monthly basis, so it really floods our logs. @bratfpatrick please help!

 

[James Hartig]

We're also seeing 100k of these errors per day per server. The majority of the time its just a result of:

client SYN

server SYN-ACK

client FIN

server FIN-ACK

or

 

client SYN

server SYN-ACK

Retransmission

Retransmission

RST

...

The error if the version is unsupported is:

http: TLS handshake error from ip:port : tls: client offered an unsupported, maximum protocol version of 300

Can we ignore this error if there was no handshake ever initiated?

Thanks!

[James Hartig]

I've posted a more detailed explanation of this to the net-dev mailing list: https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/IsYHz3hNlNU

What we're seeing is clients making 2 back-to-back TCP connections to port 443 but only ever sending Client Hello (and continuing TLS handshake) to the first opened socket. The second socket is closed by the client after ~10 seconds without anything over the socket after the server acknowledging the SYN.

It seems like this isn't a Golang issue but still seems like Go shouldn't be logging that the handshake failed when the handshake was never started.

Should I file a bug to remove the log in that case?