Re: [websec] HPKP and Certificate Revocation Check

["Ryan Sleevi" <[e-mail]>]

On Thu, May 2, 2013 2:50 am, vinod kumar wrote:
>  Hi,
>
>  I would like to discuss a possible vulnerability in Public Key Pinning
>  scheme (http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ ),
>  related to certificate revocation checking. I would appreciate if anybody
>  can review and verify my observations.
>
>  Section 2.6 the draft states that when the UA connects to a pinned host,
>  it
>  must terminate the TLS connection, if there are any errors. The referred
>  rfc, RFC 6797, clarifies that error could be related to certificate
>  revocation checking or server identity checking.
>
>  But it is not mandatory that during TLS handshake, UA performs certificate
>  revocation or an assertive answer is found about the revocation status of
>  the certificate. The reasons could be:
>
>  1.      OCSP is disabled by default at the UA and the user has not changed
>  it.
>
>  2.      OCSP checking is disabled by the user.
>
>  3.      OCSP check is performed but no answer is obtained from the OCSP
>  server within the stipulated timeout.
>
>  So it is very much possible that the UA accepts the PKP header from the
>  host without verifying the revocation status of the host certificate used
>  in TLS handshake.
>
>  In the case of the host losing its private key to an attacker, the
>  attacker
>  may be able to block the host permanently from connecting to the UA, as
>  explained below. The host’s CA would have revoked the certificate but the
>  unreliability in revocation checking creates a vulnerability.
>
>  Suppose an attacker is in possession of the private key of the host and
>  the
>  host certificate is duly revoked by the issued CA. Attacker may succeed in
>  diverting the UA to his server when UA tries to connect to the valid host.
>  Attacker may mount a DNS attack or a MIM attack to achieve this. Since he
>  posses the valid private key, the TLS connection will be successful. The
>  only other thing he needs is that UA doesn’t get to know the revocation
>  status of the certificate. Here, the attacker is able to make the UA
>  accept
>  whatever PKP headers sent in the HTTP response.
>
>  Say, the attacker has two key pairs, KeyPair1 and Keypair2, and holds a
>  valid certificate for KeyPair1.
>
>  He constructs a PKP header,
>
>  Public-Key-Pins: max-age= (maximum possible value);
>
>                 pin-sha1= (pin corresponding to compromised key);
>
>                 pin-sha1= (pin corresponding to KeyPair1);
>
>  When UA accepts this PKP header, effectively the attacker is able to set a
>  new backup pin.
>
>  The attacker can set a new PKP header in subsequent connection. He can use
>  KeyPair1 in the TLS handshake.
>
>  Public-Key-Pins: max-age= (maximum possible value);
>
>                 pin-sha1= (pin corresponding to KeyPair1);
>
>                 pin-sha1= (pin corresponding to KeyPair2);
>
>  Now the UA sets both pins to be attacker’s pins and the valid host is
>  permanently blocked from connecting to the UA.
>
>  To avoid this attack, shouldn’t we mandate revocation checking when PKP
>  headers are accepted?
>
>
>  Thanks,
>
>  Vinod.

This attack exists even if you're not in possession of the server's
private key - you may have obtained a fraudulently issued certificate for
a site that wasn't using HPKP already, an attack that's been discussed at
some length so far.

If I understand your proposal correctly, you would see UAs establish an
SSL/TLS connection, send a request (which may include sensitive data that
is otherwise desired to be protected - such as cookies), and then on
receipt of the request, when the server sends back an HPKP header, perform
a secondary revocation check?

1) What if the user has explicitly disabled revocation checking
2) I'm assuming you mean "revocation checking in hard(est) fail(ure)
mode", since anything short of that would be pointless, given all the
attacks that trivially exist.

If we think about the risk/benefits carefully - from the side of the
attacker, the site operator who deploys HPKP, the site operator that
doesn't deploy HPKP, and the user - I think the solution is much less
compelling.

>From the attacker:
- Strengths
 * Attacker can DOS a site by deploying a malicious HPKP header
- Weaknesses
 * Deploying an HPKP header would force revocation checking, potentially
revealing their attack. However, by simply *not deploying an HPKP
header*, their attack MAY not be noticed (even by clients who DO
revocation checking)
 * It requires some form of privileged connection/MITM to deploy. An
attacker with such a position can equally DOS a site at lower layers in
the protocol.
- Questions:
 * Whether or not the window of time that an attacker can DOS a site via
HPKP is less than, equal to, or greater than the window of time that an
attacker can DOS a site via lower-level protocol. This is the ongoing
max-age discussion.

>From the site operator who deploys HPKP:
- Strengths:
 * None particular over HPKP
- Weaknesses:
 * Users will pay significant additional latency costs when connecting to
a site, and a non-trivial percentage of users will outright fail. This is
(one of) the many reasons why administrators and user agents have
disabled revocation checking to begin with.
- Question:
 * Whether the security advantages of HPKP and the attack(s) they guard
against (eg: misissuance) are worth the significant tradeoffs in
performance and reachability.

>From the site operator who doesn't deploy HPKP:
- Strengths:
 * An attacker who attempts to deploy an HPKP header with a revoked
certificate will be prevented.
- Weaknesses:
 * As noted, the attacker can simply choose not to deploy the HPKP header
and continue unimpeded.

>From the user's perspective:
- Strengths:
 * None particular for the user (since, as noted above, sensitive
information will already be disclosed in the HTTP stream)
- Weaknesses:
 * The increased unreliability (due to hard-fail) may condition users to
clear pinning data [on a per-site or global basis], as a "get things
working" last effort, thus undermining many of the security benefits of
pinning.


Because of this, it seems like it significantly disadvantages all sites
that opt-in to HPKP as a means of trying to mitigate the risk of a stolen
certificate. Sites that don't opt into HPKP are already at risk (as
noted), so this is only a mitigation for sites that are at risk.

I'm not convinced of the security benefits of such a change. It certainly
seems reasonable to mention in the security considerations (if not
already...), and it seems useful to mention potential proposals to deal
with this issue - for example, pinning to a certificate that contains the
CA/Browser Forum's proposed OCSP must-staple OID, which has 'hard fail'
semantics - but I don't think HPKP itself should be the conveyance
mechanism for such policies.

Have I missed something in my analysis?