Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Combining OCSP stapling with advance MITM preparation
21 views
Skip to first unread message
Kai Engert
Feb 23, 2012, 2:52:34 PM2/23/12
to mozilla's crypto code discussion list
While working on an updated paper of the MECAI proposal (which I hope to
post in the next couple of days), the following orthogonal idea came to
me. I don't know whether it is a new idea, or whether it has been
discussed/mentioned before.
Let's say the owner of a domain learns that a rogue certificate for
their domain has been issued, and is being controlled by an attacker.
(For example because of a user's report, who used any of the systems
that may help to detect a rogue certificate.)
The rogue certificate will be revoked, but because of today's reality of
incomplete revocation checking, the victim might be unable to perform
revocation checking and still be attackable.
The following idea only helps against those attackers who can only
temporarily control act as a MITM, who only temporary control the
network connection between a client and a server, such as users with
mobile devices, and may only help with sites that are visited frequently
by the user.
As soon as the certificate has been revoked, the domain owner is able to
obtain an OCSP response for the rogue certificate. The domain owner
could configure their server to include this OCSP response in all TLS
handshakes, even though this OCSP response is unrelated to the server
certificate actually being used.
If clients had a persistent OCSP cache, in particular bundled with a
persistent OCSP cache for all revocation events, then users/clients
could potentially learn about important revoked certificates in advance,
for the servers they frequently visit.
I believe this is an argument for getting OCSP stapling (and in
particular "multi OCSP stapling" as proposed by Yngve Pettersen)
implemented and widely deployed more quickly.
Actually, here is an expansion of this idea, not sure if it is practial.
We could invent a new communication protocol between servers and CA's
OCSP servers.
Servers could be allowed to contact (daily) each of the publicly known
CAs. The server could ask "do you know about any revoked certificates
for my server's hostname?". Assuming the CA has a database of their
incorrectly issued certificates, it could lookup the affected
certificates, produce a revocation OCSP response for each of them, and
send them back to the server. This way, information about compromised
certificates could be distributed automatically, only between the
parties that are really interested in such certificates.
Of couse, this "advance OCSP stapling" doesn't help if the user connects
to the system for the first time, or visits the system infrequently and
therefore doesn't have a chance to learn about the rogue certificate
early. That's where MECAI might be able to help.
Kai
post in the next couple of days), the following orthogonal idea came to
me. I don't know whether it is a new idea, or whether it has been
discussed/mentioned before.
Let's say the owner of a domain learns that a rogue certificate for
their domain has been issued, and is being controlled by an attacker.
(For example because of a user's report, who used any of the systems
that may help to detect a rogue certificate.)
The rogue certificate will be revoked, but because of today's reality of
incomplete revocation checking, the victim might be unable to perform
revocation checking and still be attackable.
The following idea only helps against those attackers who can only
temporarily control act as a MITM, who only temporary control the
network connection between a client and a server, such as users with
mobile devices, and may only help with sites that are visited frequently
by the user.
As soon as the certificate has been revoked, the domain owner is able to
obtain an OCSP response for the rogue certificate. The domain owner
could configure their server to include this OCSP response in all TLS
handshakes, even though this OCSP response is unrelated to the server
certificate actually being used.
If clients had a persistent OCSP cache, in particular bundled with a
persistent OCSP cache for all revocation events, then users/clients
could potentially learn about important revoked certificates in advance,
for the servers they frequently visit.
I believe this is an argument for getting OCSP stapling (and in
particular "multi OCSP stapling" as proposed by Yngve Pettersen)
implemented and widely deployed more quickly.
Actually, here is an expansion of this idea, not sure if it is practial.
We could invent a new communication protocol between servers and CA's
OCSP servers.
Servers could be allowed to contact (daily) each of the publicly known
CAs. The server could ask "do you know about any revoked certificates
for my server's hostname?". Assuming the CA has a database of their
incorrectly issued certificates, it could lookup the affected
certificates, produce a revocation OCSP response for each of them, and
send them back to the server. This way, information about compromised
certificates could be distributed automatically, only between the
parties that are really interested in such certificates.
Of couse, this "advance OCSP stapling" doesn't help if the user connects
to the system for the first time, or visits the system infrequently and
therefore doesn't have a chance to learn about the rogue certificate
early. That's where MECAI might be able to help.
Kai
Kai Engert
Feb 23, 2012, 2:53:58 PM2/23/12
to mozilla's crypto code discussion list
I've just sent the following message to Mozilla's dev-tech-crypto
mailing list, and I thought you might be interested, too.
mailing list, and I thought you might be interested, too.
Kai Engert
Feb 23, 2012, 2:55:00 PM2/23/12
to mozilla's crypto code discussion list
On 23.02.2012 20:53, Kai Engert wrote:
> I've just sent the following message to Mozilla's dev-tech-crypto
> mailing list, and I thought you might be interested, too.
I apologize for the double post, the second post was intended for a
> I've just sent the following message to Mozilla's dev-tech-crypto
> mailing list, and I thought you might be interested, too.
different mailing list...
Robert Relyea
Feb 23, 2012, 7:11:10 PM2/23/12
to dev-tec...@lists.mozilla.org
On 02/23/2012 11:52 AM, Kai Engert wrote:
>
>
> As soon as the certificate has been revoked, the domain owner is able
> to obtain an OCSP response for the rogue certificate. The domain owner
> could configure their server to include this OCSP response in all TLS
> handshakes, even though this OCSP response is unrelated to the server
> certificate actually being used.
>
> If clients had a persistent OCSP cache, in particular bundled with a
> persistent OCSP cache for all revocation events, then users/clients
> could potentially learn about important revoked certificates in
> advance, for the servers they frequently visit.
So I had some initial issues with this, until I realized by domain owner
>
>
> As soon as the certificate has been revoked, the domain owner is able
> to obtain an OCSP response for the rogue certificate. The domain owner
> could configure their server to include this OCSP response in all TLS
> handshakes, even though this OCSP response is unrelated to the server
> certificate actually being used.
>
> If clients had a persistent OCSP cache, in particular bundled with a
> persistent OCSP cache for all revocation events, then users/clients
> could potentially learn about important revoked certificates in
> advance, for the servers they frequently visit.
you mean the owner of the domain being spoofed by the OCSP response.
The tricky thing here is identifying the cert that was revoked. Unless
the CA actively pushes the results of revocation out to the domain
owner, their is no way the owner will know from a random OCSP or CRL
that a given revoked cert was from their domain.
This also doesn't help if the rogue certificate happens to be an
intermediate.
Not that the idea is without merit, we just need to make sure we
understand the limitations.
bob
>
>
> Servers could be allowed to contact (daily) each of the publicly known
> CAs. The server could ask "do you know about any revoked certificates
> for my server's hostname?". Assuming the CA has a database of their
> incorrectly issued certificates, it could lookup the affected
> certificates, produce a revocation OCSP response for each of them, and
> send them back to the server. This way, information about compromised
> certificates could be distributed automatically, only between the
> parties that are really interested in such certificates.
OK this solves issue 2.
>
> Servers could be allowed to contact (daily) each of the publicly known
> CAs. The server could ask "do you know about any revoked certificates
> for my server's hostname?". Assuming the CA has a database of their
> incorrectly issued certificates, it could lookup the affected
> certificates, produce a revocation OCSP response for each of them, and
> send them back to the server. This way, information about compromised
> certificates could be distributed automatically, only between the
> parties that are really interested in such certificates.
bob
Brian Smith
Apr 6, 2012, 3:13:25 PM4/6/12
to mozilla's crypto code discussion list
Kai Engert wrote:
> The domain owner
> could configure their server to include this OCSP response in all TLS
> handshakes, even though this OCSP response is unrelated to the server
> certificate actually being used.
For complete protection, the real domain holder would have to staple all the OCSP responses for all compromised certificates in every full SSL handshake it does, until those certificates expire.
> The domain owner
> could configure their server to include this OCSP response in all TLS
> handshakes, even though this OCSP response is unrelated to the server
> certificate actually being used.
How do you compare this with http://tools.ietf.org/html/draft-evans-palmer-key-pinning-00?
In that mechanism, the server staples information that "pins" the public key of the cert such that certs with different public keys will automatically be dis-trusted by the browser.
The Evens/Palmer pinning mechanism has an advantage in that it protects against mis-issued certs before the issuing CA or the domain owner even learns about them.
The Mozilla security team is already planning to implement the Evens/Palmer mechanism in Firefox and Chrome has implemented it, AFAICT.
Cheers,
Brian
0 new messages