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.

> 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.

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).

*** This bug has been marked as a duplicate of 240261 ***

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.