Subject: [websec] HPKP and Certificate Revocation Check

From: vinod kumar <[email-masked]>
Date: Thu, 2 May 2013 15:20:35 +0530

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.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 2 May 2013 14:13:03 -0700

>  To avoid this attack, shouldn’t we mandate revocation checking when PKP

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?

---

From: vinod kumar <[email-masked]>
Date: Sat, 4 May 2013 22:53:18 +0530

Thanks very much for the detailed analysis of the proposal.

I was mainly thinking of security problems introduced by HPKP scheme. So, i
think, some of the problems you mentioned do not fall in that category.
Those are general problems associated with lack of revocation checking,
like,

1.      The first HTTP request is sent to the attacker anyway, revealing
session cookies.

2.      If the attacker does not employ HPKP headers, the attack will not
be detected.

But HPKP introduces a few DOS attacks on the host. These are:

1.      attacker gets a fraudulently issued certificate for a host which is
not using HPKP. He can add HPKP headers in the response to block out the
host.

2.      attacker steals host’s private key. This attack applies to hosts
supporting HPKP and those who don’t.

You generalize these attacks as DOS attacks. In the case of a typical DOS
attack, once the host finds out the occurrence of the attack, he can take
remedial action and recover from the situation.

But in the above attacks, host gets permanently blocked from connecting to
the affected UA’s and there is no way the host can unblock the UA.  Of
course, the user can remove the pin for the host (how does he decide?), but
any user action is always tricky and introduces other security
vulnerabilities.

Coming back to revocation checking for HPKP, it addresses DOS attack(2). We
don’t have to mandate revocation check whenever HPKP headers are received
but only in the following cases:

1.      The host is not a pinned host and an HPKP header is received.

2.      The host is a pinned host and the HPKP header contains a new pin
set.

3.      The host is a pinned host and the max age value is less than the
remaining age(?). I don’t think the attacker gets any benefit by extending
the max age of the current pins.

We may stipulate that if revocation check doesn’t pass in the above cases,
the HPKP headers will not be accepted.

I hope this modification alleviate the concern expressed in ‘From the site
operator who deploys HPKP: weakness’ section.

We may be able to provide some solution using OCSP stapling as you
suggested, that is something to explore.

On Fri, May 3, 2013 at 2:43 AM, Ryan Sleevi <[email-masked]>wrote:

> >  scheme (http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/),