3 ms·
Totally. I'd love to see crypto/tls fixed. Until then, though, I'd rather not choose the option with known, existing attack vectors. Too bad it took such a hor
by jtolds 12y ago
Totally. I'd love to see crypto/tls fixed. Until then, though, I'd rather not choose the option with known, existing attack vectors.
Too bad it took such a horrible bug to shake everyone into auditing these libraries.
Edit: fwiw, the hw acceleration is a pretty big deal for us. We have little ARM devices.
- tptacek 12y agoAre you working from the presumption that Golang crypto/tls admits practical side-channel attacks and OpenSSL doesn't? I would question that assumption. Again: if I had to make a recommendation between the two, then from a security perspective I'd lean crypto/tls. Regardless, if I was stuck on hardware acceleration, I'd probably stick a reverse proxy in front of my Golang code before I incorporated an OpenSSL Golang binding.
- jtolds 12y agoHaving a separate process for SSL termination is of course completely doable, but was a little more challenging. We use client-side certificates for application level authentication logic, so we would have needed to side-channel the authentication information from our reverse proxy to our app. Again, completely, totally doable, was just harder for our transliteration project [1]. Good advice. [1] https://www-staging.spacemonkey.com/blog/posts/go-space-monkey https://www-staging.spacemonkey.com/blog/posts/go-space-monk...