I am going to go have a look myself but would appreciate the head start.
Edit: I found these but they don't seem super terrible and are fixed in the versions of Go most people are using: https://www.cvedetails.com/vulnerability-list/vendor_id-1418...
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".
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.
* Golang's TLS stack is far less complex in comparison to other projects.
* Golang's TLS stack is written in a "safe" language.
* 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.
Why do you believe the inverse is true?
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 =)