Default golang crypto/tls connection raises ERR_SSL_VERSION_INTERFERENCE
Reported by
em...@ermolay.com,
Jul 10
|
|||||||||||
Issue description
Chrome Version : 67.0.3396.99
OS Version: OS X 10.13.5
What steps will reproduce the problem?
1. Create a minimal golang project using crypto/tls
2. Wrap a base http listener with tls
3. Listen on both (start server)
4. Try to establish a secure websocket connection to the server
What is the expected result?
Connection to the server would be established and then perhaps it would break somewhere, I don't know. "Could work!?"
What happens instead of that?
The connection attempt throws error
Please provide any additional information below. Attach a screenshot if
possible.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Example code (uses oklog/oklog Group to manage concurrent tasks in package main):
httpListener, err := net.Listen("tcp", addr)
if err != nil {
os.Exit(1)
}
g.Add(func() error {
return http.Serve(httpListener, httpHandler)
}, func(error) {
httpListener.Close()
})
{
tlsListener := tls.NewListener(
httpListener,
&tls.Config{Certificates: []tls.Certificate{cert}},
)
g.Add(func() error {
return handleSecureConnection(tlsListener)
}, func(error) {
tlsListener.Close()
})
}
,
Jul 10
,
Jul 10
Please attach a NetLog per these instructions. https://dev.chromium.org/for-testers/providing-network-details Also since this is just a Go server, if you could provide a complete runnable code sample (certificates, key, etc) to reproduce, that would be helpful. I use Go's TLS stack all the time for test servers, so breaking it would be rather unexpected. :-)
,
Jul 10
The TLS stack that doesn't have 1.3 in it? That Go TLS stack? :D Will send requested info end of day.
,
Jul 10
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 10
,
Jul 10
,
Jul 11
Best I could do https://github.com/ermik/ssl13 It's just really weird, and not necessarily good code, I've moved on miles beyond in the last 24 hrs. One thing that may prove it's not just my ignorance, but is an actual bug — of the logging is done smack in the middle of the handler, right after .Accept() in a simple for loop — it kind of works...
,
Jul 11
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 11
You appear to have httpListener passed to both http.Serve and tls.NewListener. That means both the http module and the tls module are trying to handle incoming sockets, no? So for each incoming socket you will either handle it as cleartext HTTP or a TLS connection, depending on which listener happened to get the socket. ERR_SSL_VERSION_INTERFERENCE shows up if connecting with TLS 1.3 enabled failed but connecting with TLS 1.3 disabled worked. Most likely http.Serve serviced your first connection and tls.NewListener serviced the second one. What you actually want is to pass tlsListener into http.Serve. That is, httpListener produces net.TCPConns. tlsListener takes those and wraps them in tls.Conns. You want to pass the tls.Conns into the HTTP code, not the net.TCPConns directly. Does this fix your problem?
,
Jul 13
Agreed; as I've mentioned, this could be error in my code, and same-day implementation that I wrote after hitting this error message does indeed have two separate listeners — that solves the problem. There is no errors though, outside the one chrome is displaying. Have you tried separate handlers for HTTP and TLS? I have a brittle suspicion that same listener can be used by two protocols, since the choice is binary: http can't deal with tls and vice versa... I may very well be wrong. Single listener seems to work on Node, that's where I got the idea. I hope either Chromium or 'net/http' codebases can benefit from this inquiry.
,
Jul 13
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 14
Yes, there is an error in your code. I've just described it to you. There is no error in Chrome or Go's crypto/tls package, from what you have described. There is an error in your code. If you believe there is still an error in Chrome or Go's crypto/tls package, please fix the error in your code first. If it works, we'll close this bug. If it doesn't work, please post your fix attempt and we can help you to debug it further. net/http wants a listener that outputs net.Conn. It writes HTTP over it. If the listener gives it a net.TCPConn, you get plaintext HTTP. If it gives a tls.Conn, you get HTTPS. When you give a listener to two different callers, both of them loop calling Accept(), just as if you different callers called the accept() syscall in parallel. Which caller gets which socket is arbitrary. You are clearly trying to implement HTTPS. Your code does not implement HTTPS. It implements a flip-flopping unencrypted HTTP and no-op TLS handshaker. That is not going to work well. You need to pass tlsListener into HTTP. I don't know what you're doing in Node, as you haven't provided that code. It's possible your Node code does not have this bug, or Node's APIs work differently.
,
Jul 17
Reporter@ - Could you please respond to comment #13. Hence, adding label Needs-Feedback. Thanks...!!
,
Jul 25
Closing this, as it's not a Chrome issue. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by em...@ermolay.com
, Jul 10