You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If tls.Config.CipherSuites is set with an invalid sequence and the http.Server.TLSConfig is set with it, the http.Server.Serve method returns an error.
Since http.Server.Start will update the http.Server.TLSConfig if it can, why http.Server.Serve method doesn't returns an error when an invalid cipher sequence is used like on the following example?
why http.Server.Serve method doesn't returns an error when an invalid cipher sequence is used like on the following example?
Because you used different *tls.Config values for the http.Server and the TLS listener you manually created and passed to http.Server.Serve(net.Listener). Note that crypto/tls.NewListener doesn't return an inspectable type. The http package can't tell that what its TLS config is.
There's not much we can do here. At least we'll catch it later at connection accept time. Good enough.
What you can do though is not pass different TLS configs. Or just use ListenAndServeTLS and don't worry about creating your own listener.
Yap, thanks @bradfitz for confirming this. I tried solving this last weekend but in vain with the same conclusion that we can inspect the listener from crypto/tls.NewListener.
If tls.Config.CipherSuites is set with an invalid sequence and the http.Server.TLSConfig is set with it, the http.Server.Serve method returns an error.
Since http.Server.Start will update the http.Server.TLSConfig if it can, why http.Server.Serve method doesn't returns an error when an invalid cipher sequence is used like on the following example?
http://play.golang.org/p/KGe4oi_6Eh
The text was updated successfully, but these errors were encountered: