Closed Bug 308244 Opened 19 years ago Closed 18 years ago

insecure handling of SSL certificate extension field "SubjectAltName"

Categories

(Core Graveyard :: Security: UI, defect, P1)

x86
Linux

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 240261
mozilla1.8.1

People

(Reporter: benkstein, Assigned: KaiE)

References

()

Details

(Whiteboard: [sg:spoof] [kerh-bra])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050728 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050728 Firefox/1.0.6

Hi,

besides the common name field in SSL certificates there is a field called
"SubjectAltName" that allows you to put different hostnames in one certificate
(which is neccesary no support name based virtual hosts on SSL as long as tls
upgrade isn't available).

Firefox matches this field (it also supports wildcards) against the hostname of
the server connecting to but fails to display its contents to the user when they
should accept an "unkown" (self-signed or unkown CA) certificate. It is even
impossible to check for the contents of the field by clicking on "Examine"
because firefox only displays an hex string.

If the user connects to another hostname that is included in the certificate
using the same certificate, firefox establishes the connection without asking
the user again.

Thus it is possible to do a man-in-the-middle attack if one can get the user to
accept one single certificate:

0. Suppose the attacker is able to redirect the users internet traffic to his
machine.
1. The attacker has to trick the user into accepting the forged certificate.
There may be multiple ways to do this. 
2. When the user connects to the site the attacker is interested in, he/she
serves the previously accepted certificate containing the wildcard.
3. The wildcard matches the hostname of the interesting site firefox establishes
the connection without a warning.
4. The user thinks he/she has a secure connection to the site but the attacker
can read all the traffic.

Firefox should display the contents of the SubjectAltName field to the user.
Maybe it would be better if firefox would also the SubjectAltName field on
temporarily accepted certificates and only accepted an certificate permanently
if the user agreed to the contents of the field.

Best regards
Frank Benkstein.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Oh, btw. I set up two test sites:

http://site-a.toidinamai.de - serving the "attacker" certificate
http://site-b.iamanidiot.de - serving the same certificate

If you visit the first site you are asked to accept the certificate.
If you do this and then visit the second site you get no warning because the
wildcard "*.de" in the certificate matches its hostname.

Output of "openssl x509 -in server.crt -noout -text":

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d0:5a:dd:a9:af:d6:33:d4
        Signature Algorithm: md5WithRSAEncryption
        Issuer: CN=site-a.toidinamai.de
        Validity
            Not Before: Sep 12 22:16:36 2005 GMT
            Not After : Nov 12 22:16:36 2005 GMT
        Subject: CN=site-a.toidinamai.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:d9:c4:b1:23:ea:43:23:2b:c2:ab:77:81:f5:17:
                    9b:7c:3d:62:5d:4c:ad:a4:d0:05:75:24:a7:20:31:
                    99:f8:3b:53:45:df:a5:63:af:da:db:ae:7f:22:53:
                    80:6b:d2:a2:1d:a7:67:73:53:a3:64:d2:0b:80:75:
                    98:c8:d3:3c:c9:47:27:4d:89:18:70:66:e9:fc:33:
                    bb:68:2e:94:33:06:34:81:e0:27:e2:d0:db:5f:ce:
                    4e:75:f9:80:a8:0f:40:1d:60:93:df:89:71:f9:f5:
                    79:18:85:1f:0c:46:d7:b4:fd:cf:56:99:db:4d:05:
                    5e:d4:59:1f:93:cf:15:5d:43
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:*.de
    Signature Algorithm: md5WithRSAEncryption
        b0:b4:83:e1:af:e1:97:2f:fa:d8:73:d0:7d:7c:21:7c:ee:40:
        99:8d:79:1f:a8:db:2a:c2:e6:34:bd:11:1f:52:e2:8a:6e:27:
        bd:73:c5:31:ca:bc:ec:39:a3:c5:a2:b8:f9:99:dc:11:77:d3:
        0b:4c:bd:68:85:7c:85:b0:fa:c7:7b:73:87:c4:1b:aa:64:0f:
        21:09:4c:0c:c7:3c:a6:6c:95:ef:96:92:24:ae:75:e9:4e:66:
        4c:c0:44:31:c8:4e:be:88:9b:60:a8:f9:9c:ce:de:be:1a:a2:
        ac:12:b6:87:7c:00:1d:72:51:94:74:69:09:52:38:cb:4e:95:
        73:35
See also bug 285361 comment 1 -- that restriction would reduce the potential
damage here, but of course wouldn't prevent targetted attacks if the fake cert
simply enumerated the sites it wanted to phish for.

Getting a user to accept one of these certs is be easy. The warning says we
can't verify what site it is, but if the user is just surfing around (assume the
link is "See Stars Naked!" or "Watch the funny hamster!") lots and lots of
people wouldn't care. The warning dialog is only in the way, and appears to be
warning about a danger that doesn't apply if you're just looking at random
sites. "Fine, I wasn't going to spend any money there anyway. Go away" would be
the response I'd expect at best. Heck, it's probably the response I'd have too.

The dialog should be much more explicit: "Approve this certificate for sites X,Y,Z"

bug 259031 might help a little -- at least people could read the extensions, all
3 of them paranoid enough to check in the scenario above.
Assignee: nobody → kaie.bugs
Status: UNCONFIRMED → NEW
Component: Security → Security: UI
Ever confirmed: true
Flags: blocking-aviary2.0?
Product: Firefox → Core
QA Contact: firefox
Whiteboard: [sg:spoof]
Version: unspecified → Trunk
> Thus it is possible to do a man-in-the-middle attack if one can get the 
> user to accept one single certificate:

Of course, that is true regardless of cert name mismatch issues.  
A single cert is all it takes. Allowing users to override cert validity 
errors is extremely dangerous for those users.

I see this bug as mostly arguing for disallowing users to override cert 
validity errors.  Note that NSS has two separate sets of checks and two
separate overrides, one for cert validity (e.g. signed by a known and 
trusted CA) and another for cert name (mis)matches.  Overriding one does
not override the other.  Cert name mismatch overrides only allow the 
cert to additionally be used for the one hostname that the user was 
trying to access when the cert name mismatch occured (in addition to the
hostnames for which its issuer said it was valid).  

So, this bug posits a cert with a wildcard or many host names in the 
subject alt name that fails a test, not because of a name mismatch but 
because of a validity check falure (no valid signature from a known and 
trusted issuer), triggering a cert validity override dialog.

This bug observes that once the user chooses to override the validity failure, 
the user is vulnerable to MITM.  Of course, that is always true, any time 
a user overrides a cert validity check for any reason, whether or not the 
cert contains wildcards or Subject Alternative Names (SANs). An invalid cert 
with a single host name that matches the user's desired host name is all it
takes to do an MITM attack.  The sole purpose of cert validity checks is to 
avoid MITM, and when the user overrides them, the user takes full 
responsibility for MITM attacks to which he has made himself vulnerable.

All research indicates that, in response to error dialogs of any kind, 
users do nothing but find the button with which to override that error.  
And in the case of moz browsers, that button is already the default (IINM) 
so that only a press of the "enter" key is needed to override.

If the browser presents the user with a large page of details extracted from 
the cert including all the SANs, will the user examine that any more closely 
than the user examines the present dialog, before pressing the enter key? 
And if he/she did, would he/she be any less vulnerable to MITM?  (no)

I think the issue is that mozilla browsers make it far too easy to override 
cert validity errors today.  Mozilla has acceded to the demands of "power 
users" who want to operate servers with invalid certs.  That decision is 
detrimental to the security of ordindary newbie users, who habitually 
override all security errors, when they can easily do so.  

Since mozilla is unwilling to take away the cert validity override feature,
perhaps mozilla should force the users to examine every field in the cert's 
details before allowing an override.  This is analogous to installers that
require the user to scroll past all the text in the license agreement before
allowing them to click the button that accepts its terms.  

