New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto/tls: Available ciphers list lacks AES-256 and SHA-2 based combination #9894
Comments
Compare with openSSL's available cipher list. Several good options available: https://www.openssl.org/docs/apps/ciphers.html#tls_v1_2_cipher_suites IANA's List for comparison: http://www.iana.org/assignments/tls-parameters/tls-parameters.xml |
Is AES-256-GCM not sufficient? |
(Preemptively closing this because the initial premise, that we don't support AES-256+SHA-2, is incorrect. You can still followup if I've misunderstood something.) |
You are incorrect, and the premise that AES-256+SHA-2 is not supported is correct. You can see this very very clearly if you read the crypto/tls.go and take a look at how the ciphersets are being built. There isn't any possible way that the code used in crypto/tls.go ever calls SHA-2 functions from crypto/sha2whatever. SHA-2 libraries are not ever even imported. You can also verify this using a very simple approach. Using a very helpful testing script found from superuser.com (http://superuser.com/questions/109213/is-there-a-tool-that-can-test-what-ssl-tls-cipher-suites-a-particular-website-of), against simple ListenAndServeTLS, ignoring all other considerations such as key agreement protocols and ssl/TLS version (neither of the implementations seem to be really picky about that, doesn't change the results) the results are in fact following. Commonly compliant combinations:
Ok. There are couple on that list you probably shouldn't use in real life. The point is however: Not single AES-256 and SHA-2 based combination is supported by crypto/tls. You can't even force such combination by configuring net/http and crypto/tls, the required implementation details are simply missing from crypto/tls.go. Commonly noncompliant combinations:
|
@flaggid7 Are you reading old source? https://github.com/golang/go/blob/master/src/crypto/tls/key_agreement.go#L115 |
@flaggid7, what is your conclusion on this? I see the ticket remains Closed. I'm finding finance houses are offering these four due to their corporate policies and so I can't connect to them.
These two are the closest in cipherSuites, but are SHA1. {TLS_RSA_WITH_AES_128_CBC_SHA, 16, 20, 16, rsaKA, 0, cipherAES, macSHA1, nil},
{TLS_RSA_WITH_AES_256_CBC_SHA, 32, 20, 16, rsaKA, 0, cipherAES, macSHA1, nil}, It does seem as if crypto/tls's users should be able to specify suites, or else the default list should be bigger even if there are many that are suiteDefaultOff to allow the caller to specify them. @agl, please correct me if I've got the wrong end of the stick. |
Based on the above, it does seem that we could reasonably offer |
CL https://golang.org/cl/16924 mentions this issue. |
…256_GCM_SHA384 cipher suites Fixes golang#9894. Change-Id: I9c7ce771df2e2d1c99a06f800dce63c4e1875993 Reviewed-on: https://go-review.googlesource.com/16924 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
…256_GCM_SHA384 cipher suites Fixes golang#9894. Change-Id: I9c7ce771df2e2d1c99a06f800dce63c4e1875993 Reviewed-on: https://go-review.googlesource.com/16924 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
The available ciphers list lacks an option with the combination of AES-256 and SHA-2. As far as I can tell there are only AES-256 options with SHA-1, and AES-128 options with SHA-2.
This is a problem because many companies (and government organizations) have cryptographic guidelines, of which most are starting to forbid SHA-1 and AES-128 based combinations. For those organizations the lack of suitable combination is a blocker for usage of crypto/TLS. (You can't negotiate with compliance people, they are a bit like terrorists, unfortunately.)
For example:
I build integration APIs that use client certificate authentication. I am going to be soon simply forbidden to use Go for that. I could add an extra web server (Apache, nginx, .. name your poison) but then the problem would be how I could absolutely reliably authenticate the web server against the API server. The most reliable method would be again mutual certificate authentication, requiring again AES-256 and SHA-2... Also, bringing in 3rd party library or daemon sounds too heavy solution for maintenance for me, requiring audit & accreditation process...
The text was updated successfully, but these errors were encountered: