4 ms·

Back when rustls was initially announced, people criticized how few ciphersuites it supported, like only TLS1.3 and parts of TLS 1.2. Not sure, I might have bee

by est31 6y ago

Back when rustls was initially announced, people criticized how few ciphersuites it supported, like only TLS1.3 and parts of TLS 1.2. Not sure, I might have been among them. And it still doesn't support TLS 1.1 or TLS 1.0. But since then, browsers have dropped support for many of those ciphersuites, so it's far less interesting to implement support for them at this point.

maeln 6y ago
It can be useful if you need to work with legacy system that only support old cipher and protocol. But then I guess there is always openssl and co who still do the job.
- Animats 6y ago
  I had to struggle with this recently. I have to deal with something that uses a root cert generated in 2005, valid to 2025, and signed with 1024-bit RSA. Rustls silently ignores this root cert. I can add it to the root cert store with no complaints, but it will not be used. One problem with Rustls is that the error messages are not very informative. The situation described above just generated an "Invalid certificate" message. More use of anyhow::Context would be helpful. I don't disagree with Rustls disallowing decade-obsolete crypto. It's the "silently ignores" part that's a problem.
  - briansmith 6y ago
    > he situation described above just generated an "Invalid certificate" message. More use of anyhow::Context would be helpful. I don't disagree with Rustls disallowing decade-obsolete crypto. It's the "silently ignores" part that's a problem. Because of how X.509 certificate validation works, in general it's not possible to tell you why an issuer couldn't be found, because there are many possible reasons. Regardless https://github.com/briansmith/webpki/issues/206 https://github.com/briansmith/webpki/issues/206 tracks improving the situation.
    - tialaramex 6y ago
      Brian surely knows this, but for other people's context: Certificates in the Web PKI [and likely in any non-trivial PKI] form a Directed Graph with cycles in it. So "is this end entity certificate trustworthy?" is already a pretty tricky graph problem that you're going to have to solve unless you either out-source the problem entirely to the application (lots of older or toy TLS implementations) or just rely on your peer showing you exactly the right set of certificates matching your requirements (the "chain" you may have seen in tools like Certbot) without you ever saying what those actually are. In a sense it's going to have a big undigestible list of reasons the certificate wasn't found trustworthy, like if you asked grep to tell you why all the non-matching lines in a file don't match a regular expression. "The first letter on this line wasn't a match, and then the second letter wasn't a match, and then the third..." However, as that ticket says, one relatively easy thing the code could do is notice if there was only one consistent reason and if so tell you what that was. Also I agree with several commenters that webpki's current behaviour, in which it says "Unknown issuer" even when that's not the problem at all is undesirable and an even vaguer error might actually be better for these cases. See also, languages in which the parser too easily gets confused and reports "Syntax error" when your syntax was correct but something else is wrong, "Parse failed" is vaguer but at least doesn't gaslight me.
      - briansmith 6y ago
        Are you assuming that the set of certificates that is given as input is the complete search space? It isn't; the server might have failed to send some certificate that, if present, would have fixed the "unknown issuer" problem. Also, we fail fast on errors; as soon as we find a problem, we stop the search on that path. Because of these reasons, identifying a single error would be, potentially, misleading. In some cases, e.g. the end-entity certificate is signed with an algorithm that isn't supported, or an RSA key that is too small, we could add special logic to diagnose that problem. However, all this special diagnostic logic would probably approach the size of the rest of the path building logic itself. It doesn't seem appropriate for something in the core of the TLB of the system. Perhaps at some point in the not-too-distant future we can provide some mode with more diagnostic logic, and find a way to clearly separate this diagnostic logic from the actual validation logic to ensure that the diagnostic logic doesn't influence the result.

by est31 6y ago

maeln 6y ago

It can be useful if you need to work with legacy system that only support old cipher and protocol. But then I guess there is always openssl and co who still do the job.

Animats 6y ago
I had to struggle with this recently. I have to deal with something that uses a root cert generated in 2005, valid to 2025, and signed with 1024-bit RSA. Rustls silently ignores this root cert. I can add it to the root cert store with no complaints, but it will not be used. One problem with Rustls is that the error messages are not very informative. The situation described above just generated an "Invalid certificate" message. More use of anyhow::Context would be helpful. I don't disagree with Rustls disallowing decade-obsolete crypto. It's the "silently ignores" part that's a problem.
- briansmith 6y ago
  > he situation described above just generated an "Invalid certificate" message. More use of anyhow::Context would be helpful. I don't disagree with Rustls disallowing decade-obsolete crypto. It's the "silently ignores" part that's a problem. Because of how X.509 certificate validation works, in general it's not possible to tell you why an issuer couldn't be found, because there are many possible reasons. Regardless https://github.com/briansmith/webpki/issues/206 https://github.com/briansmith/webpki/issues/206 tracks improving the situation.
  - tialaramex 6y ago
    Brian surely knows this, but for other people's context: Certificates in the Web PKI [and likely in any non-trivial PKI] form a Directed Graph with cycles in it. So "is this end entity certificate trustworthy?" is already a pretty tricky graph problem that you're going to have to solve unless you either out-source the problem entirely to the application (lots of older or toy TLS implementations) or just rely on your peer showing you exactly the right set of certificates matching your requirements (the "chain" you may have seen in tools like Certbot) without you ever saying what those actually are. In a sense it's going to have a big undigestible list of reasons the certificate wasn't found trustworthy, like if you asked grep to tell you why all the non-matching lines in a file don't match a regular expression. "The first letter on this line wasn't a match, and then the second letter wasn't a match, and then the third..." However, as that ticket says, one relatively easy thing the code could do is notice if there was only one consistent reason and if so tell you what that was. Also I agree with several commenters that webpki's current behaviour, in which it says "Unknown issuer" even when that's not the problem at all is undesirable and an even vaguer error might actually be better for these cases. See also, languages in which the parser too easily gets confused and reports "Syntax error" when your syntax was correct but something else is wrong, "Parse failed" is vaguer but at least doesn't gaslight me.
    - briansmith 6y ago
      Are you assuming that the set of certificates that is given as input is the complete search space? It isn't; the server might have failed to send some certificate that, if present, would have fixed the "unknown issuer" problem. Also, we fail fast on errors; as soon as we find a problem, we stop the search on that path. Because of these reasons, identifying a single error would be, potentially, misleading. In some cases, e.g. the end-entity certificate is signed with an algorithm that isn't supported, or an RSA key that is too small, we could add special logic to diagnose that problem. However, all this special diagnostic logic would probably approach the size of the rest of the path building logic itself. It doesn't seem appropriate for something in the core of the TLB of the system. Perhaps at some point in the not-too-distant future we can provide some mode with more diagnostic logic, and find a way to clearly separate this diagnostic logic from the actual validation logic to ensure that the diagnostic logic doesn't influence the result.