On 03/22/2009 10:38 PM, Nelson B Bolyard:
Oh, those poor server admins!
Wrong! It's those poor users exporting their client certs from Firefox
into Thunderbird....and then they have no clue why they can't sign their
mail (without explicitly importing the issuer intermediate CAs from a
different location or by exporting from Firefox).
It's in NSS 3.12.2. Has been for some time. FF may enable it whenever
Mozilla wishes.
Fantastic! Is there a bug to enable it? Highest priority....whatever
makes Firefox work better in this respect should be done.
Why is it more painful for TB? Is it because a higher percentage of
mail server admins fail to correctly configure their servers with the
required certs?
See above...
I think the only thing preventing AIA issuer certificate fetching is a
political one (privacy: the CA might know to which site you are browsing
as if the CA couldn't know that anyway through OCSP and CRL requests).
No, that's not the issue at all. (Well, maybe it is for some people,
but I agree that the legitimate CAs are going to find out through revocation
checks, as you've suggested.)
The concern is that, with AIA cert fetches, you must rely on information in
the cert before you've verified that the cert came from a real CA and is
not a forgery. This is quite different from the normal cert validation.
I don't see the problem...if it doesn't match a valid root just discard
it...done.
But with AIA, you get a cert, and you don't know if it's from a legit
issuer or is a forgery or an outright bogus cert, but you're going to
take a URL from it and go access that URL, as if it was trusted. An
attacker can use this to vector all sorts of attacks.
Which attack? Does the cert chain to a valid root? Perhaps we should ask
Microsoft about their experience, they most likely know a lot more about it.
Let me give an example. Let's say that there is a server behind a
corporate firewall that only honors requests coming from clients that
are also behind that firewall on the "intranet". Further, the firewall
prevents requests coming from outside to reach the servers behind the
firewall. An attacker outside the firewall cannot directly send requests
to that intranet server. How could he get a client behind the firewall
to do so? He could put the URL of that intranet server into the AIA
extension in a bogus cert, and then serve that cert to the client from
a bogus MITM attack server. The client gets the bogus cert and, before
it has validated the cert, goes and accesses the URL in the cert. Even if
the client ultimately determines that the cert it got was bogus, it has
already done the harmful deed and fetched the attacker's URL. Further,
the server now probably has a record that the harmful request came from
an inside user, and that user may get fired or disciplined. So it's a
vulnerability to intranet servers and users alike.
You mean it pokes a whole into the firewall unintentionally? I guess
there are easier ways doing it...plus correct firewall configuration
should prevent that.
Yes, there are other ways an attacker could do this, such as an IMG tag
in an ordinary http page. But https and PKI are supposed to prevent
(or at least mitigate) such attacks, not be a vector for them, and they
do that, except in the AIA case.
Here you said it too... :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
