Eddy Nigg wrote, On 2009-03-22 14:22:
> 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).
Well, up until now, we've been talking about client auth, and you're
talking about email signature certs, not client auth certs. But I'll
grant that there are similarities.
I find this email problem interesting! Your description tells me several
things.
1) When the user downloaded his new email cert in his browser, he didn't
get the full chain, but only got his own cert. So, he didn't have the
complete cert chain in his browser when he exported it to a PKCS#12 file.
If the cert chain had been complete in the browser, then it would have
been complete in the PKCS12 file, also, and the entire chain would have
been imported into Thunderbird.
The incomplete chain downloaded into Firefox is the problem that must be
fixed. It's the most crucial. I don't know if it's entirely an issue
in the CA (:-) or also partially in Firefox.
2) As you know, NSS 3.12 has the ability to share a single DB pair
between the browser and Thunderbird, but that feature has not yet been
put to use in either Firefox or Thunderbird. That will reduce the
pain of the exporting and importing, but it won't alter the fact that
if the chain downloaded to Firefox was incomplete, it still won't work.
3) Mozilla email clients do not require that the client have a complete
chain for its own cert in order to send a signed or encrypted email.
The problem occurs on the side of the user who receives the email with
the incomplete chain. He gets a signature that won't verify, and he
can't send an encrypted reply to the source to tell him about it.
Maybe we should change Thunderbird so that it won't let you send a
message with an incomplete or unverifiable chain.
4) Maybe, at the time the user downloads his newly issued cert, we could
warn the user "You've just downloaded a cert with an incomplete chain
that will cause you no end of grief until you get the missing certs.
Please contact your CA." :)
>> 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.
I think so, but to be honest, there are SO MANY bugs like that, where some
problem was solved in NSS long ago and the browser still doesn't make use
of it, that I don't try to follow them all any more.
>> 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...
Well, OK, but it's a different problem, not client auth.
>> 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.
I'm surprised you don't see the problem here, Eddy, but if you don't, then
odds are good that other's don't, also, so I'll try to spell it out in a
little more detail, with an example. Let's start with a diagram.
Internet Corporate Intranet
+------------+-------- Firewall -------+-----------------+
| | | |
Intended Evil Corporate Corporate
Server Attacker Server Browser
www.Bob.com Carol Ted.corp.com Alice :)
Alice is authorized to access the corporate server, run by Ted, and
she is also allowed to access a server out in the Internet, but only
via https. The firewall will only let Alice's requests out onto the
Internet if they are https requests, not if they're ordinary http requests,
and it will only let them out if they are going to hosts with approved
DNS names on the Internet. Alice visits Bob's server every day on official
corporate business, fully approved by Alice's corporation.
Alice is also allowed to send http requests to Ted's server. Ted's server
is behind the firewall. The Firewall doesn't let ANY requests of any type
go to Ted's server from outside the firewall. Alice's browser is allowed
to access Ted's server with plain old http, but Carol cannot access it
directly from outside the firewall.
Attacker Carol wants to try to send an http request to Ted's server, but she
can't because of the Firewall. She needs to find a way to get Alice
to send that request on her behalf. That would be pretty easy if Alice
sent http requests out to the Internet from her browser behind the firewall,
because then Carol could play MITM and send bogus web pages back to Alice's
browser. Without SSL there would be nothing to stop Carol from MITMing
plain old http. But the firewall doesn't allow Alice to send http requests
out to Bob. So, somehow, Carol needs to find a way to get Alice's browser
to send Carol's http request to Ted's server. How can she do it?
Alice only trusts SSL server certs that are EV certs. So, one way for
Carol to get Alice's browser to do her bidding would be for Carol to get
an EV cert for Bob's server DNS name. But she can't fool the CAs into
thinking she's really the admin for Bob's server, so she can't get a
EV SSL cert for Bob's DNS name. So she needs a plan B.
Carol is capable of making the traffic for Bob's server come to her
instead. Of course, since she doesn't have an EV cert for Bob's server,
she won't really be able to fool Alice into thinking that Carol's attack
server is really Bob's server, but that's not her objective. Her objective
is to get Carol to send a request to Ted's server that will do something
bad, a request that Alice would not normally send to Ted's server. Then
Ted will get upset, and discover Alice's access in his logs, and will get
Alice fired, or so Carol hopes. Carol knows that if she can get Alice's
browser to visit the URL shown below, Alice's career will end fast.
http://ted.corp.com/sendmemo.cgi?to=all&subject=lets+kill+the+boss&body=now!
Can Carol devise a certificate that will get Alice's browser to send that
http request to Ted's server? If Alice's browser supports AIA extensions,
the answer is: yes, Carol can!
Before we see how Carol does that, let's look at Bob's ordinary cert chain.
Bob's real EV cert has CN=www.bob.com in the subject, and is issued by
OU="Good Intermediate CA",O="Good CA". The intermediate CA's cert has a
subject of OU="Good Intermediate CA",O="Good CA", and is issued by
OU="Good Root CA",O="Good CA".
Carol knows that Alice's browser trusts all EV certs that chain up to
OU="Good Root CA",O="Good CA", and that if Alice's browser gets a cert
that looks like it might be an EV cert, but is issued by an unknown
intermediate CA, Alice's browser will use the AIA extension to try to
fetch the missing intermediate CA certificate.
So, using certutil from NSS, or OpenSSL, Carol constructs a cert with a
subject of CN=www.bob.com (just like Bob's real cert), and the issuer
name is OU="Clever Carol",O="HA HA" and the cert's AIA extension bears
the URL shown above.
Now, Carol sets up her MITM for a very short time, until she is sure
she's gotten a request from Alice. Then she puts everything back.
It looks to Bob like a short time network glitch. During that time,
Alice's browser tries to visit Bob's server, and gets Carol's magic cert.
Alice's browser looks at the cert and says, "Hmm, I don't have a cert for
this issuer, so I can't verify that this cert is legitimate and from a
trusted issuer, but LOOK, there's an AIA extension here. I can get the
missing intermediate CA certificate from that URL." And so, before
Alice's browser has verified that cert in any way, it sends off a request
to try to get the missing intermediate CA cert. The URL for that request
comes right out of Carols' clever cert. Alice's browser has NO WAY of
checking that the AIA URL is legitimate before using it. Alice's browser
HOPES that it will find that the intermediate CA cert comes from a trusted
issuer, but it cannot know that until it receives and checks the
intermediate cert from the AIA URL. So, Alice's browser sends off that
fateful URL request.
Instead of sending back an intermediate CA cert, Ted's server sends out
that fateful memo, and sends back an http reply with an html page saying
"Dear Alice, Rejoice! We have sent your memo, just as you asked.".
Alice's browser sees that reply and thinks, "Wait, that's not an
intermediate CA cert!" and so it stops right there, doesn't try any further
to validate that bogus cert. But it does ask Alice if she wants to create
a security exception. Oh, even if she never clicks the button, she has
already created a security exception all right, a BIG one. But it will be a
little while before she finds that out. Poor Alice!
Now, let's look at the questions you asked.
> Which attack? Does the cert chain to a valid root?
Of course not! But there's no way for Alice's browser to know that UNTIL
the request is sent to attempt the fetch the missing intermediate CA cert,
and the damage is done!
If checking that a cert chains up to a trusted root was a precondition
for doing AIA cert fetches, then no AIA cert fetches would ever happen,
because AIA cert fetches are ONLY done when the cert chain is incomplete.
> 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.
Tell me how the firewall will prevent Carol's attack on Poor Alice.
The question before Mozilla's browser guru's is: which is worse?
Having lots of users get invalid certs because of incomplete cert chains?
Or sacrificing Alice on the altar of ease of use?
For Alice's sake, I hope the Internet gods will provide a ram to be a
substitute sacrifice at the last minute. (Apologies to Abraham)
There's a happy postscript to this story. Bob and Carol, Ted and Alice
get the movie rights... :-)
/Nelson
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
