4 ms·

Btw, can someone explain to me how revocation interacts with certificate pinning?

ikeboy 11y ago
Quick search turns up a proposal to deal with it https://www.ietf.org/mail-archive/web/websec/current/msg00506.html https://www.ietf.org/mail-archive/web/websec/current/msg0050... (but hasn't been implemented in the actual standard, see below). Revocation In the event of pin mismatch, clients MUST check whatever revocation mechanism is available, and attempt to discover whether the certificate with the mismatching fingerprint has been revoked. For example: offending_certificate = cert in certificate_chain where cert.public_key.fingerprint == mismatched_fingerprint revoked = offending_certificate.serial_number in revoked_serials If the offending certificate has been revoked, it is unpinned and the UA can re-evaluate the pin list. If there are no pinned fingerprints left on the pin list, the browser downgrades the host from Known Pinned HSTS Host to Known HSTS Host. The revocation mechanism could be an extant mechanism such as CRL or OCSP, or a new one such as browser updates, whitelists, blacklists, or an in-built CRL. This document is agnostic about the revocation mechanism(s) UAs may use. Un-pinning Certificates that are invalidated for any reason and by any means -- revocation by extant or future means, expiration, blacklisting -- are effectively removed from the pin list. Certificates whose intermediary or root signers are revoked are also effectively invalidated and removed from the pin list. HSTS Hosts can un-set pins in clients (un-pin) by setting a pins directive that contains no pins. UAs MUST NOT obey the un-pinning directive unless the empty pins directive is set on a response in a TLS connection that was authenticated with one of the previously pinned public keys. This doesn't seem to have made it into the standard, though: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02#section-7.3 https://tools.ietf.org/html/draft-ietf-websec-strict-transpo... says When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 10 "UA Implementation Advice", below) if there are any errors (e.g. certificate errors), whether "warning" or "fatal" or any other error level, with the underlying secure transport. This includes any issues with certificate revocation checking whether via the Certificate Revocation List (CRL) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC5280]. and https://tools.ietf.org/html/rfc6797#section-8.4 https://tools.ietf.org/html/rfc6797#section-8.4 says When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking that UAs employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via TLS server identity checking [RFC6125].
- daurnimator 11y ago
  Thanks :) I wonder if this has actually been implemented correctly... Sudden revocation of a TLD will probably result in a sudden hammering of the CA's revocation servers too. I imagine an icky failure cascade is happening for some unfortunate user
  - ikeboy 11y ago
    In case you didn't see my edit, this behavior (revoke key pin if cert was revoked) is not in the standards, only proposed. The standards say the opposite.
    - daurnimator 11y ago
      In that case; ouch!

Quick search turns up a proposal to deal with it https://www.ietf.org/mail-archive/web/websec/current/msg00506.html https://www.ietf.org/mail-archive/web/websec/current/msg0050... (but hasn't been implemented in the actual standard, see below). Revocation In the event of pin mismatch, clients MUST check whatever revocation mechanism is available, and attempt to discover whether the certificate with the mismatching fingerprint has been revoked. For example: offending_certificate = cert in certificate_chain where cert.public_key.fingerprint == mismatched_fingerprint revoked = offending_certificate.serial_number in revoked_serials If the offending certificate has been revoked, it is unpinned and the UA can re-evaluate the pin list. If there are no pinned fingerprints left on the pin list, the browser downgrades the host from Known Pinned HSTS Host to Known HSTS Host. The revocation mechanism could be an extant mechanism such as CRL or OCSP, or a new one such as browser updates, whitelists, blacklists, or an in-built CRL. This document is agnostic about the revocation mechanism(s) UAs may use. Un-pinning Certificates that are invalidated for any reason and by any means -- revocation by extant or future means, expiration, blacklisting -- are effectively removed from the pin list. Certificates whose intermediary or root signers are revoked are also effectively invalidated and removed from the pin list. HSTS Hosts can un-set pins in clients (un-pin) by setting a pins directive that contains no pins. UAs MUST NOT obey the un-pinning directive unless the empty pins directive is set on a response in a TLS connection that was authenticated with one of the previously pinned public keys. This doesn't seem to have made it into the standard, though: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02#section-7.3 https://tools.ietf.org/html/draft-ietf-websec-strict-transpo... says When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 10 "UA Implementation Advice", below) if there are any errors (e.g. certificate errors), whether "warning" or "fatal" or any other error level, with the underlying secure transport. This includes any issues with certificate revocation checking whether via the Certificate Revocation List (CRL) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC5280]. and https://tools.ietf.org/html/rfc6797#section-8.4 https://tools.ietf.org/html/rfc6797#section-8.4 says When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking that UAs employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via TLS server identity checking [RFC6125].

daurnimator 11y ago
Thanks :) I wonder if this has actually been implemented correctly... Sudden revocation of a TLD will probably result in a sudden hammering of the CA's revocation servers too. I imagine an icky failure cascade is happening for some unfortunate user
- ikeboy 11y ago
  In case you didn't see my edit, this behavior (revoke key pin if cert was revoked) is not in the standards, only proposed. The standards say the opposite.
  - daurnimator 11y ago
    In that case; ouch!