IMO, if you really want to protect users from MITM, you won't ask to give 
them even MORE to ignore before overriding the validity failure.  The only
thing that will make a difference is to make it much more difficult to 
override cert validity errors.  Make it difficult enough that a user is 
likely to say "it's not worth the effort just to see funny hamsters".  
(In reply to comment #3)
> This bug observes that once the user chooses to override the validity failure, 
> the user is vulnerable to MITM.  Of course, that is always true, any time 
> a user overrides a cert validity check for any reason, whether or not the 
> cert contains wildcards or Subject Alternative Names (SANs). An invalid cert 
> with a single host name that matches the user's desired host name is all it
> takes to do an MITM attack.

The problem here is that the user does not need to accept an untrusted
certificate on the "interesting" site but on some random other site. I hope that
if he/she gets such an error at his/her bank's site he/she would think: "Huh?
That never happend before. Maybe this is bad, I better ask someone who knows."
But he/she doesn't get that error here, firefox silently uses the previously
accepted certificate.

I don't think you can disallow users to visit sites with invalid certificates.
Because else they would simply fire up another browser that "doesn't cause them
so much trouble." (I think most of the users can't differentiate between a
problem of the browser and a problem of the site they are visiting.) But if the
user agrees to accept a certificate only this one session should be (possibly)
corrupted not *all* others that follow. If you don't want to display the
contents of the SubjectAltName field to the user, simply don't use it when
checking validity of a site. If a site administrator has to use this feature
he/she should be smart enough to get their users to accept their certificate
permanently (which should be more difficult btw).
(In reply to comment #2)
> bug 259031 might help a little -- at least people could read the extensions, all
> 3 of them paranoid enough to check in the scenario above.

Yes, this bug would help. At least me and the other two. :-)
This bug cites as its concern the possibility of an MITM attack.
In the event of receiving a cert that cannot be validated, there is 
ONLY ONE WAY for a user to truly avoid an MITM attack, and that is to 
KNOW THE PUBLIC KEY of the intended server, and to verify that the 
cert contains that public key and no other.  

No other information in the cert can help the user avoid MITM attacks.
The MITM attacker can copy EVERY field in the cert from the attacked server's
cert, and merely substitute his own public key.  If the user is relying on
ANY fields in the cert, OTHER THAN the public key, to determine the cert's
validity (in the absense of a verifiable signature from a trusted CA),
the user is making himself vulnerable to MITM.  It's that black and white.

So, the suggestion put forth here, that by displaying more details (other
than the public key, which is already available), the user will be better
able to avoid MITM, is *FALSE*.  

On that basis, I think this bug is invalid, and is not really security
sensitive, because it does NOT expose a previously-unknown vulnerability.
Again, the MITM vulnerability is caused by the lack of a verifiable CA 
signature, AND the lack of knowledge of the intended server's public key,
NOT by unexpected information in the cert's various name fields.

If this bug is merely a request for the display of more information, and 
can be satisfied without solving any MITM problem, then it is merely a 
duplicate of bug 259031.
Let me explain again what exactly my concern is:

The user connects to site A having an unkown certificate. It is perfectly clear
that if he/she chooses to establish the connection nevertheless he is vulnerable
to a man-in-the-middle attack in his communication with site A. The problem here
is that he/she is also vulnerable in all other communication following the
acceptance of the unkown certificate if this certificate was faked by some attacker.

It is currently nearly impossible to protect oneself against this. One way would
be simply not to accept the certificate but this is probably not what the user
wants. The other way would be downloading the certificate with openssl s_client,
dumping all it fields and checking by hand if the unkown certificate contains
fields like SubjectAltName with harmful wildcards.

I think the current behavior poses an immense security risk and displaying more
information is only one possible fix although possibly not the best one. An
(temporarily) accepted certificate should only be valid for the site it was
accepted for. If it the certificate is accepted for example.com and *.com,
firefox should tell the user that. 

Please correct me if I'm wrong but I do think this is an previously undisclosed
vulnerability. I'm no SSL expert at all. Is there currently another way to
protect me against these wildcards than to simply reject all unkown
certificates? (Excluding the openssl s_client way, that is just impraticable.)
Could we do something like:

