Hi,
what are the known attacks when pin is created to a CA certificate by
SubjectPublicKeyInfo (SPKI) compared to pinning by full certificate (or
hash of full certificate)?
Some I could think of:
1. Extending certificate chain
Let's have server-cert SC1 that directly chains to CA-cert I1 from
authority CA1, pin is made by SPKI to I1.
If there exists cross-certificate R1 such that:
- R1 is issued by CA1 to authority CA2
- R1 directly chains up to certificate O1 (from CA1)
- O1 and I1 have identical SPKI
then original chain
I1->SC1
can be extended to
O1->R1->SC2
where SC2 is server-cert issued by CA2 (fraudulently perhaps) and pin
would be valid (the scenario is a bit simplified since CAs usually don't
issue end-entity certs directly under their root).
I'm not sure how viable the above scenario is - I presume CAs won't
share same key for signing cross-certs and server-certs. (Though
occasionally CA certs with identical key and different subject pop up;
perhaps offices/RAs at different geographical locations.)
2. Swapping certs with different X.509v3 extensions
Let's say attacker swaps CA-cert I1 for different CA-cert I2 having
different extensions (e.g. in SSL handshake). Some that matter here:
- basic constraints - would allow longer/shorter chain (shorter
chain=>possible DoS)
- name constraints - very rare in practice
- policy constraints - rare in practice, I'm not sure how widespread
support in clients is
- authority information access - it may be handy to swap a cert for one
without OCSP or CRL
Adam Langley mentioned following scenario before
(https://www.ietf.org/mail-archive/web/dane/current/msg03753.html):
* The site fails to include any intermediate certificates
* The leaf doesn't include an Authority Key Identifier, but incudes an
AIA URL for I1 (I1 = next CA cert in chain just above server cert)
* I1 is replaced with a certificate with the same SPKI, but a different
issuer.
Though in case server does not send intermediate chain the processing at
client's side is non-deterministic.
Any other ideas?
Ondrej
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
