Closed Bug 205677 Opened 22 years ago Closed 20 years ago

Server Name Mismatch on Every Biff

Categories

(Core Graveyard :: Security: UI, defect)

Product:
Core Graveyard
Component:
Security: UI
Version:
Other Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mozilla, Assigned: KaiE)

References

Details

2003050908 trunk My POP account is hosted on a regular hosting service. The domain is hosted on a machine with many other domains, so the reverse DNS does not match my domain. I have set Mozilla to use SSL for POP. Whenever Mozilla does a biff check, it pops up a dialog warning me that the server name in my prefs does not match the server's reverse DNS. There is no option to make it stop, or to never warn me again. Every single biff pops this dialog.
This is a modal dialog in that the mail is not retrieved until "OK" is clicked.
-> PSM and this is wontfix (Kail told me that on IRC because i had the same problem) because this is a critical security warning. The Cert doesn't match the Hostname Leaving open because a developer/QA should confirm this
Assignee: sspitzer → ssaux
Component: Mail Notification → Client Library
Product: MailNews → PSM
QA Contact: stephend → bmartin
Version: Trunk → unspecified
That's insane. It renders Mozilla mail useless for anyone that has their own domain hosted with a hosting service.
I agree with the suggestion to WONTFIX. It's not insane. You probably use encryption, because you care about your password. But if you don't care whether cert and server identity match, you basically don't care for "man-in-the-middle-attack", where somebody else can pretend to be your server and steal your password. Requesting to disable the password is the same as not caring for security. If you don't care for security, but want to get rid of the warning, do not use encryption (use a standard POP port).
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Requesting to disable the password is the same as not caring for security. ^^^^^^^^ I meant warning.
You are oversimplifying. I don't think it's unreasonable to want to have my username/password encrypted in a POP3 session. Mozilla is making this impossible by dictating that I be equally concerned about a man in the middle attack. Why is it reasonable to dictate the importance of security concerns to users instead of letting the user decide? Can you even provide some data to suggest that a man in the middle attack is as common as password sniffing?
> I don't think it's unreasonable to want to have my > username/password encrypted in a POP3 session. sure > Mozilla is making this impossible > by dictating that I be equally concerned about a man in the middle attack. It's not making it impossible. All we do is we show a warning, trying to protect you. > Why is it reasonable to dictate the importance of security > concerns to users instead > of letting the user decide? Nobody dictates something. Our decision is "either you are secure or you are not". You still have the decision to not use security. > Can you even provide some data to suggest that a man > in the middle attack is as > common as password sniffing? A man-in-the-middle-attach is probably not very common. But it is sufficient if your attacker is doing it once in 10000 times when you check email. You will not notice, and your password is stolen, and your attempt to use security did not help you in any way.
By not allowing the user to disable the warning, we don't encourage the user to feel secure, when it fact, there is no sufficient security in place.
Instead you force the user to even more insecurity by not only allowing a man in the middle attack, but allowing password sniffing as well. If they're vulnerable to one attack we might as well make sure they're vulnerable to all attacks right? Ugh. It's no use.
AND you'll make sure that there is no chance of security. You're making into an all or nothing proposition. Security is _all_ about matters of risk and degree. You are not allowing the user to choose. This is always bad. You are dictating that if we accept the risk of a man in the middle attack that we give up on any security at all and leave ourselves vulnerable to *everything*
This warning is to protect you and Joe User. There is nothing secure if Mozilla would ignore this (also by request). Accepting the man in the middle attack means that you can simple use a "normal" pop3 connection because there is no difference ! IMHO it's the best solution if I read your comments because you don't see the reasons for this and you also would not see the risk if you could ignore this warning. You think that you are secure because you use a SSL connection but the truth is that you can be very easy attacked. Someone who can sniff you connection (to get your passwords) can also very easy do a "man in the middle" attack. verified wontfix
Status: RESOLVED → VERIFIED
*** Bug 213132 has been marked as a duplicate of this bug. ***
I complete understand the rationale behind setting this WONTFIX, but I would like to offer another idea, though it might be in vain. You claim that ignoring this message is the same as not using SSL, which is wrong. Being able to disable this warning permanently would be. I offer this solution instead. When the user connects to a server with an untrusted cert, he can decide whether to accept it temporarily or permanently, and review the contents of it. If the domain name is mismatched, another dialog is presented with the option to review the certificate. What about giving the option to explicitly trust THIS certificate (and this one only) permanently? If the security cert changes again, a warning would be presented that it has changed. I realise that any lapse in the security policy is a potential risk for the user, but I do not see how this would be any less secure than allowing the user to trust a non-trusted certificate or self-signed one. As long as the user is given ample warning that this is a bad and dangerous thing to do, and should only be done if the user knows the cert is valid, it should be okay. Is there any chance of this happening? Maybe just an option that is disabled by default so unless a user specifically wants this, he won't even have the option? Last, I just want to contend that if you trust a certificate with the domain mail.anydomain.tld and you have a domain mail.yourdomain.tld which resolves to the same server, it IS secure. The reason this is an issue is not because someone is too lazy to get a cert, but because he is not able to have his own cert on a shared server.
*** Bug 209299 has been marked as a duplicate of this bug. ***
I agree with comment 13 by ds@catull.us. Why can't I opt to trust that specific certificate, whether or not the domain matches? If I know for sure that that certificate is the correct certificate, whether the domain name matches or not, I think I should be able to trust it like any other certificate. I guess my real question is why can't I permanently trust a certificate whose domain name is mismatched?
I'm bothered by the resolution of this bug, because (assuming I understand the reported problem correctly) this resolution appears inconsistent with how mozilla handles the same problem for https. For https, mozilla does allow the name mismatch to be overridden for the rest of the mozilla session. That is, for as long as the mozilla process continues to run. That way, you get this warning at most once per mozilla session for https pages. I think it's reasonable for IMAPS and POPS to work the same way as https in this regard, and in fact, I'm surprised that it doesn't. Kai, any reaction to that statement?
When I wrote my earlier comments, I obviously didn't realize for https overriding is possible. Nelson, your argument is good, Mozilla should be consistent.
Kaie, in light of your comment 17 I think it is appropriate to reopen this bug.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
My guess would be that either the server or NSS is failing to cache the SSL session, so each reconnection does a full handshake. PSM doesn't cache answers to mismatch dialogs, it's just that NSS caches the SSL session, so most connections after the first resume the handshake and thus don't recheck the cert.
The NSS CERTCertificate structure includes a pointer to a list of alternative host names that are not in the cert, but for which the user has explicitly chosen to allow the cert to be used. The function is NSS that determines whether or not there has been a cert name mismatch checks that list of names in addition to the names in the cert itself. The function that adds names to this list is CERT_AddOKDomainName. It takes as arguments a pointer to the CERTCertificate and a pointer to the string that contains the exact hostname as it appeared in the URL for which the user approved the mismatch override. mozilla has to call this function to register the override. I believe mozilla does for https, and I suspect it does not for other protocols.
Mozilla calls it at http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSIOLayer.cpp#1344 Note that the CERTCertificate's ref count must not go to zero, or the cert will be deleted, and the list of "OK domain names" will be lost. So, mozilla wants to avoid deleting the reference to this cert until the user shuts down mozilla or switches profiles.
To the best of my code reading ability, Mozilla calls that function for all protocols. Mozilla does all bad cert handling the same, there is no different code for different protocols.
...in any case, this bug is unlikely to make progress without a test case server.
This bug is about POP-over-SSL. It could be easily tested, using ANY POP-over-SSL server with a valid SSL server cert. John, do you have access to one of those? I used to. Let me see if it still works.
Also, If all protocols call this code, then the most likely explanation is that some of those protocols cause the last reference to the server's CERTCertificate object to be removed, causing the object to disappear and with it the history of "OKdomainNames", and others are preserving one or more references to it. I'd guess that the https code somewhere calls CERT_DupCertificate to obtain another reference to it, and that other protocols do not.
John, the pop-over-SSL server mail.comcast.net still works although bug 202575 is still an unresolved issue for it. If you would like I can set up an account there for you. To test the problem described here, you would create an /etc/hosts file entry for a host named (say) mail.comblast.net with the IP address of mail.comcast.net. Then you would configure your mozilla email account to use the server named mail.comblast.net. When mozilla contacted that server, it would experience a host name mismatch. Should be all you'd need.
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Status: REOPENED → NEW
*** Bug 240180 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > *** Bug 240180 has been marked as a duplicate of this bug. *** Is anyone actively working on this bug? I have to say that in reading all these comments, if I'm on any server that hosts multiple domains, and they don't reverse DNS then the cert becomes useless regardless because you can never verify the other end, by the logic presented. But clearly a known, good cert that mismatches domains is better than one that isn't. Further, if a cert is presented by a man-in-the middle for the domain that I know is wrong but mozilla thinks is correct, can't that get through despite the fact it shouldn't? Granted it's justa theoretical example, and my security knowledge doesn't really take into account the practical points, but it seems that there is something broken about not allowing a secure connection to occur without making me explicitly endorse it and not requiring that for other secure connections just because they fit certain "sanity checks."
*** Bug 274356 has been marked as a duplicate of this bug. ***
Assignee: nobody → kaie
QA Contact: bmartin
why not adding something like "ignore that this certificate for the domain "mail.a.example" is used on "pop.a.example" ? This wouldn't allow a man in the middle attack...
Matti, see comments 16 20 and 25 above. NSS already has code to do exactly what you want. Some of the protocols in mozilla do it (use the NSS code) correctly, with the result that they don't have this problem of getting a mismatch every time they visit the same server. Other protocols evidently don't do it right, and have this problem. Because protocols such as https get this right, I believe this is not an NSS problem, but rather a problem with the speicific protocol(s) for which this is a problem (e.g. pop3). I believe that if the protocols call the right NSS calls, and don't discard the last reference to the cert upon which they have bestowed these rights, it will work. Perhaps this bug is assigned to the wrong product, component. Perhaps it should be assigned to pop3 developers rather than PSM.
I'd have to agree with John that there's NO cert handling code in the mailnews protocol code - it all happens at a lower level, so there's little opportunity for the mail code to be doing something wrong. Neither pop3 or http cache connections, so it can't be some sort of connection caching. Maybe https is doing something more with cert handling? We basically call nsISocketTransportService::CreateTransport with a connection type of SSL and get out of the way. We pass an nsIInterfaceRequestor so PSM can throw prompts up, etc. Perhaps there's something special about biff, which runs w/o a msg window. Jerry, does this same alert pop up every time you hit get new mail?
It's currently asking me every Thunderbird session. It seems to cache the answer for the session. An improvement, but still annoying.
ah. Now, I believe that is an NSS thing, though Nelson can correct me if I'm wrong :-) So, we could close this bug, if I understand correctly. I think there's another bug open about remembering that decision across sessions. Either that, or we consider it a bad idea...
Someone will have to check on Mozilla. When I filed this, it asked for every single biff.
Mozilla and thunderbird share the same backend code, so it's unlikely that they're different.
I have an ISP who setup an SSL cert on the POP side (just for me!). This ISP happens to have multiple domain names for all hostnames. So, I changed the POP server hostname in my mozilla mail account preferences to one of the other domains. When I first checked my POP mail, I got the warning about the hostname mistmatch, and was able to override it by clicking OK. On subsequent clicks on "Get messages" for this POP account, I did not get the warning. I do not know if this is because mozilla remembered that I wanted to override this, or simply because in subsequent clicks and POP connections, the SSL session was restarted and therefore the server's certificate didn't have to be checked again. One would have to leave the browser and wait for the SSL session to expire (24 hrs by default) to find out if there is another prompt. Perhaps the original poster was using a server that didn't do SSL session caching ?
Per recent comments, this code is working as designed with correctly functioning POP servers. Resolving INVALID.
Status: NEW → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → INVALID
I certainly disagree with resolving this bug as invalid. If we're going to give the user UI to choose to continue to use a cert for a site that it doesn't name (for the remainder of the process lifetime), then that feature should work. I believe there's no NSS bug here. When a user chooses to mark a cert as trusted for use with a site whose name does not appear in the cert, that info is recorded in the NSS cert object. In order for that decision to persist, the NSS cert object must not be freed by the calling code above NSS. If the user is shown UI giving him a chance to choose to allow the cert for a certain web site, and then all references to that cert object are closed, then the decision is lost. I think that's the root cause of this complaint. Apparently, for https, the decision is effectively preserved, but for email it's not. That's not a difference in NSS. It's a difference in the way that NSS is being used by https vs email. I don't know how many layers there are above NSS for email, so I cannot comment on whether it's a PSM problem or an email problem, but it's not NSS's job to hold that cert reference, it's the higher layer's job.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Wait. Re comment 35, Jerry, are you saying that it is no longer complaining about mismatch for every biff, but only once per process lifetime? If so, this bug should be resolved works for me. That's the intended behavior.
that was my understanding - re-resolving.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
This bug appears to be RESOLVED, but I still have the problem when using Thunderbird. I get a warning every time I get mail. If I set Thunderbird to check for messages every 5 minutes, I get the warning dialog every five minutes. The certificate is made out to "mail.pacifier.net". The POP3 server is "mail.iinet.com". Trying to get mail from mail.pacifier.net doesn't work. By the way, the Help button on the Security Error: Domain Name Mismatch dialog doesn't do anything.
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.