- When the user accepts a cert after a mismatch error, they accept it only for
the  field in the cert which is the one which matches the current hostname. If
you later access another, you get asked again.

So if the cert had:
*.toidinamai.de
*.iamanidiot.de 

and you visited site-a.toidinamai.de, you'd get a popup and that would be fine.
It would also be fine if you visited site-c.toidinamai.de. But if you then went
to site-b.iamanidiot.de, you would get the original popup again, this time
displaying the new domain name,

Would that fly?

Does this problem occur in IE, anyone?

Gerv
Gerv,  what you describe is true of a cert name mismatch error.  A cert name
mismatch error implies that the cert is valid, but does not include the DNS 
name to which the user was browsing.  Mozilla offers the user the chance to 
add that DNS name to the set of acceptable names for the validated cert.

But the situation reported here is not a cert name mismatch error.  In this 
case the cert already bears the name of the site being visited by the user.  
This case is a cert validity error (no valid signature from a trusted CA).  
The user is choosing to accept a cert from a CA that is unknown and/or 
untrusted (to the browser).  And in doing so, the user is allowing the cert 
to be treated exactly as if it had been issued by a known and trusted CA, 
which implies that the cert will be treated as valid for ALL the DNS names 
that are given in the cert's list of Subject Alt Names.  

A cert that is valid (either because of a valid signature from a trusted CA, 
or because the user has declared it to be valid despite the absence of such 
a signature), will be acceptable for all the names it bears in the Subject 
Alt Names (if there are any).  It is not treated as valid for some of those
names but not others.  After a cert is manually validated, it may experience 
cert name mismatches, and thereafter the user may ADD names to the cert, as
explained above.

Fundamentally, when a user chooses to manually validate a cert that is not
otherwise validatable, there are two possibilities: 
a) the cert is the correct and proper cert for all the given DNS names, 
bearing the correct public key for those DNS names, or 
b) The cert contains certain names for which the public key is not correct, 
or a public key that is not correct for ALL the names in the cert).

The user CANNOT determine which of those two cases is facing him based solely 
on the names in the cert.  The latter case is an attack on the user's security 
(by definition).  If the user chooses to accept and manually validate such a 
cert, the user has made himself vulnerable to MITM.  That is certainly not 
news, and has always been known.  

I think Mr. Benkstein is saying that he wants to be able to limit the scope
of the DNS names for which the MITM attack would be valid after the user 
chooses to manually validate an otherwise-invalidated cert.  He wants the 
user to be vulnerable to MITM attack only for the DNS names shown to the 
user in the dialog by which the user chose to manually validate the cert.  

His proposed solution does not eliminate the MITM attack vulnerability that
the user brings on himself by manually validating the cert.  Increasing the
user's level of knowledge of the scope of vulnerability does not eliminate 
the vulnerability.  

I think the time for mozilla to approve and accept the patches for bug 259031
is LONG overdue, and I urge Gerv or Dan to take the necessary action to unblock
it and get it into the product, with all due haste.  But I don't accept that
this is a new vulnerability.  It's the same old MITM vulnerability to which
users subject themselves by manually validating an otherwise-invalid cert.
(In reply to comment #9)
> A cert that is valid (either because of a valid signature from a trusted CA, 
> or because the user has declared it to be valid despite the absence of such 
> a signature), will be acceptable for all the names it bears in the Subject 
> Alt Names (if there are any).  It is not treated as valid for some of those
> names but not others.  After a cert is manually validated, it may experience 
> cert name mismatches, and thereafter the user may ADD names to the cert, as
> explained above.

I think therein lies a bad misconception about the validity of a certificate. A
certificate that is (temporarily) accepted by the user should not have the same
trust as a certificate signed by a known CA or otherwise known to firefox. The
whole thing SSL is about is *not* no ask users to make security decisions. The
users intent in clicking away the dialog is to visit the site. This visit may
not be save (as is plain http) but the user (hopefully) knows about it and
doesn't care. In no way will a user think that if he/she accepts the certificate
this will affect his/her other sessions. I only stumbled upon this because I am
a website administrator myself and played a little bit around with SSL.

Maybe SSL connections with temporarily accepted certificates should be
considered entirely as plain text connections (leaving the address bar white)
and should not affect the SSL subsystem of firefox at all.

If a power user really wants to trust a certificate he/she will import the
certificate into firefox thus make it fully trusted. Therefore he/she must have
the ability to see all the fields. This is handled by bug #259031. IMHO the
option to permanently accept a certificate should be removed from the
"click-away-to-visit-the-site" dialog and be an option in the security
preferences or be made otherwise more difficult to reach.
> [...]
> I think Mr. Benkstein is saying that he wants to be able to limit the scope
> of the DNS names for which the MITM attack would be valid after the user 
> chooses to manually validate an otherwise-invalidated cert.  He wants the 
> user to be vulnerable to MITM attack only for the DNS names shown to the 
> user in the dialog by which the user chose to manually validate the cert.  

Nobody called me Mr. Benkstein before :-), but yes that is true. The temporarily
accepted certificate should only be valid for this one host the user wants to visit.

