3 ms·

> Go TLS does not support hardware accelerated crypto. Go uses AES-NI instructions on amd64 when available http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s

by tagrun 12y ago

> Go TLS does not support hardware accelerated crypto. Go uses AES-NI instructions on amd64 when available http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s > Go TLS does not have wide support for backwards compatibility with less secure and older protocol versions (a good thing, until you have no other option). LibreSSL people beg to differ about this "feature". > Go TLS does not give much control over the certificate validation process, which makes it difficult or impossible to add additional checks and validations. What exactly is this about? > Oh, and Go TLS is vulnerable to timing attacks. A mitigation is in WIP https://codereview.appspot.com/94850043 https://codereview.appspot.com/94850043

jtolds 12y ago
AES-NI doesn't work on ARM, which is what we have. >> Go TLS does not have wide support for backwards compatibility with less secure and older protocol versions (a good thing, until you have no other option). > LibreSSL people beg to differ about this "feature". Agreed agreed! Don't use old protocols! >> Go TLS does not give much control over the certificate validation process, which makes it difficult or impossible to add additional checks and validations. > What exactly is this about? OpenSSL allows you to specify your own validation callback, to add additional checks to the certificate validation step. The only certificate validation option Go's TLS gives you is either InsecureSkipVerify or not. >> Oh, and Go TLS is vulnerable to timing attacks. > A mitigation is in WIP https://codereview.appspot.com/94850043 https://codereview.appspot.com/94850043 awesome!
- tagrun 12y ago
  > AES-NI doesn't work on ARM, which is what we have. I'm afraid this falls into scope of the low-priority issue 4299 then: https://code.google.com/p/go/issues/detail?id=4299 https://code.google.com/p/go/issues/detail?id=4299 > OpenSSL allows you to specify your own validation callback, to add additional checks to the certificate validation step. The only certificate validation option Go's TLS gives you is either InsecureSkipVerify or not. I'm not sure about the necessity or the details of the particular use case, but if it is general enough, you can file an issue.
  - jtolds 12y ago
    Thanks for the pointer to #4299. Unfortunately, custom asm isn't going to be nearly as fast as what we're doing, but I left a comment to that affect. As for adding options to Go TLS, it is worth filing an issue for sure. Go 1 compatibility guarantee (and resulting standard library interface freeze) definitely restricts options here, but yeah I'll look into it.

by tagrun 12y ago

jtolds 12y ago

AES-NI doesn't work on ARM, which is what we have. >> Go TLS does not have wide support for backwards compatibility with less secure and older protocol versions (a good thing, until you have no other option). > LibreSSL people beg to differ about this "feature". Agreed agreed! Don't use old protocols! >> Go TLS does not give much control over the certificate validation process, which makes it difficult or impossible to add additional checks and validations. > What exactly is this about? OpenSSL allows you to specify your own validation callback, to add additional checks to the certificate validation step. The only certificate validation option Go's TLS gives you is either InsecureSkipVerify or not. >> Oh, and Go TLS is vulnerable to timing attacks. > A mitigation is in WIP https://codereview.appspot.com/94850043 https://codereview.appspot.com/94850043 awesome!

tagrun 12y ago
> AES-NI doesn't work on ARM, which is what we have. I'm afraid this falls into scope of the low-priority issue 4299 then: https://code.google.com/p/go/issues/detail?id=4299 https://code.google.com/p/go/issues/detail?id=4299 > OpenSSL allows you to specify your own validation callback, to add additional checks to the certificate validation step. The only certificate validation option Go's TLS gives you is either InsecureSkipVerify or not. I'm not sure about the necessity or the details of the particular use case, but if it is general enough, you can file an issue.
- jtolds 12y ago
  Thanks for the pointer to #4299. Unfortunately, custom asm isn't going to be nearly as fast as what we're doing, but I left a comment to that affect. As for adding options to Go TLS, it is worth filing an issue for sure. Go 1 compatibility guarantee (and resulting standard library interface freeze) definitely restricts options here, but yeah I'll look into it.