5 ms·

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

by maeln 5y 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 5y 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 5y 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 5y 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 5y 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.
      - tialaramex 5y ago
        No, I'm pretty sure I wasn't assuming that, and I'm not sure what gave you that impression from what I wrote. There are a variety of interesting strategies to decide that an end entity certificate you were shown is trustworthy, and you're presumably aware that Mozilla (in Firefox) eventually chose to go with a strategy of * Requiring all root CAs to disclose intermediate CAs as part of their root programme * Bundling this set with Firefox Whereupon Firefox gets to decide whether the end entity certificate it was shown was issued by one of these trustworthy intermediates and short cut to a "Yes" answer regardless of which certificates, if any, the server included in the supplied "chain". In the general case this isn't very applicable, but I note that webpki is named "webpki" and not "General purpose certificate validator" so actually it could go the same route (with the caveat that this needs frequent updates to avoid surprises with very new CAs) Mostly though if you're quite determined not to introduce more complicated logic into webpki (which is understandable) I specifically don't like the gaslighting of saying "unknown issuer" as I said, when the reality is that you don't know why you don't trust the certificate, so say that. If std::fs::File::open() gives me Result with an io:Error that claims "File not found" but the underlying OS file open actually failed due to a permission error, you can see why that's a problem right? Even if this hypothetical OS doesn't expose any specific errors, "File not found" is misleading.

by maeln 5y 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 5y 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 5y 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 5y 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 5y 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.
    - tialaramex 5y ago
      No, I'm pretty sure I wasn't assuming that, and I'm not sure what gave you that impression from what I wrote. There are a variety of interesting strategies to decide that an end entity certificate you were shown is trustworthy, and you're presumably aware that Mozilla (in Firefox) eventually chose to go with a strategy of * Requiring all root CAs to disclose intermediate CAs as part of their root programme * Bundling this set with Firefox Whereupon Firefox gets to decide whether the end entity certificate it was shown was issued by one of these trustworthy intermediates and short cut to a "Yes" answer regardless of which certificates, if any, the server included in the supplied "chain". In the general case this isn't very applicable, but I note that webpki is named "webpki" and not "General purpose certificate validator" so actually it could go the same route (with the caveat that this needs frequent updates to avoid surprises with very new CAs) Mostly though if you're quite determined not to introduce more complicated logic into webpki (which is understandable) I specifically don't like the gaslighting of saying "unknown issuer" as I said, when the reality is that you don't know why you don't trust the certificate, so say that. If std::fs::File::open() gives me Result with an io:Error that claims "File not found" but the underlying OS file open actually failed due to a permission error, you can see why that's a problem right? Even if this hypothetical OS doesn't expose any specific errors, "File not found" is misleading.