I can see no valid case where a temporarily accepted cert is valid for more than
one host and where it is better not to ask the user again for the request to
another host. If an administrator depends on this he/she is doing something
wrong. The user should get a new warning for each host maybe resulting in
bugging the admin/webmaster (which would be a good thing).

> His proposed solution does not eliminate the MITM attack vulnerability that
> the user brings on himself by manually validating the cert.  Increasing the
> user's level of knowledge of the scope of vulnerability does not eliminate 
> the vulnerability.  

The proposed solution was only something I wish for "power users", considering
myself such. I fully agree that this will not increase the security for the
average visitor of the funny hamster site.

> I think the time for mozilla to approve and accept the patches for bug 259031
> is LONG overdue, and I urge Gerv or Dan to take the necessary action to unblock
> it and get it into the product, with all due haste.  But I don't accept that
> this is a new vulnerability.  It's the same old MITM vulnerability to which
> users subject themselves by manually validating an otherwise-invalid cert.

I would be very happy if the patches in #259031 were accepted (given they do
what the author says) but they alone won't fix the issue. See above.
> The whole thing SSL is about is *not* no ask users to make security decisions.

But in fact, when the security software says "this cert is not valid", and the
user decides to override that and proceed anyway, the user most certainly *IS*
making a security decision.  I would be happy to take that ability away from 
the user, but users seem to demand the ability to make that decision, even if
they do not understand the decision they are making.  

When the security software says "the validity of this cert cannot be proven" 
and the user says "use it anyway", the user is deciding to treat the cert as 
if it was valid.  The user is telling the software to treat the certificate 
in all respects as if it was provable valid.  That is a security decision ,
and thee user is making it.

Now, it seems that the dialog that asks the user whether or not he wants to 
do this may be misinforming the user about the nature of the decision he is
making.  If so, then the dialog's text needs to be fixed.  

BTW, I believe this is precisely how windows/IE handles this also.  When the
user chooses to override an invalid SSL server cert, that cert gets put into
windows' store of server certs that are trusted *as if* they have been 
provably valid in the first place.  
Whiteboard: [sg:spoof] → [sg:spoof] [kerh-bra]
Flags: blocking-firefox2? → blocking1.8.1?
Priority: -- → P1
Target Milestone: --- → mozilla1.8.1
We're not going to block 1.8.1 for this, but we'd happily consider a backend patch that doesn't involve significant UI changes (we're very close to the UI freeze).
Flags: blocking1.8.1? → blocking1.8.1-

*** This bug has been marked as a duplicate of 240261 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
or possibly a duplicate of bug 238142
This bug can be made public now that bug 240261 is, right?
cc'ing Jesse regarding Gavin's question
Nelson or kaie, please read through this bug report to make sure there's nothing mentioned here that makes the issue more severe than what's already public in bug 240261, then mark this bug as public.
Gladly.  IMO, all the information in this bug report was publicly known for
years before it was filed.  
Group: security
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.