No, I do not. Unfortunately that's no guarantee they're not around though :(.
All the data on this is extremely old and no one seems to recently have done a deep-dive into Go's TLS stack. I really hope someone will (or that Google will fund the research themselves). It would be beneficial to the ecosystem to have a thoroughly reviewed implementation and a clear understanding of what the state is.
Right now all I can go on is a statement of the author about 3 years ago, around the time of Go 1.2:
Cryptography is notoriously easy to botch in subtle and surprising ways and I’m only human. I don’t feel that I can warrant that Go’s TLS code is flawless and I wouldn’t want to misrepresent it.
There are a couple of places where the code is known to have side-channel issues: the RSA code is blinded but not constant time, elliptic curves other than P-224 are not constant time and the Lucky13 attack might work. I hope to address the latter two in the Go 1.2 timeframe with a constant-time P-256 implementation and AES-GCM.
Nobody has stepped forward to do a review of the TLS stack however and I’ve not investigated whether we could get Matasano or the like to do it. That depends on whether Google wishes to fund it.
I've also had a discussion with one of the Caddy developers who recommended for production usage to front it with something that does TLS for you, precisely because no one really seems to know the state of TLS in Go. Arguably other TLS implementations have other issues but there's something to be said for "the devil you know".
I would generally expect Go's TLS 1.2 defect rate to be competitive with those of other mainstream TLS implementations. That code is very well regarded and designed by domain experts.
I'm one of the founders of Matasano, and started the crypto practice within Matasano that would have done that Go TLS review, and I can say pretty confidently that compared to the attention Go TLS already gets from experts, the long-term benefit of us reviewing it as a formal project would have been marginal.
Currently being in that crypto practice, and having found the latest CVE on golang that affected their TLS stack (was found in the bignum package), I'm confident of the inverse.
> Golang's TLS stack is far less complex in comparison to other projects.
TLS is the definition of complex =)
> Golang's TLS stack is written in a "safe" language.
Not all bugs are memory corruption bugs.
> Golang's TLS stack is written by individuals with lots of experience in SSL/TLS (and its flaws!)
> Contributions to the project are held to very high standards
True, I would expect the code to be of high quality and the bugs to be sparse. But even knowing this, you always want to have other pair of eyes looking at your code. An audit done by other experts brings a lot to the table.
PS: also, I think an audit would cost a negligible cost to Google =)
I'm not saying having you look at the code would be a bad idea. I'm just pushing back on the notion that the code isn't "ready for prime time" until you do.
Anyone who writes crypto and does not give such a disclaimer is delusional. That makes me more confident, since it means the author respects the problem.
All the data on this is extremely old and no one seems to recently have done a deep-dive into Go's TLS stack. I really hope someone will (or that Google will fund the research themselves). It would be beneficial to the ecosystem to have a thoroughly reviewed implementation and a clear understanding of what the state is.
Right now all I can go on is a statement of the author about 3 years ago, around the time of Go 1.2:
Cryptography is notoriously easy to botch in subtle and surprising ways and I’m only human. I don’t feel that I can warrant that Go’s TLS code is flawless and I wouldn’t want to misrepresent it.
There are a couple of places where the code is known to have side-channel issues: the RSA code is blinded but not constant time, elliptic curves other than P-224 are not constant time and the Lucky13 attack might work. I hope to address the latter two in the Go 1.2 timeframe with a constant-time P-256 implementation and AES-GCM.
Nobody has stepped forward to do a review of the TLS stack however and I’ve not investigated whether we could get Matasano or the like to do it. That depends on whether Google wishes to fund it.
https://blog.golang.org/a-conversation-with-the-go-team
I've also had a discussion with one of the Caddy developers who recommended for production usage to front it with something that does TLS for you, precisely because no one really seems to know the state of TLS in Go. Arguably other TLS implementations have other issues but there's something to be said for "the devil you know".