Re: [websec] HPKP and Certificate Revocation Check

vinod kumar <vinodkumarpm@gmail.com> Sat, 04 May 2013 17:23 UTC

Return-Path: <vinodkumarpm@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B7F21F9667 for <websec@ietfa.amsl.com>; Sat, 4 May 2013 10:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdpzQPONPbLe for <websec@ietfa.amsl.com>; Sat, 4 May 2013 10:23:20 -0700 (PDT)
Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 026EA21F86F4 for <websec@ietf.org>; Sat, 4 May 2013 10:23:19 -0700 (PDT)
Received: by mail-bk0-f54.google.com with SMTP id y8so1116033bkt.27 for <websec@ietf.org>; Sat, 04 May 2013 10:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pQuJadhrbAYyC8fmBgo3Bz8cEccR/ylZ3ew7EzyhwfQ=; b=v1jZMNOExYH6116fLGQApjhqQr/LrXTZm1pX7xT1bSapfiNeLzjrhlVLL5rm6S9yFa H8ENlH4R+uZD7+eMNAUt/Xovw0nTItYvsYdCc7Yj2sY8XCTu2NxL5AUGXe+ktOvhXmwq Ea6bppOzJyCSvzWE6qCgVK2Ty3Yz3cuhz+gmKX3Vo7huIa9hUSn0oy4Jxj0M05nAiwS4 ismwSYBMAzQcmmSz67YeXDgh9wMmjWh9CjNd8lSIbil3Hftx+i3tRkaDoP+fo/eWlPna iDhvv1W2kzcinxa2+0hwBkG6z7YbnaPt1xlFqpkN/6tk0InW7BIKpiMw2fC62jXTGqUu M0jw==
MIME-Version: 1.0
X-Received: by 10.205.105.8 with SMTP id do8mr5559258bkc.3.1367688199022; Sat, 04 May 2013 10:23:19 -0700 (PDT)
Received: by 10.205.34.13 with HTTP; Sat, 4 May 2013 10:23:18 -0700 (PDT)
In-Reply-To: <fbbc35aab2ca54295338b00a60b3ac1a.squirrel@webmail.dreamhost.com>
References: <CAMvi6UW9+eBQ-9mJKvXNMxEK+UEU_a7r8AyCvxo2rrH5Qg+r3w@mail.gmail.com> <fbbc35aab2ca54295338b00a60b3ac1a.squirrel@webmail.dreamhost.com>
Date: Sat, 04 May 2013 22:53:18 +0530
Message-ID: <CAMvi6UXDgE8T2-gQfu7F_+YSp09vtwmW5ceqhRN5O-w340NP_w@mail.gmail.com>
From: vinod kumar <vinodkumarpm@gmail.com>
To: ryan-ietfhasmat@sleevi.com
Content-Type: multipart/alternative; boundary="f46d042186b9445aba04dbe7b9ce"
Cc: websec@ietf.org
Subject: Re: [websec] HPKP and Certificate Revocation Check
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 May 2013 17:23:23 -0000

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 <ryan-ietfhasmat@sleevi.com>wrote:

> 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?
>
>