Handling signature_algorithm extension on TLS1.3 server
rashok.svks at gmail.com
Fri Jun 7 12:42:26 UTC 2019
> This was an area of some ambiguity in the TLSv1.2 spec where only
> signature_algorithms exists. I believe it was common practice for
> implementations to not check the signatures in certificates for
> conformance with
> this (certainly that is the way OpenSSL behaves). The TLSv1.3 spec seems
> to be
> more explicit about this. I would expect our TLSv1.2 implementation to
> to operate as it did before so this additional checking of signatures in
> certificates where only the signature_algorithms extensions is present
> only apply to TLSv1.3.
> I don't see any code to do this in has_usable_cert so this looks like a
> potential bug. Although possibly it was left out on purpose.
Yes. Currently this check is missing for both TLSv1.2 and TLSv1.3. I feel
we may need to add for both TLSv1.2 and TLSv1.3, because TLSv1.2 RFC 5246
also mandates to do this check.
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension.
Fix should be something like
Atleast we should add this check for TLSv1.3. Otherwise cert with
rsa_pkcsv1_5_xxx signature getting selected even if client has not included
rsa_pkcsv1_5_xxx in signature_algorithm ext, but included rsa_pss_rsae_xxx.
This looks weird.
Apart from this I am having one more doubt, that TLSv1.3 RFC 8446 says
certificate with legacy signature(rsa_pkcsv1_5_sha1 and ecdsa_sha1) can be
selected if no other valid certificate present on TLS1.3 server. But in
tls_choose_sigalgs() function for TLSv1.3 we are currently skipping all
SHA1 based and RSA_PKCSv1_5 based signature algorithm. I feel instead of
avoiding we should consider as a low priority in this function for
selecting legacy certificates with rsa_pkcsv1_5 and ecdsa_sha1.
TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless
no valid certificate chain can be produced without it (see
Section 18.104.22.168 <https://tools.ietf.org/html/rfc8446#section-22.214.171.124>).
> Ben Kaduk may have a view on this who implemented this code:
And also requesting Ben Kaduk to put some light on it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users