Closed Bug 228684 Opened 21 years ago Closed 17 years ago

Remember overrides of Certificate Domain Name Mismatch

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 387480

People

(Reporter: jacobc, Assigned: KaiE)

References

(
URL
)

Details

(Whiteboard: [sg:want P3]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031210 Firebird/0.7+ (aebrahim)
Build Identifier: Mozilla Thunderbird 0.4RC1 (20031201)

Many hosted domains include SSL-secured IMAP email that uses a generic
certificate belonging to the ISP.  For example, I own a domain
'spaceshipnofuture.org' that is provided by 'dreamhost.com.'  When I connect to
'mail.spaceshipnofuture.org,' the server presents a certificate with the
hostname 'mail.dreamhost.com.'  Because of this, Thunderbird will (correctly)
display the Domain Name Mismatch dialog on initial connections to this mail
server.  Every time I start Thunderbird, I must click through this dialog, which
is easily lost when many other windows are open.  I would like the option to
disable this dialog, perhaps with a checkbox on the dialog that reads something
like "Display this error next time."  

I realize that this is potentially dangerous, but I think some users would be
willing to take the risk.  The risk could also be mitigated by only disabling
the dialog for specific domain name combinations; for example, Thunderbird would
remember that I disabled the dialog when encountering a cert for
'mail.dreamhost.com' when connecting to 'mail.spaceshipnofuture.org' -- if, upon
 a subsequent connection, a cert for 'foo.com' was presented by the server, then
Thunderbird would display the Domain Name Mismatch dialog again.

Reproducible: Always

Steps to Reproduce:
1. Add an IMAP account and turn on SSL connections for the account.  The account
must be for a server that presents a certificate that does not match its hostname.
2. Check mail for this account

Actual Results:  
Domain Name Mismatch dialog is displayed.

Expected Results:  
The Domain Name Mismatch *should* be displayed by default; however, it would be
helpful to be able to disable this dialog.
Component: Mail Window Front End → Preferences
OS: Windows XP → All
Hardware: PC → All
this is especially annoying when you have thunderbird set up to check mail every
minute -- it presents the dialog each time.
Another reason: I use ssh tunnels a lot for both IMAP and SMTP. In general, I
have to use a hostname that I can put in my /etc/hosts file, and which doesn't
conflict with the real hostname for the remote server, so that I can continue to
use that for non-tunnel use.

e.g. I often use hostnames like:

127.0.0.1   ssh-realhostname

the loopback address is used, since of course the tunnel endpoint is here, on my
system.

When I use these tunnels for IMAP/SSL or SMTP/TLS, I always get prompted with
this warning, since of course ssh-realhostname != realhostname, even if we
assume that realhostname == certificatehostname.

I'm happy to see the warning, but I don't need to see it every single time.
It would be good if you could select a checkbox that said something like "Don't
show this again," but it would only store information about those specific hosts
in a list which would be editable in the advanced preferences.
I am experiencing a very similiar situation. When I connect to my IMAP server
the address is: "username.myserver.com" , however the security certificate is
for "*.myserver.com" because each user is connecting to a different subdomain.
This raises an error in Thunderbird 0.9.2 and can be rather irritating.

I am not sure what the expected behavior is for wildcard characters in a
certificate domain name. Should I file this as a seperate bug or is Thunderbird
handling it correctly? If Thunderbird is handling it correctly, could you please
add an option to "Ignore this warning in the future". Thanks.

This bug annoys me a lot too...

What about prompting the user with those standard choices? Sounds wise.

  * Accept this certificate permanently
  * Accept this certificate for this session only
  * Do not accep and do not connect

My 2 cents.
I think this is no enhancement, this is damn annoying and you can't do anything
about it. It's an usability bug.
=> Setting Normal + mail3 + proposing 0.9

I am also not sure if it's the right component
Keywords: mail3
Target Milestone: --- → Thunderbird0.9
please don't put bugs into milestones for me.
Keywords: mail3
Target Milestone: Thunderbird0.9 → ---
I have this problem in addition to the fact that the certificate for my mail
host actually won't become valid for a year. This is an error on the part of the
mail host, but its a free service run by volunteers. So they will get around to
fixing it when they can.

In the mean time I don't use SSL, because thunderbird complains every time it
goes to get mail from the server.

It would be very nice to ensure that any scenario where Thunderbird complains
about a certificate can be overridden by the user.
Could we at least get this changed from an enhancement to a bug. The fact that I
have to click a box everytime I start thunderbird is an error on thunderbird's part.

Being able to save the cert. where ever certificates are saved would be nice. I
found where one could import certificats, but I have no idea where the
certificate is. It must be temporarily stored locally during a thunderbird
session, because thunderbird only displays the annoying window at start up and
only for the first account of the same mail server.
My email server uses two aliases ukc.ac.uk and kent.ac.uk the SSK certificate is
issued by the ukc domain and my email is delevered from the kent domian.
Therefore there is a mismatch and it everytime thunderbird looks for new email I
have to confirm the certificate. Is there some way of confirming once per
session and letting it confirm in the background?
I have the very same problem (I am hosted by dreamhost, too). It's a real pain
in the butt. Cedric's suggestion in comment #5 of having the same options as for
self-signed certs (accept permanently, blah blah) sounds just fine to me.

I can confirm this thing in TB 1.0 final, for Chrissakes!
(In reply to comment #11)
> I have the very same problem (I am hosted by dreamhost, too). It's a real pain
> in the butt.

I have a client hosted by Dreamhost, and there is an ugly hack you can use that
will work for Dreamhost and probably other situations as a workaround until this
bug gets fixed. What you do is add an entry to your HOSTS (or /etc/hosts) file
that maps the domain name used in the certificate to the IP address of the IMAP
server you are connecting to. Then adjust your Thunderbird settings to connect
to <certificate-domain> instead of <IMAP-server-domain>.

So for example, my client normally connects to mail.example.com, but the
certificate from the ISP is for mail.dreamhost.com. So a HOSTS entry is added like:

1.2.3.4     mail.dreamhost.com

where 1.2.3.4 is the IP address of mail.example.com. Then Thunderbird is updated
to connect to mail.example.com.


Granted this is a bit fragile, as it'll break if the ISP changes the IP of the
IMAP server, and it makes the machine referenced in the certificate inaccessible.
Flags: blocking-aviary1.1?
not a 1.1 stopper.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Scott: I see there's been no work on this bug for 4+ months, and all of a
sudden, with TB 1.1 coming up, you decide it's not blocking aviary.  OK, so we
won't have a usability fix for this in the months to come?

This thing has been bothering a sheer amount of people since TB first came out.

I assume certificate management is handled by some generic layer that can be
found in most Mozilla products.  This layer allows the kind of
Always/JustThisTime/Never management that was referred to in comment #5.  AAMOF,
such a behavior is provided for self-signed certificates in TB.

Could you please explain WHY oh why it is so difficult to extend this kind of
behavior to domain mismatch?  Every single time I've opened TB in the past year
and over, I've had to press Enter to the mismatch prompt.  It's annoying and
reflects a very real and commonplace situation: ISP mutualized hosting!

Why is this thing still enh/new ?!
I'm nobody here, I'm "just" a user of Thunderbird, but I have to say that it
infuriates me to see that comment from Scott MacGregor.

This is a bug.  It needs to be fixed.

I don't want to sound like a jerk, but as a user, I am blissfully ignorant of
whatever secret concerns may drive you to decide that certain bugs are stoppers
and others are not.  My concern is simple: I want the software to work.

Seeing that this bug is not going to be fixed severely damages the reputation of
mozilla in my mind.  It certainly doesn't help that no reason is provided
either.  This is the kind of thing that makes me think I'm going to drop
Thunderbird and tell anyone who asks not to use it --- not because it's not a
decent piece of software, but because I continue to receive the impression that
Mozilla developers are not sensitive to the desires of actual users of their
programs.
this is a core security lib issue - if you search bugzilla, you'll find a lot of
reports of similar problems. The security team feels it would be a security hole
to add an accept permanently button to this core security lib dialog, for
various reasons, including man in the middle attacks, if I understand correctly.
I'm sure that's not going to make anybody happy, but it's totally out of
mailnews control.
(In reply to comment #16)
> The security team feels it would be a security hole
> to add an accept permanently button to this core security lib dialog, for
> various reasons, including man in the middle attacks

?

I'm saying *this* particular certificate for *this* particular server. If
someone tries to MITM, that's a change. Why is this a security problem?

And really, this bug makes using TB a PITA sometimes. For _this_ I switched
email clients?
I'm not a security expert, and believe me, this is a pain for me since one of
the servers I use has this problem. see bug 255025 among others. Cc'ing some
security experts...
If you add an option that disables name checking, there absolutely will be a
CERT alert, major vulnerability report about it.  You will have essentially
killed SSL's ability to protect you from all active attack.  

the mozilla browser/email client has a feature where when you first override
a cert name mismatch, it remembers the name of the host you were trying to 
access and associates that info with the cert.  Thereafter, (during the lifetime
of that process) if you visit that host again, it will remember that you
previously chose to allow that cert to be used for that hostname, and will not
warn again.  

When that feature was first implemented, it didn't associate a hostname with
the cert, and instead marked the cert as valid for all hosts.  There were TWO
separate CERT alerts filed about that bug.  It was a situation where the user
had chosen to override security, and STILL CERT declared the product vulnerable
over it (and IMO they were right).

So, the moral of this story is that you must be very careful in what you 
choose to allow for overrides.  Don't make overrides any broader than they
absolutely must be.  

It's not difficult for server admins to get certs that list multiple hostnames
in a single cert.  That is a much preferred solution to this problem.
Oh, bug bounties were paid for all the bugs mentioned above as CERT alerts.
Probably not good to implement bugs that lead to paying bug bounties.
Hmm, on bug 255025 comment 1 someone suggested that it's the site's fault.  I'm
confused now: is it in fact Thunderbird's fault for not handling this (i.e.
these sites are using some kind of certificate strategy which is actually
sometimes a good idea) or does the problem only occur when the e-mail provider
is doing something they should *never* do?  That would be an important thing to
make clear from the start (which isn't to say, however, that even if it's always
the e-mail provider's fault, Thunderbird shouldn't allow an override when the
user wants one.  But if this is a sometimes valid thing for e-mail providers to
do then this problem should definitely be fixed quick).

Pardon my lack of security and network knowledge, I just really don't like this
problem.
(In reply to comment #19)
> the mozilla browser/email client has a feature where when you first override
> a cert name mismatch, it remembers the name of the host you were trying to 
> access and associates that info with the cert.

That's all _I'm_ asking for, actually. If you want to warn me _once_ (for the
life of the process) that there's a mismatch between the cert and my server
name, that's just fine. But to ask me _every_single_time_ I try to check my
email is just ridiculous.
The hostname association feature I described is only good for the lifetime 
of the process.  Each time you restart seamonkey, you get warned about any
hostname mismatches the first time you enounter the site.  

Having said that, I should also mention that the SSL protocol is designed to
avoid sending and validating certs on every connection.   Having once connected
and validated the cert, the client and server should establish a "session key"
which is then re-used in subsequent connections between that same client and
server for up to 24 hours, or the lifetime of the process, whichever is less.  
When a session key exists, the client and server should be able to negotiate a
handshake without any certs being involved.  

If you are indeed being asked to revalidate certs on EVERY connection attempt
then something is wrong in the implementation or configuration of either the
client or the server.  It sounds like one or both of their SSL session caches
isn't working.  mozilla's SSL client cache code works fine in the browser.  

In reply to comment 21, 
Any SSL server that sends out a certificate that does not contain the 
DNSname(s) by which that server is known is misconfigured, IMO.  

One of SSL's key values, one that sets it apart from many other crypto 
protocols, is its ability to detect MITM attacks and protect the user from
them.  This ability depends on the client being able to determine, 
algorithmically, that the cert it receives from the server is the cert
for the server that the client's user intended to contact.  Today, the
convention (in RFC 2818) is that the client must find the DNSname by which 
it tried to reach the server in the certificate's list of DNSnames.  

If the client receives a valid cert that happens to belong to someone other 
than the server it intended to reach, and the client does not detect this 
and report it, then it is trivial for a bad guy to interpose between the 
client and server and masquerade as the server.  The hostname mismatch 
dialog is the ONLY thing that gives the user a chance to decide to avoid
being succesfully MITM attacked.  A user who routinely ignores all host
name mismatch errors is a user who is completely vulnerable to MITM attacks.

SSL is largely regarded as being immune to this attack precisely because 
the vast majority of SSL clients properly check the servers' certs to 
ensure they contain the desired host name.

Any server admin who runs a server with a cert that does not contain all the 
names by which that server is commonly known and used it forcing a situation on
his client users in which they will experience host name mismatches.  IMO,
that's a bad thing for a server admin to do to his users.  

Now, we can debate whether or not a client should allow its users to override
these errors.  There's no standard that says clients must or ever should do
that.  And we believe that most users always click past any errors that their
clients allow them to click past, so the ability to click past the host name
mismatch errors is effectively a vulnerability in itself.  If the clients did
NOT offer a way to click past this, you can be sure that a lot of lazy sysadmins
woudl fix their certs, and users would not complain about having to click
through so much.  In some sense the ability to click through is itself the cause
of these complaints.  

So, yes, if you're using a service from some server (especially if you're paying
for it) and you're finding that you always have to deal with cert name mismatch
dialogs, then your service provider should fix his server's cert.  That's his
responsbility, IMO.  He should not be contiually putting you in a position to
have to deal with alerts that serve a legitimate purpose of detecting MITM
attacks.  By being forced to repeatedly click past that warning, you become
trained to ignore that error, and someday you may be victim to MITM because of
that.  
Nelson:

First, thx for all the comments, they help getting a better understanding of the
issue.  I realize changing this is outside mailnews scope, but since this is the
bug where most of the discussion takes place, I'll add a comment here.

IMHO, putting up the same Name Mismatch dialog every single time TB starts (or
every 24hrs, as per the session key expiry you mention) only serves to make
users more apathic to such dialogs, so they end up disregarding them at large.

Indeed, as long as the original Mismatch dialog prominently displays the
/intended/ DNSname and the /cert's/ DNSname(s), why is that so dangerous to
allow the user to permanently allow such "human match"?  Later on, if the cert's
DNSnames list changes, still w/o containing the intended DNSname, a new Mismatch
dialog would appear.

Such an override would only declare the actual cert to be OK for the intended
domain, in the state it was at override time.  I can't seem to find a reason why
this constitutes a security issue (unless, of course, the user carelessly
allowed permanent override, i.e. w/o regard to the cert's details, but then it's
not the product's fault, it's the user's fault).

Aside from this, you mention it's easy for server admins to produce a
multiple-DNSname cert.  I seem to recollect sysadm friends who did not appear to
find a workable road towards this (this was for HTTPS covering of virtualhosts I
believe).  Would you by chance have a link at hand?
Brendan writes in comment #15:
> ...it infuriates me to see that comment from Scott MacGregor.
> This is a bug.  It needs to be fixed.
> 
> Seeing that this bug is not going to be fixed...

Scott's comment was "not a 1.1 stopper." That doesn't mean the bug won't be
fixed, only that other work has priority with respect to the 1.1 release.

If you think the bug should have a higher priority, protest (I'm not sure if
that accomplishes anything), vote for this bug, write a patch, or hire a
developer to write a patch.


Nelson Bolyard writes in comment #19:
> the mozilla browser/email client has a feature where when you first 
> override a cert name mismatch, it remembers the name of the host you 
> were trying to access and associates that info with the cert.  
> Thereafter, (during the lifetime of that process) if you visit that 
> host again, it will remember that you previously chose to allow that 
> cert to be used for that hostname, and will not warn again.  

And that seems to be precisely the functionality desired to address this bug.
(Though the duration shouldn't be only for the life of the process. It should be
permanent. Having non-technical users see a warning they don't understand after
every restart doesn't improve security.)


> When that feature was first implemented, it didn't associate a 
> hostname with the cert, and instead marked the cert as valid for all 
> hosts.  There were TWO separate CERT alerts filed about that bug.

Interesting, and something for the developers to keep in mind so the same
mistake isn't repeated, but what's your point?


> It was a situation where the user had chosen to override security, 
> and STILL CERT declared the product vulnerable over it (and IMO they 
> were right).

Of course they were right. It was a buggy implementation. So?


> It's not difficult for server admins to get certs that list multiple 
> hostnames in a single cert.  That is a much preferred solution to 
> this problem.

Review the earlier comments on this bug. The condition was originally
encountered by users of ISPs who map customer specific domains, such as
mail.example.com for the example.com customer, to a shared mail server. It would
be impractical to create a certificate that lists thousands of domains and keep
it up to date as customers were added/removed from the mail server.

Why not just have customers directly access mail.isp.net? Presumably the ISP
uses the customer-specific subdomain to provide a level of indirection. They can
reallocate how customers are assigned to mail servers transparently by updating
DNS records.

The other scenario mentioned in Comment #2 was port forwarding.


Adam writes in comment #21:
> ...is it in fact Thunderbird's fault for not handling this (i.e. 
> these sites are using some kind of certificate strategy which is 
> actually sometimes a good idea) or does the problem only occur when 
> the e-mail provider is doing something they should *never* do?

I think it is somewhere in the middle. Thunderbird is correctly following the
standards, but ISPs face some practical limitations in adhering to the
standards. It's not unusual for a client (web, mail, whatever) to accommodate
real-world usage.


David Bienvenu in comment #18:
> see bug 255025 among others.

Seems like bug 255025 is a dupe of this bug. (And maybe this bug should be
likewise moved to Core, if that's where the problem is.)


Nelson Bolyard writes in comment #24:
> ...we believe that most users always click past any errors that 
> their clients allow them to click past, so the ability to click past 
> the host name mismatch errors is effectively a vulnerability in 
> itself.

Valid point. It's also why I'd rather train clients (customers) to pause and ask
when such dialogs appear, rather than get them in the habit of blindly
dismissing such dialogs.

(While I was writing this Christophe Porteneuve posted a comment that makes the
same point.)


> If the clients did NOT offer a way to click past this, you can be 
> sure that a lot of lazy sysadmins woudl fix their certs...

Also probably true, providing those who operate the mail server can't simply
respond by saying, "we don't support Thunderbird."


> [your service provider] should not be contiually putting you in a 
> position to have to deal with alerts that serve a legitimate purpose 
> of detecting MITM attacks.

I think permanently dismissing such warnings holds minimal security risk, if
implemented correctly, which is to warn the user again if any of the elements
(the IP, cert host, and real host) change.


To spell out what others have intimated, fixing this bug would actually increase
security by drastically increasing the ratio of significant warning dialogs.

Consider a MITM attack in which evil.com intercepts communications between mail
server X and its users.  User Joe uses Thunderbird with its current
functionality, while user Jane uses a mail client that lets her permanently
trust a particular certificate/domain combination.

When evil.com presents its certificate to Joe, and Thunderbird warns Joe of the
discrepancy in evil.com's certificate, Joe clicks the OK button in the warning
dialog immediately, without ever looking at the text of the warning, just as he
always does (after the first few times) when he starts the application and it
warns him about the domain discrepancy in mail server X's certificate.

When evil.com presents its certificate to Jane, on the other hand, and her mail
client warns her of the discrepancy in its certificate, Jane pays attention,
because she hasn't seen that dialog for months (ever since she first told her
mail client to permanently trust mail server X's certificate for her domain).

So evil.com steals Joe's authentication tokens and accesses his email, but it
doesn't steal Jane's, who contacts her mail administrators after receiving the
unexpected warning dialog and learns she is under attack.

This example isn't merely theoretical.  My mail provider (pair.com) hosts
thousands of domains, and its certificate is one of those whose domain
(*.pair.com) doesn't match my mail server's domain name (mail.melez.com).  I
start Thunderbird several times a day to access my mail on that server, and
every time I do so, I dismiss the domain mismatch warning dialog the moment it
appears.

Like Joe in the example, this behavior leaves me susceptible to MITM attacks. 
It's also a rational, calculated risk, since the warning dialog is virtually
always seeding doubt about what is actually the correct server.

For this warning dialog to meaningfully warn users of a potential attack, it
should appear rarely and only when an attack appears likely.  In the mail world,
where mail servers increasingly serve multiple domains and users generally
access the same small subset of servers, that will be best accomplished on the
client side by allowing users to permanently accept a certificate/domain
combination.
Well said, Myk.  It's clear that if Thunderbird is going to be completely
secure, it's going to have to not present an option to accept the certificate at
all, but simply an error message with a note to tell your site administrator to
fix their server.  This would of course cause many people to be unable to use
Thunderbird.  If any of these connections are to be allowed, making the dialog
go away permanently (for certain domains only) is better than having it recur.

How about the following idea if we want to get really secure?  Have a
configuration option which says something like "allow certain invalid
certificates", which is off by default.  When an invalid certificate arrives,
display an error, similar to the one currently displayed, but which tells users
that they must enable that option if they want to insecurely work around their
e-mail provider.  Then they go select the option, try to get their e-mail again,
and then they're asked if they want to allow certificates that have that
particular form.  This way, only users with bad e-mail providers are at
significant risk (lower risk than now, anyway).

Oh, and by the way, under that configuration option I mentioned you could have a
list of certificates that are allowed through, which the user can manage.
This whole discussion is ridiculous. This bug is a textbook example of many
different invalid uses of PKI. It bug should be resolved INVALID. If you want to
use PKI, which includes SSL/TLS, you need to follow its standards. Using PKI
with invalid certificates offers the same level of security as not using PKI at all.

There are known solutions to the problem :
1) the cert issuers/users could fix their certs to become valid . Then, the
mozilla pop-ups will disappear.
2) the users could switch to the non-SSL port. There will be no pop-up about
mismatched cert in this case either.

But the solution should NOT be :
3) the security in mozilla clients should be compromised . This is what this
"enhancement" request is about . With enhancements like these, who needs bugs ?

Julien, with all due respect you are wrong.

Securing a connection using SSL/TLS can serve two purposes:
* Verifying the identity of the other party
* Encrypting the connection

You are suggesting that because users do not want to verify the identity of the
other party, they have no right to encrypt their connection and should use
non-secure connections only.

As others have pointed out, letting the user choose how much of the identity
verification should be done does increase end-to-end security (and in no case is
the security of the client(!) compromised).
Klaus,

SSL/TLS rely on X.509 certificates. When you get an X.509 certificate, you must
verify that it matches your party. Show me a standard document that says you
have a choice not to do that.

(In reply to comment #32)

> SSL/TLS rely on X.509 certificates. When you get an X.509 certificate, you must
> verify that it matches your party. Show me a standard document that says you
> have a choice not to do that.

Sure, but (again, with all due respect) that seems to be beside the point that
Klaus just made.  You said earlier that "Using PKI with invalid certificates
offers the same level of security as not using PKI at all," and Klaus pointed
out that an encrypted connection is nevertheless plainly better than an
unencrypted connection.  Bear in mind also that ideal certificate management is
probably impossible and certainly prohibitively expensive in a virtual hosting
situation, which is what we're talking about here.

Go back and read the original problem description.  If I attempt to connect to
"myhost.com," and the server presents a certificate for "actualhost.com," but I
know that "myhost.com" is simply a virtual host on "actualhost.com," why can't I
tell my email client to go ahead and treat this particular combination as valid?
 Especially if I make this choice with full knowledge of the risks involved?
Jacob, I disagree that an encrypted but unauthenticated connection is plainly
better than an unencrypted, unauthenticated connection.

If somebody has the ability to snoop through your traffic (the threat you are
protecting against by encrypting), they have access to router data somewhere,
and almost certainly also have the ability to run an MITM attack on you just by
reconfiguring router settings. Thus, the cost of the MITM attack is only
marginally higher than snooping plaintext traffic, and it is questionable why
you would want to protect against one attack but not the other attack of very
similar cost.

The problem of SSL virtual hosting needs to be solved properly, through standard
ways that don't involve compromising security, such as including multiple names
in a cert, wildcard certs, or simply using a different cert for each domain,
either through a dedicated IP per domain, or a dedicated port if extra IPs are
not available. The later shouldn't be any more expensive for the ISP - and the
limit is reasonable, 65536 ports, ie. 65536 domains, per IP address, which
should be plenty. Most clients, and certainly mozilla mail, allow you to
configure the port for mail servers. In the future, a single IP:port will also
be usable for multiple certs for virtual hosting. See bug 116168 and 116169 .
The ISPs have no excuse but their own laziness not to respect the standards.
This argument cannot be used to justify compromising security in mozilla. If you
want to do that for yourself, fine : since you understand the risks, you can
pull the mozilla source, remove hostname check yourself, and recompile it. Most
people don't understand the risks, and this shouldn't go into the main tree
under any circumstance, not even as an option.

Julien

> If somebody has the ability to snoop through your traffic (the threat you are
protecting against by encrypting), they have access to router data somewhere,
and almost certainly also have the ability to run an MITM attack on you just by
reconfiguring router settings.

in a non-switched environment anyone on the same local network can sniff network
traffic but usually cannot reconfigure routing.

Encryption does improve security.

Going by your argument, the user should not be given the option to override the
hostname mismatch even by session.

We are all in agreement that a working PKI and matching certificates are ideal
and desirable, but we do not live in an ideal world and we need to choose
between several alternatives, none of which are ideal.

Yes the people discussing this here know how to work around the problem (the
easier solution than changing the source is to define the matching hostname
locally in etc/hosts), this is not about finding solutions for a bunch of
developers who understand the issue and can fix it for themselves but solving
the problem for Mozilla users at large who don't know and either decide to use
another mail client because of this "feature" or blindly accept the security
warning, and any other security warning they will get, every time because they
are so numerous.

PS. The SSL 3 specification explicitly allows for secured connections without
authentication, maybe the right option for users who only want to encrypt
traffic is to provide an option to not authenticate the server (although
personally I think that authenticating the server with a known and
user-confirmed hostname mismatch is the better choice).

Klaus,

The mozilla user-at-large who doesn't understand about security should never
override this error, so if this is who it's for, then that's all the more reason
not to add an error. The security warnings are meant to be taken seriously, not
ignored. The mozilla users need to understand the servers they are connecting to
are at fault, not the browser. Switching to a less secure client doesn't solve
their security issue. The pop-ups are doing the users a service. Removing them
is a disservice to the user in the context of security. 

I'd say that for the mozilla users at large who don't understand security, most
of the security pop-up dialogs shouldn't have an override at all, neither
one-time "OK" button nor permanent.

The goal of security is not to make the mozilla browser the most popular browser
on earth. It is not to accomodate servers that don't follow standards. It is to
make the application secure. When it comes to implementing security standards,
there isn't the same margin for interpretation as there is with, say, the HTML
standard. The risks of being lenient are much higher with security. security
standards exist for a reason, and they need to be respected, by both the client
and server sides. Mozilla should stick to enforcing these standards.

If users want to stop using mozilla because it's secure, it's their own loss. If
server administrators break security rules which result in mozilla not working
with them, they should bear the consequences of reducing their user base. They
are the ones each and every one of you need to complain to, to get to fix their
servers. You should not file "bugs" on mozilla requesting that the security
standards be broken. It will not happen.

Julien,

any comments on my observation that the SSL 3 specification does allow
encryption without server authentication?


Klaus,

Please be specific .
I assume you are referring to section F.1.1 of RFC2246, Authentication and key
exchange :

"   TLS supports three authentication modes: authentication of both
   parties, server authentication with an unauthenticated client, and
   total anonymity. Whenever the server is authenticated, the channel is
   secure against man-in-the-middle attacks, but completely anonymous
   sessions are inherently vulnerable to such attacks.  Anonymous
   servers cannot authenticate clients. If the server is authenticated,
   its certificate message must provide a valid certificate chain
   leading to an acceptable certificate authority.  Similarly,
   authenticated clients must supply an acceptable certificate to the
   server. Each party is responsible for verifying that the other's
   certificate is valid and has not expired or been revoked."

Total anonymity is possible with TLS, but the decision is dependent on the
protocol that runs a top. Sections 1 and D.3. support these statements :

"     - The peer's identity can be authenticated using asymmetric, or
       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
       authentication can be made optional, but is generally required
       for at least one of the peers."

Notice how it says "generally required for at least one of the peers". In the
cases we have discussed thus far, the client doesn't have a certificate, so the
peer is the server, and thus authentication is "generally required", not
optional . The "total anonymity" case is seldom specified.

Also, later, section 1 says :

   "One advantage of TLS is that it is application protocol independent.
   Higher level protocols can layer on top of the TLS Protocol
   transparently. The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS."

None of the protocols that mozilla is concerned with, HTTPS, IMAPS, SMTPS, and
POPS, specify that total anonymity is allowed .

Further :

"D.3. Certificates and authentication

   Implementations are responsible for verifying the integrity of
   certificates and should generally support certificate revocation
   messages. Certificates should always be verified to ensure proper
   signing by a trusted Certificate Authority (CA). The selection and
   addition of trusted CAs should be done very carefully. Users should
   be able to view information about the certificate and root CA."

Julien

I was referring to the SSL 3 specification, not the TLS specification, although
they are similar:

http://wp.netscape.com/eng/ssl3/draft302.txt (my highlights IN UPPERCASE)

5.5 Handshake protocol overview

   The cryptographic parameters of the session state are produced by
   the SSL Handshake Protocol, which operates on top of the SSL Record
   Layer.  When a SSL client and server first start communicating,
   they agree on a protocol version, select cryptographic algorithms,
   OPTIONALLY AUTHENTICATE EACH OTHER, and use public-key encryption
   techniques to generate shared secrets.  ...

   Following the hello messages, THE SERVER WILL SEND ITS CERTIFICATE,
   IF IT IS TO BE AUTHENTICATED.

Also in the section you quoted

   Implementations are responsible for verifying the integrity of
   certificates and should generally support certificate revocation
   messages. Certificates should always be verified to ensure proper
   signing by a trusted Certificate Authority (CA). The selection and
   addition of trusted CAs should be done very carefully. Users should
   be able to view information about the certificate and root CA."

there is no reference that the hostname must match the name specified in the
certificate, this is about trusted CAs (fortunately we have no disagreement
about CA trust hierarchies :-))
Klaus,

I referred to the TLS spec because it is more current.

Re : SSL3 section 5.5

In all the cases that have been discussed here, the server does send a
certificate. According to what you quoted, since the server sent a certificate,
then it must be authenticated [by the client].

Re : hostname check

The process of verifying a certificate requires that you have some identity
attribute and a certificate that is supposed to match the identity . The
definition of a certificate is that it is the binding between that attribute
(and other attributes) and the public key in the cert. In the
SMTPS/HTTPS/POPS/IMAPS protocols, the identity attribute is the hostname. This
is specified as part of the application protocols layered above SSL3/TLS, not in
SSL3/TLS itself . Eg. , see RFC 2818, HTTP over TLS :

3.  Endpoint Identification

3.1.  Server Identity

   In general, HTTP/TLS requests are generated by dereferencing a URI.
   As a consequence, the hostname for the server is known to the client.
   If the hostname is available, the client MUST check it against the
   server's identity as presented in the server's Certificate message,
   in order to prevent man-in-the-middle attacks.


> the client MUST check it against the server's identity as presented in the
server's Certificate message

Again no disagreement there, it MUST check that the names match and handle the
case when they do not.

The specification does not say what the appropriate behaviour is in that case,
and the whole discussion here is about what is appropriate, ranging from

* Never ever allow the user to connect
* Allow the user to connect but only after seeing a warning and accepting the
specific mismatch every time the client is started (current behaviour)
* Allow the user to connect but only after seeing a warning and accepting the
specific mismatch


But are we in agreement that it's more secure to allow the user to make the
dialog go away for specific hosts than for them to click it each time?  From
both of your arguments, it seems to follow that both those options are too
insecure, and users should never be allowed to connect to a site with an invalid
certificate.  Is that true?  Anyway, that's another problem completely from the
recurring dialog, and maybe even a problem for another bug report.

I'd personally say blocking all invalid certificates is too strict, especially
since a program may assume that it is itself correct, but that everything else
might be incorrect (including its users and whether other programs/servers
follow standards.  Though it's true that disallowing connections to things that
don't follow standards may still be the proper way to handle it).

Klaus, actually, RFC2818 does specify the behavior if the check fails. From
RFC2818, section 1 again :

   If the hostname does not match the identity in the certificate, user
   oriented clients MUST either notify the user (clients MAY give the
   user the opportunity to continue with the connection in any case) or
   terminate the connection with a bad certificate error. Automated
   clients MUST log the error to an appropriate audit log (if available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it.

> Klaus, actually, RFC2818 does specify the behavior if the check fails.

And all three options 

* Never ever allow the user to connect
* Allow the user to connect but only after seeing a warning and accepting the
specific mismatch every time the client is started (current behaviour)
* Allow the user to connect but only after seeing a warning and accepting the
specific mismatch for a defined period of time, including permantently

meet the requirement "If the hostname does not match the identity in the
certificate, user oriented clients MUST either notify the user (clients MAY give
the user the opportunity to continue with the connection in any case) or 
terminate the connection with a bad certificate error."

The specification does not say "notify every time a connection is established"
or "notify every time the client software is restarted".


Would addressing this bug be any more palatable to the security purists if the
problem was redefined as follows:

On the "Server Settings" page of "Account Settings" add an optional "Server
Certificate Name" field (probably on the Advanced dialog) where a user can
explicitly specify the name that Thunderbird should match the returned
certificate against.


Not as ideal as simply checking off "remember this" on the certificate mismatch
dialog, but it equivalently solves the problem, and requires that the underlying
Mozilla security subsystem perform an exact match between the certificate and a
user specified field. No guessing and no confusing dialogs presented to the
user. This also can be something a consultant or IT person sets up for a
non-technical user and can be specified in setup instructions supplied by an ISPs.

(In reply to comment #36)
> The mozilla user-at-large who doesn't understand about security should never
> override this error, so if this is who it's for, then that's all the more reason
> not to add an error. The security warnings are meant to be taken seriously, not
> ignored. The mozilla users need to understand the servers they are connecting to
> are at fault, not the browser. Switching to a less secure client doesn't solve
> their security issue. The pop-ups are doing the users a service. Removing them
> is a disservice to the user in the context of security. 

This is pure fantasy.  Users want to read their email.  Draconically enforcing
authentication protocols to guard against hypothetical security risks will
accomplish nothing except alienating the vast majority of users.

Moreover, even if you maintain that naive users should not even do the
per-session override, that doesn't explain why non-naive users should be
prevented from doing a permanent override.  From my understanding of the spec
quotes people have posted on this thread, including this option would not
violate the spec.  The override should specify exactly which host, IP, etc. are
being "trusted", and if any of these parameters change, a new warning box can
justifiably appear.
Julien writes:

> Jacob, I disagree that an encrypted but unauthenticated connection is plainly
> better than an unencrypted, unauthenticated connection.
> 
> If somebody has the ability to snoop through your traffic (the threat you are
> protecting against by encrypting), they have access to router data somewhere,
> and almost certainly also have the ability to run an MITM attack on you just
> by reconfiguring router settings.

This is demonstrably not correct in unswitched Ethernet as well as open wireless
networks as commonly configured in cafes and conferences.  While it is certainly
 possible that someone could mount a MITM attack in an open wireless
environment, this is significantly more work than just listening to packets for
passwords using (eg) Ethereal, and, as a result, almost certainly much less
common.  

Do you disagree?

[...]

> The mozilla user-at-large who doesn't understand about security should never
> override this error, so if this is who it's for, then that's all the more 
> reason not to add an error. The security warnings are meant to be taken 
> seriously, not ignored. [...] The pop-ups are doing the users a service. 
> Removing them is a disservice to the user in the context of security. 

Please re-consider the above paragraph in light of Myk's comment #25.  It seems
to me that he makes a compelling argument that the pop-ups actually increase
risk here, because they encourage the user to ignore them.  Worth keeping in
mind is that we're trying to deal with how users actually _will_ act in the real
world, not how they _should_ act.  Do you see some flaw in the reasoning in
comment #25?

I think Brendan and other posters also make a good point that there are really
multiple options here: status quo, or make it possible for everyone to override
this dialog permanently, or make it difficult but not impossible for clued
users/ISPs to override (eg via a pref).
*** Bug 255025 has been marked as a duplicate of this bug. ***
As I wrote in comments above, disabling all cert name mismatch checking 
discards the major security benefit of SSL for the sake of a few rare sites 
that have bad certs.  Such a change is guaranteed to create a CERT alert
and would severly damage the reputation of mozilla.

If any change is to be proposed, it should remember a user's override for 
the named sites that the user overrode, not disable the check for all sites.  
I have not yet read any comment that disagrees that that would suffice.
I am changing the summary of this bug to reflect that.
Summary: Add option to disable Certificate Domain Name Mismatch dialog → Remember overrides of Certificate Domain Name Mismatch
I am not sure that there is exact equivalence between these two bug reports. But
they are close.

What I would like to see is the option to permenantly accept THAT PARTICULAR
CERTIFICATE (not certificates from that site) when the warning is given.
In reply to comment 50, right.  When you choose to override a cert name 
mismatch,  You're not saying you want mozilla to accept any and all certs
for that site.  Neither are ou saying that you want that particular cert
to work for ALL sites everywhere.  You're saying you want that particular
cert to continue to work with that particular site.  

Some ISPs are setup with one certificate for all virtual domains. For whatever
reason, mostly administrative overhead I expect, they do not include every
hosted domain in the valid domains in the certificate.

I see lots of valid comments from developers regarding non-adherence by these
ISPs to various security standards but very little discussion regarding viable
solutions to users suffering the consequences in TB.

Given the ISP is unlikely to change their configuration, what can be done by the
Mozilla developers to lessen the inconvenience for TB users? Given this has gone
nowhere in over 18 months, if the answer is nothing, at least update the
Component to Security and Status to INVALID or WONTFIX for this bug report and
close it with the official position.
*** Bug 292815 has been marked as a duplicate of this bug. ***
Please let me disable this annoying error, nobody is trying to steal my email
and  Im so sick of Thunderbird nagging me about some certificate that I have no
control over. 
I just started using SSL for my IMAP account to test out another bug recently
and I see this problem too. It is awfully annoying.

I'd like to see us be able to remember the CERTOKDomainName list for a
particular certificate across sessions. As Nelson points out, that list is
persisted across the current session. 

One big problem with saving the cert domain list associated with the cert is
that we don't save SSL certificates (nor should we I believe), so there's no
cert in the cert database which we could store the CERTOKDomainName list for.
Scott, in the lifetime of a single TB process, 
are you seeing this warning more than once per server?
(In reply to comment #56)
> Scott, in the lifetime of a single TB process, 
> are you seeing this warning more than once per server?

Hey Nelson, no, that's working just fine, multiple connections to the same
server produce just the single dialog. The 'annoyance' is that every time the
user starts up Thunderbird, he has to dismiss the cert mismatch dialog when we
first log onto the server every time. That's why I was talking about how I would
like the ability to see the cert domain ok list stored in the cert db for a
particular cert. Of course since we don't store SSL certs, there isn't even a
cert to store it with. :(

I was thinking a bit more on this and I suspect it's not realistic for us to
expect/hope for a lot of these web hosting companies to list all of their
domains in the certificate their mail server uses for SSL. Would someone really
list a couple hundred thousand domain names (or more?) in a certificate.
Wouldn't that end up generating a certificate that would have a huge size? I
don't know if I'd even want to see the client NSS code strtok'ing all of the
possible domains from my hosting company just to find my particular domain
anyway. :)

Hmmm.


How about if you created a new table somewhere that listed "equivalent domains"? 
 i.e. what's really going on here is that you're saying that the hosted domain 
is equivalent to the host's domain for auth/cert purposes.  e.g. in my case, my 
domain is interthingy.net hosted at dreamhost.com.  For authentication purposes, 
interthingy.net is equivalent to dreamhost.com and it can permanently be treated 
as such if the user (me) says so.  I guess the tricky part is doing this in a 
secure way (i.e. wouldn't want someone hacking the equivalent domains table to 
trick an eveel domain into being authenticated -- actually, I'm not really sure 
that's possible, but I think it is -- I'm too tired to think of an example right 
now...).

I was able to add dreamhost's cert to the authorities table in cert mgr (not 
sure if that was the right thing to do though) -- is there any way to amend the 
cert in the authorities table to include the additional domain name?

One more thought: IIRC, firefox has implemented this feature.  Maybe you could 
look at what they did?

~ray

Scott,

Creating a single cert with all the options is certainly *not* the only option
available to hosting companies.

The simplest option for hosting companies is to create individual certs for each
domain, and just use a separate IP / port combination for each server. Or if
they can't afford that many IP addresses, they can just use say, 1 IP and cert
for every 10 virtual hosts. 

These companies have plenty of options to fix there issues. The standard
documents are out there. If you are worried about them, point it out to them.
Maybe you can add a link to the standard docs in the error dialog, so these
companies can't hide and pretend they don't know they are breaking the standard.

In any case, we certainly can't expect the ISPs to fix anything if we are going
to ignore this error. This is one that should *not* be ignored, unless you want
to remove security altogether as a feature in mozilla .

Also, my understanding (which may not be correct, please contradict if you have
other info) is that the main protocol that requires multiple IPs for certs
currently is HTTP - and even that is getting fixed with the TLS server name
indication extension (which also fixes it for all other protocols that may be
broken). Many mail protocols use STARTTLS, which means there is an in-the-clear
negotiation which precedes the server's sending of the cert . This negotiation
may allow the server to know which virtual host the client intends to talk to,
and thus would allow the server to pick the right cert, with a single virtual
hostname in it.

Any way you look at it, this is fundamentally a problem of incorrectly setup
servers, not clients. This is a problem that *cannot* be fixed solely by changes
on the client side. If anything, it needs to be an evangelism bug, not a browser
bug !!!
 
Ray,

A cert cannot be "amended" because it is signed by a CA cert. The only way to
change the properties in a cert, such as a hostname, is for a new cert to be
issued to replace it. This is what the hosting companies need to do - obtain a
new cert every time they add a new virtual host, which they aren't currently
doing. Regardless of the evolution of internet protocols and TLS extensions, and
whether the hosting companies choose to use one cert per host or to use a single
cert with multiple hosts in it, these companies will *always* have to obtain a
new cert for each virtual host.

I believe they aren't doing that currently because they are either incompetent
or greedy, in that order.

If Firefox actually implemented the removal of the hostname check, then I'm very
glad I'm still using Seamonkey.
(In reply to comment #57)
> it's not realistic for us to
> expect/hope for a lot of these web hosting companies to list all of their
> domains in the certificate their mail server uses for SSL. Would someone 
> really list a couple hundred thousand domain names (or more?) in a 
> certificate.

No.  My ISP does it this way.  They have one DNS name for their IMAP, POP,
and outgoing SMTP server(s).  They may serve email addresses in thousands of 
domains, but their server has just one name (as seen by their customers).  

Their customers/users login to the server with their full email address 
as the user name.  Their SSL cert has just one DNS name, and it works 
for ALL their users in all those users' many domains, because the server 
is not trying to pretend that it has a DNS name in all those domains.  

The users just have to accept the fact that, although their email domain
may be flintstone.com, they have to connect to a server named
superduperemail.com and login with their full email address for IMAP or 
outgoing SMTP service.

Would you people please listen to what we are saying? Its gotten a bit
ridiculous that someone keeps saying, "This is not a problem with the client,
the problem is with the servers." Yes, the certificate problem is with the
servers -- but this is not a discussion about how to resolve the certificate
problem... this is a discussion about how to get rid of the warning about the
certificate problem. 

We don't want the warning. Its making an existing problem WORSE. 
In a lot of ways I completely understand Arin's frustration.  This traq has been
going for quite some time now.  I mean we're coming up on two years of finger
pointing!  Amazing...truely amazing!  Now for Arin, since you are getting so
frustrated with this, might I suggest using the "hosts" hack to clear your
dialog box for the time being.  Agreed, I don't necessarily like doing it
either, but it does remove the frustration from the equation.

Julien, I completely understand and appreciate your need and desire to maintain
focused on security, however this "It's the ISP's problem", "This is not a bug,
the ISP's are doing it wrong" defense has got to stop!  We've all read it
numurous times and the rhetoric is making our brains bleed.  Yes, technically,
this may be considered an issue with how ISP's maintain certificates, but why
stop there? Why not point the finger at the Cert Authoriies? You mentioned
"greedy ISP's", but the last I checked, the profit margins for hosting providers
are not what they were ten years ago.  It's a cut throat business, and they're a
dime a dozen with heavy competition, low margins and high overhead.  All the
while certain Cert. Authorities are charging upwards of five to seven hundred
dollars for a 128bit "file!"  Now if you want to go on a campaign and span the
globe forcing all ISP's to register one cert. per FQDN then be my
guest...however I would hazard to guess that you probably don't have time for
that in your schedule.  Now lets flip that coin and put yourself in the ISP's
position.  ISP xyz.com hosts, conservatively, 50,000 domains.  Now at the
current pricing structure utilizing a "generic" Cert. Provider you're required
to pay on the order of $100 for a 128bit cert per FQDN.  Now do a little math
and I've got a yearly bill of about 5 million.  Now considering your 50K
customers @ $9.95/mo generate about 6 million.  But wait, don't forget to pay
your employess, say $250K, or your Rent/Lease $100K, and all those computers
$300K, and some bandwith to serve up all those certificates I just paid for,
$150K.  Now let's give Uncle Sam his cut...I think the egg just ate the chicken!

My point being, sure it's easy to point the fingers at the ISP's/Hosting
providers but is it not the system that is broken?  Why don't the Cert
authorities develop a product more tailored for these business? Another
discussion I know, but if you want a cause to rally for change, there's your
focus. Sure ISP's could mitigate these problems solely on how their servers are
configured.  As was previously mentioned, If I have domain abc.org but check
mail through my provider at mail.xyz.com and login w/ bobdobbs@abc.org then the
ISP is within the bounds of the Cert and all is well.  However many ISP's allow
customers to utilize their own mail domain, in my case mail.abc.org which does
indeed break the model, but is needed for advanced services and other products
that they need to differentiate their services.

I don't think anyone here is asking anyone to give up and throw the security out
the window.  All we are asking is that instead of mandating your security views
on the populous, allow us to mandate security as we see fit.  Allow us that
choice.  By keeping things how they are now with popping up a mismatch everytime
I check mail, you are desensitizing me to it's validity.  I become preprogrammed
to hit "check mail," "click OK"..."check mail," "click OK" without so much as a
glance.  On the other hand, i can alter my "hosts" file, but then I loose any
management I may want over the mismatch.

If people don't like the thought of "Accept Once," "Accept for the Session,"
"Accept Always" options for Cert. Management mismtaches, then add the
functionality and leave it off by default, but don't deny us the choice to have
it.  We all take calculated risks every day.  Just allow those of us that are so
inclined to add this one to our list.
For those new to this conversation, note comment 27 and comment 47, which
explain why the requested behavior would actually increase security.  Also note
comment 44, which points out that the requested behavior conforms to RFC 2818.

Julien: I understand what you're saying regarding the ISP's role in this but 
please consider, as many others have said, that it's not that simple.  We can't 
control what our ISPs do and there are valid economic reasons why they can't do 
what you say and why many of us can't provide our own solution.  If you thumb 
your nose at the problem you're only hurting your own users; you're not going to 
change the ISP's behavior no matter how right you may be.

As for "amending" certs: I understand that certs can't be modified; I was 
thinking more along the lines of using something like an attachment to the 
original cert.  I don't know what your DB looks like though, nor if it can 
support this, or support it securely, or be changed easily to support it.  If I 
had more time I'd look into it myself and submit a patch.

Regarding Firefox: I tested it today and confirmed that it wasn't FF that did 
this.  I suspect now that it may have been Evolution but I can't test it right 
now (my employer blocks outgoing POP and IMAP :(

Whichever program it was though, it didn't remove the hostname check, it only 
provided an option to permanently remember a SPECIFIC combination of mismatching 
hostnames so it can suppress the warning in the future.  I think that's all 
anyone is asking for here.

~ray

Just a small remark about authentication:
If I manually check the self signed certificate of my ISP (by matching the
fingerprints) and on success import the certificate into my mail client/browser,
I get an authenticated and encrypted connection with no possibility (except
broken TLS) for a MITM attack. That's exactly the situation I'm in. So at least
in the certificate manager I should be able to override the hostname check for
*specific* domains.
I also suffer from this bug and in my case it is even worse!

I access my mail through an ssh tunnel using the pop3s protocol. *Every* time I
press "Get Mail" I have to OK the "Domain Name mismatch" dialogue. Surely if I'm
allowed as a user to still access my mail after saying it is OK to accept the
domain name mismatch I should also be able to say it's always OK for this
particular mismatch?

I'm forced into this situation because:

1) My employers only use SSL connections i.e. pop3s, and pop3 is not supported
2) They block external access to the pop3s server on all ports other than ssh.
Therefore I need to open an ssh connection to the server, and route the pop3s
995 port through to my localhost with an ssh tunnel. So I get a domain name
mismatch between the server and localhost.
3) I cannot use the /etc/hosts work-around as that will mess with my ssh tunnel
connection and god knows what else!

Do I have any hope or will I be forced to stop using mozilla based mail clients?

I think this is a case of security gone mad. I seem to be trapped between two
differing security mentalities!

(In reply to comment #24)
> In reply to comment 21, 
> Any SSL server that sends out a certificate that does not contain the 
> DNSname(s) by which that server is known is misconfigured, IMO.  
> 
> One of SSL's key values, one that sets it apart from many other crypto 
> protocols, is its ability to detect MITM attacks and protect the user from
> them.  This ability depends on the client being able to determine, 
> algorithmically, that the cert it receives from the server is the cert
> for the server that the client's user intended to contact.  Today, the
> convention (in RFC 2818) is that the client must find the DNSname by which 
> it tried to reach the server in the certificate's list of DNSnames.  
> 

I work at dreamhost.com, though I am not really their representative in this
issue, just expressing personal concerns, observations, and frustrations.

We use self-signed certificates on our shared mail clusters, all of the servers
inside of a cluster, possibly globally, have the same modulus, and the same CN=
field of mail.dreamhost.com. Basically, it is just something to get the
connection scrambled from the casual eavesdropper. I, personally, would love the
option to "ignore warnings regarding this certificate unless something
changes.", much like an SSH client works. If I were "evil.com" forging a
certificate I would make darn sure that the CN= field in a fake self-signed
certificate matched what was on the server.

I'm not up on all of the specifics of how these PKI certs work, but obviously
knowing the public key and its modulus does not put you at risk of forgery.
Couldn't Mozilla check based upon the modulus changing to put up its warning? In
our current situation the certificate file would be huge and ever changing if we
were to put DNSAltName fields in it and reload it for every domain we host. Most
people in our hosting environment want to connect to "mail.example.com", not
mail-cluster-a.hostingcompany.com. The override could even be specific to
self-signed certificates which are already untrusted unless imported.

On another note, if I have two seperate email accounts, Mozilla will not allow
me to connect if I have two domain names, such as mail.example.com and
mail.example.net, that are served the same self-signed certificate. I don't know
if thats an RFC issue or what, but it seems like overkill to block the
connection versus allowing the user to override it.
Could we raise severity and priority of this bug? It doesn't seem to be an
"Enhancement" any more.
One could argue that this is a security issue and susceptible to a pavlovian
vulnerability:
http://robert.accettura.com/archives/2005/10/15/pavlovian-vulnerability/
At least I'm a well trained dog, clicking on those unnecessary warnings without
thinking anymore.
This bug has been open for 683 days, go open source!

The requested behavior is simple - if the certificate name does not match the name of the server one is connecting to, allow the user to choose to "accept this certificate permanently".

This behavior *already exists* in Firefox.  Can anyone give me a good reason why firefox's behavior is acceptable, yet the same behavior would be unacceptable in  Thunderbird?  Several commentors stated that changing Thunderbird's behavior would severely decrease the security of the application.  If that is true, then it would appear that Firefox has a serious security flaw, and I recommend someone notify CERT.

No?  Then the code in Firefox is good enough for Thunderbird.
(In reply to comment #70)
> This bug has been open for 683 days, go open source!
> 
> The requested behavior is simple - if the certificate name does not match the
> name of the server one is connecting to, allow the user to choose to "accept
> this certificate permanently".
> 
> This behavior *already exists* in Firefox.  

The bug is in the certificate name mismatch dialog, not the "untrusted certificate authority" dialog. Firefox does not have a way to permanently make a name mismatch dialog go away. Try visiting https://amazon.com/ , accept the certificate with the name error, then restart FireFox. It will re-present you with the certificate mismatch error.
It's so sad that developers can not understand the simple pov of oridinary user. I'm developer myslef (focused on web) and user experience is the very important thing for me. In case Thunderbird - it is so lame that when i set the option to periodically check my mail for every 10 minutes and i have host with lame certificate - the message with warning will appear every time without even the possibility to _remember my choice to accept my choice for this particular Thunderbird session_. It is very annoying and should be changed by Thunderbird developers. Of course it can be cause for endless discussion but imvho this bug makes my life much harder. Plase change this.
(In reply to comment #45)

A long way back on this discussion, I think comment #45 is THE solution. I didn't find any comment on this, but maybe I missed it in the middle of all the other stuff.

Maybe this could be done as an extension, that way people could choose which way they want it - more security or less annoyance.

Let me just mention (I'm not sure anyone's done it before) that I get this issue not when starting TB and checking for mail, but rather when SENDING mail. This is because my ISP only allows Authenticated SMTP (SMTPA) and I have a proxy computer between me and the ISP (which causes the name mismatch).

So, I would defend the option of following the solution (brilliantly) proposed by Tom Metro on comment #45, but making sure it's available for the SMTP server as well. The solution could be implemented as regular UI, as an Extension, or even as a tweak (about:config or something).
I have not yet read this bug in total, it is very long.

But this bug is not specific to Thunderbird, it applies to Firefox and Seamonkey, too.

A cross-application solution should be found.
I propose the product of this bug be changed to Core / Security PSM.

Please also note bug 94904 and bug 99411.
I contains related suggestions (which I have not yet reviewed either).

Could we avoid storing certificates for fixing this problem?

Could we just store a hostname-in-cert to hostname-connecting-to string pair?

We could say, whenever we see a valid certificate issued to hostname-in-cert and we are trying to the associated hostname-connecting-to, we could skip the warning.

However, there is obviously a certain danger with implementing this feature. The user could make the "remember" decision too quickly, without having looked at the displayed test in detail.

Therefore I propose, this "remember mismatch permanently" feature should be implemented together with bug 276533, see bug 276533 comment 5. Instead of displaying a secure lock icon (when talking about browser windows) we should extend the lock icon by a visual feedback visualizing "the site is authenticated, but partly because of your own decision to trust".

Without re-opening the whole debate about what's right and what's wrong from a security point of view...

A volunteer could easily write an extension that would supress this error dialog. For those of us foolish enough to want to ignore this dialog, we could go out and install the extension. No modifications to the mozilla source would be required and you wouldn't have to wait for a more complicated discussion / implementation that happend in the mozilla source.

An extension author can write a small extension which implements nsIBadCertListener  like we did for software update: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1588

But this implementation would wrap the default implementation, forwarding all calls to the real listener except for confirmMismatchDomain which should return false. 

"Foolish to want to ignore this dialog" seems to be a bit exagerrated, in context of comment #1, which started it all.

Anyway:

1) Would such an extension be capable of killing the dialog on per domain basis? And only if some other conditions are met? For example when certificate is issued by someone else, however that "someone else" is strictly defined to be "someone" yet not "anyone" else? Generally we don't want this dialog to be destroyed everytime.

2) Extension has a small downside: it might be installed without user knowing it - or am I completely wrong with this?

Hi people,

I am a nobody here. I am just a regular Firefox/TB user. However, this bug is just so annoying that I am forced to switch back to IE/Outlook. Hope some day this bug will be gone because I love FF/TB, but I really can't deal with seeing this annoying pop up every time.
I think dennison's comment above shows the real problem here.

Under some circumstances, the mismatch dialog will pop up *every time* Thunderbird checks for new email.

This happened to me when I first started using Thunderbird and prompted me to start following this thread.  Since then, Thunderbird hasn't exhibited the same behavior (even on different machines accessing the same mail server with the mismatched cert.)

I think most people would be content if the mismatch dialog occured once and only once for each instance of Thunderbird, instead of for each time Thunderbird checks for mail.  Unfortuantely, I can no longer duplicate the problem of Thunderbird notifying me of the mismatch every time it checks for mail, even though I'm using the same mail server I was when I experienced that problem, so I am unable to provide any details that would help identify the situations under which this problem occurs.
(In reply to comment #78)
> Hi people,
> 
> I am a nobody here. I am just a regular Firefox/TB user. However, this bug is
> just so annoying that I am forced to switch back to IE/Outlook. Hope some day
> this bug will be gone because I love FF/TB, but I really can't deal with seeing
> this annoying pop up every time.
> 


(In reply to comment #78)
> Hi people,
> 
> I am a nobody here. I am just a regular Firefox/TB user. However, this bug is
> just so annoying that I am forced to switch back to IE/Outlook. Hope some day
> this bug will be gone because I love FF/TB, but I really can't deal with seeing
> this annoying pop up every time.
> 
=====================================================================
(oops)-sorry for the blank. New user.
====================================================
TEMPORARY FIX

Desperate for a quick fix? 
Just a quick note which may be of use to anyone with a comment such as the one above. Someone has created an extension which re-installs the checkbox to remember this preference. The post can be found here:

http://forums.mozillazine.org/viewtopic.php?t=370852&highlight=

Thanks all for creating the state-of-the-art in browsing and email.
*** Bug 324923 has been marked as a duplicate of this bug. ***
(In reply to comment #81)
> http://forums.mozillazine.org/viewtopic.php?t=370852&highlight=

What about a temporary fix for seamonkey?

Can we have a vote for cloture to resolve this bug?  And similarly for the related circumstance, an expired certificate, which also does happen in the real world with dismaying regularity.
(In reply to comment #84)
> Can we have a vote for cloture to resolve this bug?

While the extension works great for me, I grow tired of managing all these extensions and I believe some functionality that is currently provided by extensions should built-in.  This is definitely a perfect example of that.

I would therefore vote to leave the bug open to encourage this functionality to built-in.

I agree. IMHO security issues should not be handled by extensions as long as it is possible to built the feature into the main app.
(In reply to comment #86)
> I agree. IMHO security issues should not be handled by extensions as long as
> it is possible to built the feature into the main app.

Right.  When a user regularly accesses a mail server with a domain mismatch problem, repeatedly showing the dialog reduces the security of Thunderbird, while suppressing the dialog increases security.  Making users in this situation install an extension to get more security seems too high a hurdle.

Not to mention that the extension doesn't actually implement nsIBadCertListener, as comment 76 indicates would be the correct solution to the bug.  Instead, it merely "clicks" the OK button in the dialog.  It's a workaround, not a solution.

> Can we have a vote for cloture to resolve this bug?

There is absolutely no reason to close it IMHO. Extensions are for extra functionality, not bug workarounds.

(In reply to comment #87)
> (In reply to comment #86)
> > I agree. IMHO security issues should not be handled by extensions as long as
> > it is possible to built the feature into the main app.
> 
> Right.  When a user regularly accesses a mail server with a domain mismatch
> problem, repeatedly showing the dialog reduces the security of Thunderbird,
> while suppressing the dialog increases security.  Making users in this
> situation install an extension to get more security seems too high a hurdle.
> 
> Not to mention that the extension doesn't actually implement
> nsIBadCertListener, as comment 76 indicates would be the correct solution to
> the bug.  Instead, it merely "clicks" the OK button in the dialog.  It's a
> workaround, not a solution.

I'd be interested in a patch that implements comment 76. I exchanged some e-mails with a couple extension writers who were going to collaborate on a solution using this technique, but I haven't heard back from them in a while.
 


Comment 76 appears to propose to ignore all cert name mismatch dialogs.
Is that really what you're proposing?

Do you understand the implication of such a proposal on, say, auto update
security?  See bug 340198.
(In reply to comment #90)
> Comment 76 appears to propose to ignore all cert name mismatch dialogs.
> Is that really what you're proposing?
> 
> Do you understand the implication of such a proposal on, say, auto update
> security?  See bug 340198.
> 

I was envisioning the extension checking against the list of domains the user wants to ignore the mismatch dialog for in confirmMismatchDomain, forwarding the rest of the errors on to Thunderbird's implementation.
Are there really any domains for which the user wants to ignore ALL name 
mismatch errors?  
These would be domains for which the user doesn't care if he gets MITM 
attacked or not.  

I think what these users want is the ability to remember *a specific cert*
as being acceptable for *a specific host name* not listed in it.  
That's not vulnerable to MITM attacks using other, previously unseen, certs.
> I think what these users want is the ability to remember *a specific cert*
> as being acceptable for *a specific host name* not listed in it.  
> That's not vulnerable to MITM attacks using other, previously unseen, certs.

Right.  I think what we want here is to offer users the ability to turn off cert name mismatch dialogs only for connections to configured email servers and only for specific host/cert combinations.

For other kinds of connections (automatic updates, remote content like images in HTML mail, etc.) we should continue to do what we're currently doing when we get a mismatch (i.e. cancel the load or prompt the user).

Re: comment #88, this isn't a bug - witness the severity : "enhancement" .

Re: commment #75, you may not need to store the entire certificate to implement this RFE. You could just store 2 hashes (done with 2 different algorithms; or more if you are really paranoid) of the certificate, along with the hostname for which you want the cert to always be good for.

(In reply to comment #1)
> this is especially annoying when you have thunderbird set up to check mail
> every minute -- it presents the dialog each time.

Can anyone confirm that?  
If true, that is a separate problem.  That would be a bug, pure and simple, 
in the way the email client is using SSL.  
This bug is about host name mismatch overrides not being remembered after
restarting the client process (browser or email).  
If the email client doesn't even remember the mismatch override within the
same process lifetime, then the email client is not giving libSSL the info
needed to cache the session, or to find it in the cache.
A separate bug should be filed for that, if confirmed.


(In reply to comment #95)
> (In reply to comment #1)
> > this is especially annoying when you have thunderbird set up to check mail
> > every minute -- it presents the dialog each time.
> 
> Can anyone confirm that?  
 
> If the email client doesn't even remember the mismatch override within the
> same process lifetime, then the email client is not giving libSSL the info
> needed to cache the session, or to find it in the cache.
> A separate bug should be filed for that, if confirmed.
> 

The logic behind it is that the IMAP/POP/SMTP connection is often completely new. New connection, new SSL transaction, etc. I know our system has a load balancer in the way, and after so long of idle time the connection is simply flushed, so the SSL state information is long gone. 

For active live connections that persist the dialog is not presented again.

If there are no security implications I don't see what the issue is. I've been over that in previous comments though.
> ... after so long of idle time the connection is simply
> flushed, so the SSL state information is long gone. 
> 
> For active live connections that persist the dialog is not presented again.

Just a thought: given this, might it be possible for folks who get the dialog on every mail check to avoid it by increasing the frequency of their mail checks?  (i.e. to avoid the cache timeout?)
Kelly Kane,
The duration of an SSL session is not tied to the duration of any TCP 
connection nor any group of TCP connections.  

An SSL session between a client and a server typically lasts until 24 hours 
have elapsed, or until the client process ends, whichever occurs sooner.

An SSL session may be used by multiple TCP connections between the same 
client and server,  whether those connections overlap (e.g. are simultaneous)
or are purely sequential (one after another) with no overlap.  The re-use of
SSL sessions avoids the costly RSA, RSA< or ECC computations, AND it avoids
all the cert validation logic, by reusing the previously validated and 
negotiated session secrets.  

It never hurts to try to use an old session.  If the other end no longer 
honors that session, it just starts a new one anyway.  There are no extra
connections, nor round trips, nor other bad side effects of attempting to 
restart an old connection, and there is significant benefit to doing so 
when an old session is succesfully reused.  

At this point, I wonder how much of the perceived problem is due to the 
cert mismatch info not being preserved over multiple sequential process
lifetimes, and how much of it is due to failure to re-use SSL sessions
that already live in the local process's session cache.  The former 
requires significant new development.  The latter would simply be a misuse 
of th existing NSS API, and proably trivial to fix.

The "issue" with failing to re-use the SSL sessions is huge user inconvenience
and bad user experience.  Indeed, this is the same issue with failing to 
preserve cert name mismatch issue across process lifetimes, but presumably
the frequency of one problem is much greater (and hence perceived more severe) 
than the other.

Is there another bug about the lack of SSL session reuse in a single process
lifetime?  I really don't want to further lengthen this bug about that topic.
(In reply to comment #95)
> > this is especially annoying when you have thunderbird set up to check mail
> > every minute -- it presents the dialog each time.
> 
> Can anyone confirm that?  

Well, unless I have misconfigured Tb 1.5.0.5, yes I have this problem with 2 mail servers. Every 20 minutes or so (the time between two successive checks for new emails), I have to click "OK" twice (once per server). Did someone say "annoying"? ;)
Fred (?) Buclin,  Do these server certs have valid DNS names in them?
Can you access those servers by the names in the certs?
If so, What happens if you reconfigure your mail accounts to fetch 
the mail from the servers with the names in the certs?  
I'll get the mismatches simply disappear. 
Others have reported success with this method.

Better to light a candle than curse the darkness.
(In reply to comment #100)
> Better to light a candle than curse the darkness.

Hum, yeah, this works. Shame on me for not trying this earlier. :-/ Thanks Nelson.
As mentioned before by Nelson Bolyard, any issue having to do with a domain mismatch dialog being shown multiple times during a single Thunderbird session is NOT the issue described in this enhancement request.  This issue deals with a common situation under shared hosts where Hostname A must be specified on the client side, but a certificate for Hostname B is always presented on the server side.
I'm the author of the Remember Mismatched Domains extension. I'd really like to update RMD to implement Scott's <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=228684#c76">'Comment 76'</a> suggestion but am not sure it's possible. I'm able to successfully provide a custom notificationCallbacks for the MessageBrowser ("messagepane") however it seems other components also trigger the Mismatch dialog... If anyone has suggestions on how I can get this going for those as well I'd be very happy to implement a more 'proper' solution. As it stands I'm running out of ideas (as resorting to soliciting assistance in bugzilla might indicate).
*** Bug 362737 has been marked as a duplicate of this bug. ***
Assignee: mscott → kengert
Component: Preferences → Security: PSM
Product: Thunderbird → Core
QA Contact: psm
How can disable this message without the workaround with an extension? Can I delete the certificate or where is this informations stored in TB?
I have been frustrated by the constantly popping-up dialog boxes as well.

The extension does elegantly solve the problem:

https://addons.mozilla.org/en-US/thunderbird/addon/2131

I would love to see this standardized in the client as well, perhaps under the Edit/Preferences/Advanced/Encryption tab.

I understand the security arguments against making this extension a standard feature, but consider this:

1) User frustration over constantly popping-up dialog boxes shifts user preference away from Thunderbird and toward other email clients like Outlook, with the resulting security problems.

2) User frustration over constantly popping-up dialog boxes causes users to quickly click the "OK" button, ignoring the text.  What if it had been a real security breach, featuring a MITM redirection attack to a new domain or IP address that the user hadn't seen before?

The design of the extension, remembering pairs of domains/IP addresses and only those pairs that have been pre-authorized by the user, is exactly the correct approach.  If a real MITM attack should occur, the user will be presented with the correct dialog box again.

3) Many users are powerless to change the SSL certificates of the email sites they use.

The SBC Yahoo example above is a good example.  Even a huge web corporation like Yahoo can't get it right when switching from SBC to AT&T.  Without the extension, all users of SBC Yahoo email will be presented with endless dialog boxes.  That's a lot of frustrated users!

4) Many low-cost web hosting providers only use a single certificate to cover all of their domains.

Due to the high cost of getting an official certificate that is signed by the recognized authorities, many small providers only do this once, and then let all of their customers share a common certificate.  Of course, the domains won't match.  The users need this extension, to get around the annoying dialog boxes.

This approach is still about as secure as it's going to get, since if an attacker breaks into the web server containing many virtual hosts, they can grab all of the data anyway, and it wouldn't make a difference whether the virtual domains each use an individual SSL certificate or share a common certificate between them.

5) Expired certificates are just as annoying as mismatched certificates.

The design of this extension, remembering pairs, works elegantly well to solve this problem as well.  Instead of containing two domain/IP address pairs, the pair here consists of the certificate domain and the expiration time.  The user is given the choice to remember this pair, and not have to answer any more dialog boxes until the expiration time changes again.  The user is still protected against a substitution attack, because a real dialog box will be displayed if an attacker unexpectedly substitutes an old, expired, possibly-cracked certificate that the user hasn't accepted before.

So, these 5 reasons are my votes for getting this extension's features built directly into the Thunderbird client.  It's not something that should be marked as INVALID due to a perceived security problem, on the contrary, it helps security by easing the constant nagging that tricks users into blowing past dialog boxes and not reading them.  It saves the nagging for a real security breach, when it is much more important to nag the user!

Thank you Josh for composing that. It is always frustrating to me when programmers will not listen to their users. Not having this feature does indeed make it less secure rather than more secure. The typical user will click the accept button without reading it when they are confronted with endless warnings.
Will this be fixed as part of bug 327181, or will Thunderbird need its own changes?
Whiteboard: [sg:want P3]
(In reply to comment #112)
> It is always frustrating to me when programmers will not listen to their users.

Um, in case you haven't noticed, there are only two full-time developers working on mail&news.
(In reply to comment #114)

> Um, in case you haven't noticed, there are only two full-time developers
> working on mail&news.

Of course he didn't notice.  How could he?  How would he, or anyone, know which developers are working on what?  I certainly have no idea, and I don't know where that information is.  Perhaps you could enlighten us?
Please, let's not get into that kind of discussion.
Bugzilla is not meant as a forum, it's meant for bugs and on how to fix them.
If you really think this should be fixed, I guess you could set the blocking1.9? flag.
Flags: blocking1.9?
(In reply to comment #113)
> Will this be fixed as part of bug 327181, or will Thunderbird need its own
> changes?

Thunderbird will not need its own changes, the code in bug 327181 and bug 387480 is planned to work with any application and protocol. A backend enhancement to cert fetching in bug 327181 will be required, because xmlhttprequest by default blocks connections to mail protocols. The new interface/service would have to get accepted for shared ff3/tb3 branch. Hopefully I can get it done soon enough. That new service would have to do a ssl connection to the server, obtain the cert even though the certificate is bad, close the connection without bringing up any error messasges, and make the cert status available for the UI in bug 387480.

If you want to get this done asap, feel free to contribute programmer resources to get this done. I'm willing to provide guidance if someone steps up.

I don't think this qualifies as a blocking bug anymore, due to there being a valid workaround (extension).  The argument about security for the common user isn't very strong for making it a blocking bug, because I'm sure this wouldn't be the default option.  I don't think the common user is going to realize that they can go into some advanced security option to disable this, they will probably just keep hitting OK.

Thus, the users who understand this issue and want to fix it already have an option of fixing it by downloading the extension.  That is not significantly harder than enabling an advanced option.

Don't get me wrong, I'd love to see this feature/bug added.  However, I also realize now that there is a good workaround for it, and that if there was an advanced option, it wouldn't really be much different from the extension that already exists.

I'd rather have programmers working on bugs that have no easy workaround.
Flags: blocking1.9?
I agree to Stevens last paragraph, but I see no reason not to include the extension as default. This way every user will get the close at hand option to add the specific pair as trusted.

I would like to comapre this to the fature with allowing popups for a certain site. Of the functionality of the NoScript extension.

Making the extension a natural part of the software would just follow the natural behaviour of FX.
(In reply to comment #118)
> I don't think this qualifies as a blocking bug anymore, due to there being a
> valid workaround (extension).

As stated previously, extensions are for adding features, not for fixing bugs.
(In reply to comment #120)
> As stated previously, extensions are for adding features, not for fixing bugs.

Whether or not the lack of some particular feature qualifies as a bug is not always clear-cut; in addition, since the present report is of "enhancement" severity, it is not about fixing what people usually call a bug, but rather about adding a feature. However, this is not the right place to discuss it: you might find more sympathetic listeners in some of the newsgroups on the news.mozilla.org server.
Can this bug be closed now? Should it be morphed into a Thunderbird-specific bug about adding the UI to fetch certs as part of account creation (or do we have that one already?)?
I agree this bug should be fixed as part of bug 387480, or better, I'd like to mark it as a duplicate of bug 387480.

The workaround for mail server is:
- connect first
- then go to servers tab and add exception (see bug 399043)

The security engine will not offer an immediate click-through that we had in the past.

We have implemented a multi-step-assistance for adding exceptions, which comes with warnings and requires consideration, as part of bug 398718 and bug 401575.


What's left for mail, what could be done to improve the user experience for mail servers with bad certs?

Because mail accounts are configured, that configuration UI seems to be the right place to add a hint/link/button to the add exception mechanism. If you want to do that, I propose to file a separate bug against the mail UI.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.