Comments (6)
Thank you, both. Your work is much appreciated
from rustls.
So just adding some information here from what I've dug into so far:
Signature algorithms offered by the ring-based client:
Signature algorithms offered by the aws-lc-rs-based client:
The increase in algorithms here makes sense due to aws-lc-rs offering a larger set of supported algoirthms in its signature module.
The corresponding Go server key exchange message for a ring client:
The corresponding Go server key exchange message for aws-lc-rs client:
What has me a bit puzzled though is why the Go server in both these instances is offering a signature algorithm to the client that can't be used with the certificate? My understanding is that the signature offered in the key exchange message is supposed to be a signed message of the key exchange parameters using ECDSA using p256r1 w/ SHA256 given that the private key is a p256r1 key and that scheme matches the certificate. So why is the Go server offering p384 and p521 in both instances if that doesn't match the servers private key? Interesting that it succeeds with the ring. Or is Wireshark just lying here and really this is just two bytes that specify the digest algorithm and digital signature scheme.
Attaching the debugger on the failure case confirms this is the failure case: https://github.com/rustls/rustls/blob/main/rustls/src/client/tls12.rs#L897. The actual error being returned is UnsupportedSignatureAlgorithmForPublicKey
from here.
From rfc4492 section 2.2:
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
capable public key and be signed with ECDSA.The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.The client generates an ECDH key pair on the same curve as the
server's ephemeral ECDH key and sends its public key in the
ClientKeyExchange message.Both client and server perform an ECDH operation (Section 5.10) and
use the resultant shared secret as the premaster secret.
Of course it is possible I have a gap in my knowledge here, but figured I'd drop some information of what I had seen so far.
Update: I believe this is likely the intended behavior for TLS 1.2, in that the digest algorithm isn't bound to a specific key size. See this comment from the Go TLS implementation: https://github.com/golang/go/blob/master/src/crypto/tls/auth.go#L182-L192
from rustls.
Ah I see since aws-lc-rs doesn't expose SHA512 for the other curves that is creating an issue. Let me revisit that and get back to you, I'm not seeing an immediate reason why we wouldn't allow SHA512 with the non-p521 curves.
Update
I think the direction you have chosen for the fix is likely the best path forward given that you only recently extended support for SHA512.
There is a few online discussions that are of interest around this topic of why you may not want to use larger digest sizes with the smaller keys in addition to reusing the same key across different digest algorithms:
https://groups.google.com/g/mozilla.dev.security.policy/c/mCKvUmYUMb0/m/VVW_eSNrCAAJ
https://groups.google.com/a/chromium.org/g/security-dev/c/SlfABuvvQas/m/qOil2X4UBQAJ
In Go's fixed preference order for signature algorithms in clients ECDSA SHA512 is actually ranked lower in priority then SHA256 and SHA384 similar to your change here. I imagine these concerns are largely why TLS 1.3 binds the digest used to a specific key size.
from rustls.
Thanks for filing this issue. It sounds interesting and having a repro is a big help (even if its on the larger side). I won't have a chance to investigate for a little while but wanted to leave a comment so you knew it's on our radar.
from rustls.
Had a short look at this and it looks like there are no relevant TLS-level differences between the providers. Next step is to minimise the reproducer to just the signature verification, then we can send it upstream.
from rustls.
Ah, thanks for the detailed look!
I agree on your conclusion, and I think it means that offering ecdsa_secp521r1_sha512
for TLS1.2 & TLS1.3 implies support for SHA512 signatures for all supported curves on TLS1.2. That is very annoying!
That previously wasn't an issue, because the set of hash functions we were willing to do verifications for {SHA256, SHA384} were supported for each curve.
from rustls.
Related Issues (20)
- GHSA-6g7w-8wpp-frhj and CVE-2024-32650 don't make it clear that async rustls servers aren't susceptible HOT 2
- Rustls w/ aws-lc-rs on Windows requires NASM HOT 33
- Making impl ClientHelloPayload public ? HOT 21
- Question. Does rustls have something to hide cert (as it is sensitive data ) in binary and memory HOT 3
- Verify that SigningKey matches public key within certificate HOT 6
- Ensuring that a provider based on the one built-in is used HOT 8
- Compile error when target is watchos HOT 6
- Expose ability to customize ClientHello message HOT 4
- How I use CryptoProvider::install_default() ? HOT 3
- Illegal instruction on arm-a72 HOT 3
- Add RustCrypto cryptographic backend HOT 5
- Build rustls v0.23.5 with musl HOT 2
- UnbufferedConnectionState HOT 2
- Unbuffered process_tls_records does not mach usage scenario HOT 2
- Clean up crate feature naming
- build failure due to aws-lc-sys v0.16.0 HOT 1
- `UnknownIssuer` with self-signed certificate HOT 2
- poll based encrypt/decrypt/sign api to support both async and sync call HOT 6
- Server-side Encrypted Client Hello (ECH) support
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rustls.