On 10/13/2009 11:37 PM, Robert Relyea:
On 10/13/2009 06:54 AM, Gervase Markham wrote:
Firefox uses OCSP but, by default, any response other than a definite
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change that, so that any response other
than "is not revoked" is treated as "is revoked".
IMO, we need to be smarter about that.
We have to be very careful here. There is a major risk in trying to
prevent the attacker from intercepting the OCSP response. Here's why:
For an attacker with a compromised certificate:
Case 1: The attacker does not have the ability to block the OCSP
responder, or modify the response.
We get the OCSP response which says revoked and we don't trust the cert.
Case 2: The attacker can modify the response.
The attacker modifies the OCSP packet. He can:
1) invalidate the signature. The packet says revoked, but we
don't trust it because the signature isn't valid.
2) changes revoked to not revoked. Again, we ignore this because
the signature isn't valid.
3) Moxie's attack.
We can solve 1& 2 by considering a bad signature as revoked.
We can solve 3 by ignoring the unsigned status fields.
4) He can modify the http response to some other status (400,500).
We can solve 4 by your proposal.
Case 3: The attacker can substitute his own response.
The attacker can give a funky status (400,500) (looks like 2.4), or
the attacker can give an OCSP response that looks valid except the
signature (looks like 2.2).
Case 4: The attacker can block the response (or the request).
These show up as no response. This is indistinguishable from network
problems.
It turns out that of all cases 2, 3, and 4, case 4 is the easiest
(simply overload the requested OCSP server). Also, if you can do 2, and
3, you can always do 4 (You just drop the packet on the ground). So
while an attacker may have lots of things he can do to us, he can always
do the one case that we are going to always accept under this proposal.
OK, so lets ignore this case, and assume that the attacker is stupid (or
there is a case 2 or 3 that doesn't allow the attacker to just drop the
packet) and mounts a case 2 or 3 attack.
In order to be successful, the attacker needs both a compromised
certificate and the ability to mount a case 2 or 3 attack. So we defend
against cases 2 or 3. Firefox goes out, by default, with where it
rejects any cert if it gets a skanky OCSP response (bad signature,
unexpected http status response, etc.).
Now an attacker, who can mount a case 2 or 3 attack, can attack websites
which he does not have a compromised certificate for:
If he could mount case 2, he could:
1) modify the signature of a valid response (indistinguishable from case
2.2).
2) change a valid response to an invalid response (indistinguishable
from case 2.1).
3) change the http response (indistinguishable from 2.4).
If he could mount case 3, he could supply his own funky http status, or
his own response without a valid signature.
In all these cases, Firefox would now reject the certificate as revoked.
The attacker now has the ability to effectively shut off any number of
https websites he chooses simply by attacking the OCSP responder for the
CA that certified that website.
So in trying to prevent an attack based on an OCSP responder, we have
expanded the possible attack surface such an attacker could leverage (at
the same time failed to prevent he exact attack we were initially trying
to prevent).
OK, so does that mean we ignore this strawman?
Not necessarily. The ecosystem is highly interdependent, and changes to
the equation may change our vulnerability to different attacks. For
instance, if we believe attacks of class 2 and 3 are sufficiently
difficult to be rare, then we may go ahead with making them fatal. In
this case we aren't necessarily protecting against some OCSP attacker
(who can always revert to class 4 attacks), but we are making sure our
infrastructure is working properly. If a CA puts up a non-working OCSP
responder, it will be come obvious quickly, and there will be lots a
pressure to get that CA to fix it's responder.
In doing so, we assume that the internet infrastructure people would
quickly detect the OCSP based DoS attack in the real world and shut it
down (I am not naive enough to believe that class 2 or 3 attacks are
impossible, not as long as DNS can be subverted).
Adding OCSP stapling to the mix makes things even better. Now websites
have protection against OCSP DoS attacks by supporting stapling. The
OCSP response need not be fetched since we already have it.
In summary, we have to be careful about 'doing something because it just
seems right'. We need to truly understand the risks, and what we are
getting for those risks.
Bob, a way to mitigate attacks on OCSP responders (DOS) can be mitigated
to by also supporting CRLs at multiple locations. Also we considered
already multiple different locations for OCSP responders, I'm not sure
if NSS (and other software) would support that.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: start...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
