<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>This was an area of some ambiguity in the TLSv1.2 spec where only<br>
signature_algorithms exists. I believe it was common practice for<br>
implementations to not check the signatures in certificates for conformance with<br>
this (certainly that is the way OpenSSL behaves). The TLSv1.3 spec seems to be<br>
more explicit about this. I would expect our TLSv1.2 implementation to continue<br>
to operate as it did before so this additional checking of signatures in<br>
certificates where only the signature_algorithms extensions is present should<br>
only apply to TLSv1.3.<br>
<br>
I don't see any code to do this in has_usable_cert so this looks like a<br>
potential bug. Although possibly it was left out on purpose.<br></blockquote><div><br></div><div>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.</div><div><br></div><div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">   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.</pre></div><div><br></div><div>Fix should be something like <a href="https://github.com/raja-ashok/openssl/commit/2eb916d6048f54fd6109329d31850f8eb4407780">https://github.com/raja-ashok/openssl/commit/2eb916d6048f54fd6109329d31850f8eb4407780</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">      TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless
      no valid certificate chain can be produced without it (see
      <a href="https://tools.ietf.org/html/rfc8446#section-4.4.2.2">Section 4.4.2.2</a>).</pre></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Ben Kaduk may have a view on this who implemented this code:<br>
<br>
<a href="https://github.com/openssl/openssl/pull/5068/commits/e639c37bddea48334cb45d88d407c655641e1a35" rel="noreferrer" target="_blank">https://github.com/openssl/openssl/pull/5068/commits/e639c37bddea48334cb45d88d407c655641e1a35</a><br><br></blockquote><div><br></div><div>And also requesting Ben Kaduk to put some light on it. </div></div></div>