Regarding older SSL-support in go-lang
Josef Johansson
In short, I wonder what the current status and planning for
SSL-support in Go is. I have heard that it has been some discussion
about it lately, but can't find any reference to it.
I have developed a small patch for SSLv23 support, but agl
said that as SSLv2 is so old, he does not want it in the standard
library. Which I get is the consensus of most people.
In all my attempts to use Go, my implementations fail because of old
clients not supporting SSLv3+, ranging from old phones to other
clients that I have to support or that I can't modify. The internet
lives much in the past still, even if the implementation of SSLv2 is
long due to be removed. We're trying to decide how we should plan
future implementations and would hope to get a direction of what
support will be in Go 1 and beyond for SSLv2 and SSLv23.
Cheers,
Josef
Adam Langley
> In all my attempts to use Go, my implementations fail because of old
> clients not supporting SSLv3+, ranging from old phones to other
> clients that I have to support or that I can't modify. The internet
> lives much in the past still, even if the implementation of SSLv2 is
> long due to be removed. We're trying to decide how we should plan
> future implementations and would hope to get a direction of what
> support will be in Go 1 and beyond for SSLv2 and SSLv23.
To be clear: I think the problem here is not the clients don't support
SSLv3 and above, but that they are using an SSLv2 compatible
handshake. This is basically an SSLv2 handshake that advertises
support for SSLv3/TLS and serves only to upgrade to SSLv3/TLS.
I think the lack of support for quirks such as that serves two purposes:
Firstly, it keeps the library code cleaner. There are a very large
number of odd corners in SSL/TLS that I'm not keen to workaround. For
a (very) incomplete list, see [1].
Secondly, and perhaps more importantly, if you get to the point where
you're seeing these issues then it's probably time to put your service
behind something else to do the SSL/TLS termination. It's unfortunate,
but the stack of packages leading up to crypto/tls has never been
seriously attacked. Although Go's memory safety excludes whole classes
of exploits, I'm not perfect and RSA, in particular, is full of razor
edges for the implementer. Also the RSA and elliptic code (with the
exception of P224) is not constant time, although the RSA code is
blinded.
Putting your service behind something using OpenSSL, even though the
OpenSSL code itself is an abomination to look at, gets you all the
quirks necessary to support any client, a fair speed up and well
studied and attacked code.
[1] http://www.imperialviolet.org/2011/02/04/oppractices.html
Cheers
AGL
Norbert Roos
> clients not supporting SSLv3+, ranging from old phones to other
> clients that I have to support or that I can't modify.
It's even not always old clients. Unless it changed in the last couple
of month, the current Safari browser is still doing only SSL2
connections for websockets..
Norbert
Jason Swank
Putting your service behind something using OpenSSL, even though the
OpenSSL code itself is an abomination to look at, gets you all the
quirks necessary to support any client, a fair speed up and well
studied and attacked code.