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
[email protected]
https://www.ietf.org/mailman/listinfo/websec
