Re: [websec] HPKP and Certificate Revocation Check
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 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
Re: [websec] HPKP and Certificate Revocation Check
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 hosts 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 doesnt 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 attackers pins and the valid host is > permanently blocked from connecting to the UA. > > To avoid this attack, shouldnt 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 sig
[websec] HPKP and Certificate Revocation Check
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. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
