Closed Bug 456590 Opened 16 years ago Closed 6 years ago

Yahoo and AT&T SMTP SSL change fails with Thunderbird

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jm-mitre, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [psm-auth])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: 2.0.0.16 (20080708) (also 2.0.0.9 and 3.0.1) Last week AT&T (or Yahoo!) rolled out a change to their mail servers. Now Thunderbird users using this ISP can't send mail. There is also a necessary song and dance before Thunderbird users can receive mail. There are several symptoms. Sending mail: Thunderbird error, Send Message Error: Sending of message failed. The message could not be sent because connecting to SMTP server smtp.att.yahoo.com failed. The server may be ... Please verify ... or contact your network adminsitrator. AT&T (or branded Yahoo!) support management is well aware of this problem. Their position is that there is a design flaw in Thunderbird. Support staff freely agrees that Thunderbird did work for months with their servers. They agree that it was a recent change to their servers that resulted in this problem. By being nice, you can get them to agree that it was their change that led to the "design flaw," which led to the problem. There is no doubt that my settings [i][b]are[/b][/i] correct. Others with the same setting have the same problem. Reproducible: Always Steps to Reproduce: 1. Configure correctly for AT&T+Yahoo! SSL SMTP connections 2. Compose mail 3. Click Send Actual Results: Thunderbird error, Send Message Error: Sending of message failed. The message could not be sent because connecting to SMTP server smtp.att.yahoo.com failed. The server may be ... Please verify ... or contact your network adminsitrator. Expected Results: Connection made; message sent. I wrote the summary as "Yahoo and AT&T SSL change fails with Thunderbird," because I don't have enough information to be sure where the problem is. This is the way AT&T+Yahoo! support management would have titled the thread: Yahoo and AT&T SSL change uncovers design flaw in Thunderbird. .... Last spring AT&T (and, maybe, all Yahoo! e-mail) switched to using an SSL session to transmit and to pick up mail. That required a change to the Thunderbird account settings. Easily made and no problem. Last week AT&T (or Yahoo!) rolled out a change to their mail servers. Now Thunderbird users using this ISP can't send mail. There is also a necessary song and dance before Thunderbird users can receive mail. There are several symptoms. Picking up mail: 1. An occassional Thunderbird request, User Identification Request: The site has requested that you identify yourself with a certificate: pop.att.yahoo.com; Org: Yahoo! Inc.; Issued Under Equifax This can be dismissed, or a certificate can be supplied. (I provide the certificate, which I must have installed in Thunderbird, because I must read encrypted mail sent to me using my public key.) 2. Subsequent Thunderbird alert, Alert: Error establishing an encrypted connection to pop,att,yahoo.com. Error Code: -12195. This can be dismissed with OK. Clicking the Get Mail icon again then successfully checks for mail and downloads any mail. Sending mail: 3. When clicking Send icon on any message, sometimes the request of symptom 1 above. This may be due to automatic checking for mail, and not related to the clicking of Send. 4. Thunderbird error, Send Message Error: Sending of message failed. The message could not be sent because connecting to SMTP server smtp.att.yahoo.com failed. The server may be ... Please verify ... or contact your network adminsitrator. This can be dismissed with OK. But the message is n o t sent. ....... AT&T (or branded Yahoo!) support management is well aware of this problem. Their position is that there is a design flaw in Thunderbird. Support staff freely agrees that Thunderbird did work for months with their servers. They agree that it was a recent change to their servers that resulted in this problem. By being nice, you can get them to agree that it was their change that led to the "design flaw," which led to the problem. There is no doubt that my settings [i][b]are[/b][/i] correct. Others with the same settings have the same problem. Both XP and Vista. Both Thunderbird 2.0 and 3.0. Posted as two bugs, one for POP and one for SMTP. Probably related to 381287, which was recently assigned. Possibly related 447960, 437683, Cordially, Joaquin
Please let me know if I can help by gathering more info. Please give specific instructions. I'm a software architect, so kinda ignorant.
I get a similar alert, asking for my cert, and I also get prompted for my master password. Cancelling out allows the send to succeed. Oddly, my cert has expired. Nelson, is there logging I can do to figure out what's going on at the ssl level?
Posted at Bug 456593 for POP certificate problem.
Random thought: People using encrypted mail often have self-issued certificates or el cheapo certificates such as low class Verisign certificates. The certificate chains that these have may not inspire confidence at AT&T+Yahoo!.
Several thoughts. 1. I know what they changed in their server. 2. There are other bugs that describe this same problem, and this bug is basically a duplicate of (at least) one of them. 3. See bug 313012 for a lot of history about this issue, especially comments 15, 26, 33, 36 & 37. SSL always identifies the server to the client with a server certificate. The server can also optionally ask the client to identify the client's user to the server with a client certificate. When that happens, the user typically gets the dialog described in comment 0. Yahoo's email servers have apparently begun to request that your email client identify you with a certificate. If it doesn't recognize the cert you send it, it will terminate the connection. That's what you're seeing. Note that, if you had a certificate for this purpose, it would typically NOT be the same cert as you would use for encrypted S/MIME email, but email certs CAN be used for this purpose, so Thunderbird will include any email certs you have in the list of certs when it asks you to pick one. If none of your certs are for client identification and authentication, then you should click cancel. Today, the email protocols (POP, IMAP, SMTP) all give the user a choice about what to do when the server asks the client to identify itself with a client certificate. The two choices offered are: - pick one automatically, or - ask the user to pick one EVERY TIME. This is chosen by one global preference named security.default_personal_cert which applies to all protocols. The default was recently changed to "ask every time". Users whose certs are not accepted by the server MUST presently use the "ask every time" setting so that they can choose to send NONE. Otherwise, some wrong cert will be automatically sent every time. For a long time now, I have been suggesting that each mail/news account should have its own separate configuration for this, and there should be 4 choices including the ones shown in the suggested configuration pane below. Implementing this will probably require changes to both the mail protocols and to PSM. Suggested preference panel for configuring email identity client auth: > Every time that this server asks me to identify myself with a certificate: > ( ) automatically pick one of my certificates to send > (o) ask me to pick one > ( ) always send my certificate that I have chosen below > ( ) do not send any certificate That last choice in particular would solve the problem for most people. Please, email Gods, can we get that into TB 2?
I meant "TB, the next generation" (whatever is coming from the trunk).
Thx very much, Nelson. Cc'ing Bryan for his UI input. I believe there's a patch out there for associating certs with identities, but that may be for signing/encrypting e-mail, I'm not sure. What changes would we need to make to our protocol code and PSM to support this? Would we add this to the security page of the account settings? That page is already pretty full. And we only really care about this if the user has pick SSL/TLS.
Do all these users now need a client certificate? This makes me wonder about someone's suggestion to generate these when accounts are created / certificates are required from the server. Most people are not going to understand at all what a user certificate is. I think we'll need an optimized route that creates one and sends it to the server asking the user once; at most. If a person has a certificate already setup we'll definitely need to prompt them for which one to use. Initial use of thunderbird after creating a first account will be a tricky situation to handle. Can this user cert be required for downloading mail as well as sending?
My understanding from what Nelson said is that most users can pick "None" as the cert to use, and everything will be OK (I haven't tried that yet, and it's a bit counter-intuitive). I don't believe we can just create a certificate on the fly. Yes, this applies to POP3 and IMAP, as well as SMTP.
It may be the case that Yahoo is beginning to allow some of its users to authenticate themselves with certificates from a particular CA, and has merely misconfigured their server so that, instead of sending out the name of the CA whose certs they honor, they are sending out an empty CA name list, which means "Any CA". Or, it may be that they do not intend to use client authentication at all, and have erroneously enabled client authentication in their server. I'd put my money on that bet. Either way, it's a server configuration error. It really makes no sense to accept certs from ANY CA, because users can be their own CAs with programs like OpenSSL. It only makes sense to trust some (one, or a few) CAs, and accept certs from them only. When the server is configured to do that, it is supposed to send out a list of the names of the CAs whose certs it will accept. But the Yahoo server is sending out an empty list. Most users have no certs of their own, so they will not be asked to pick one of their certs. The few that do will be asked. IF the server was sending out the proper CA name list, then only those users with certs from the selected CA(s) would be asked, and users whose cert(s) come only from CAs not in that list will not be asked.
(In reply to comment #7) > What changes would we need to make to our protocol code and PSM to support > this? Kai Engert (Mr. PSM) can best answer that question. It may be that no PSM changes are required. I don't know. Your protocol code would need some interface to PSM by which it can tell PSM what cert to use for the account. That might be a call-back interface from PSM to your code. Your code needs to store the info I described in the prefs for the account. > Would we add this to the security page of the account settings? That page is > already pretty full. And we only really care about this if the user has pick > SSL/TLS. Maybe you need a new separate security certificates page/tab. Wherever you put that config info, You will want accounts to be separately configurable for certs to: a) sign outgoing emails b) use for receiving encrypted emails, and c) use for SSL client authentication. It's probably best for all those choices to be made on a single page/tab, so that the user sees all 3 choices at once, and is less confused about what goes where.
Thanks, Nelson. Your workaround works around the AT&T+Yahoo! server configuration problem. I used Config Editor to set security.default_personal_cert to 'Ask Every Time'. Whenever the User Identification Request dialog box pops up, I click Cancel. In the long run, all of us will either convince AT&T to reconfigure or switch to Comcast. And thanks to all. Cordially, Joaquin
> My understanding from what Nelson said is that most users can pick "None" as > the cert to use, and everything will be OK (I haven't tried that yet, and it's > a bit counter-intuitive). So it seems that when a person adds their own client cert we should be asking if they want to use it for all accounts or specific accounts. And possibly upon receiving a request from a server ask the person some cert details. For servers that accept "None" as a response it sounds like we want to ignore this request when a user doesn't have certs defined. Otherwise we'll just be prompting people with garble text, "Do you want to frobnicate your widgets?". Or we'll be blocking people from using TB, like the comment 0 explains. > > Would we add this to the security page of the account settings? That page is > > already pretty full. And we only really care about this if the user has pick > > SSL/TLS. > > Maybe you need a new separate security certificates page/tab. Wherever you > put that config info, You will want accounts to be separately configurable > for certs to: > a) sign outgoing emails > b) use for receiving encrypted emails, and > c) use for SSL client authentication. > > It's probably best for all those choices to be made on a single page/tab, > so that the user sees all 3 choices at once, and is less confused about > what goes where. Seems like that's the best place for it to go, despite being a thorny mess already.
In my case, I have an expired cert - the UI asks me to pick it as the cert to send, and then, I assume, the server rejects it. And I can't get rid of the expired cert because I didn't have a master password because of some other unpleasantness, and that makes it impossible to do lots of things, apparently.
(In reply to comment #13) > So it seems that when a person adds their own client cert we should be asking > if they want to use it for all accounts or specific accounts. It is extremely unlikely that two servers will ever accept the same cert for client authentication purposes, and even more unlikely that ALL servers would accept the same cert. Remember than if you send the wrong cert to a server, your connection gets terminated. So, "use for all accounts" is not really a good choice for client authentication certs. > And possibly upon receiving a request from a server ask the person some > cert details. ? What do you have in mind? > For servers that accept "None" as a response it sounds like we want to ignore > this request when a user doesn't have certs defined. Otherwise we'll just be > prompting people with garble text, "Do you want to frobnicate your widgets?". > Or we'll be blocking people from using TB, like the comment 0 explains. You never get to this dialog unless a) the server has requested client auth, AND b) You have one or more certs that were issued by one of the CAs named by the server, and that can be used for client auth. (noting that if the server's list of CA names is empty, then all CAs are acceptable.) A user who has no certs, or whose only certs are not from a CA named by the server, will not see this dialog. IOW, the dialog will not appear when the list of certs from which the user would select will be empty.
(In reply to comment #14) > In my case, I have an expired cert - the UI asks me to pick it as the cert to > send, and then, I assume, the server rejects it. That's a decision made by Mozilla people, not by NSS people. A cert that has expired is not valid *by definition*. But some users who manage their own servers wanted their own self-issued client certs to be valid forever, even after they expired. They complained that they were not give the change to select expired certs, and someone caved in and gave them that choice. Imgaine explaining to your mother why expired certs are in her list. :(
Depends on: 437683
I suggest that people who want a real fix to this go and vote for bug 437683 which was just denied for TB3.
Nelson: I didn't _deny_ it for TB3, I denied it blocking-tb3 status, which is very different. I do want it for Tb3. Also, voting on bugs is not worth it -- explaining to me the relationship between the two bugs (which I figured out after that flag setting) is a much better way to get the bug the attention it deserves.
This hot bug and its twin bug 456593 are still unconfirmed in bugzilla. I cannot verify this problem myself since I don't have an account on yahoo or AT&T, but it looks verified to me. Can someone please verify this bug and update the status and platform?
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Until we get fix for bug 437683 in a future release, is it possible to at least initially just to add the new option (3) "send no cert" (ever) (even if I have some defined) to the existing security.default_personal_cert property (globally) and get it in the next v2 patch? It's a real pain for Yahoo users to have to click cancel all the time now...
Shredded behavior is the same. Shredder 3.0b1pre thunderbird-3.0b1pre.en-US.win32.installer.exe 27-Sep-2008 04:28 7.8M Downloaded 27 Sep 8 2:10 PM PDT Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080927031346 Shredder/3.0b1pre security.default_personal_cert : Ask Every Time Details at Bug 456593
I have a similar problem and I also have a third party certificate. I have changed security.default_personal_cert : Ask Every Time as outlined in Comment #12 From Joaquin Miller 2008-09-24 15:50:17 PST. That worked once, anyway. Why is everybody busy pointing fingers instead of trying to fix the problem? Dave
I have This problem and am glad that I am not alone. Now can one of you come up with a simple work around that us unknowing can use to get our mail sent? Make it simple so that we non programmers can use it. Other wise is there another company that has a similar DSL offer to AT&T that is inexpensive and works that we can move to until AT&T gets theirs fixed or some quits poking holes in the sky with their finger and fixes Thunderbird
Stanley: This is a problem with Yahoo! and AT&T: "Yahoo and AT&T SMTP SSL change fails with Thunderbird." Thunderbird behaves correctly, so it is not a question of fixing Thunderbird. However... 1) Workaround The simple workaround is: Whenever Thunderbird displays the User Identification Request window Check Remember this decision (if not already checked). Click Cancel. You will have to do this twice, since both the AT&T POP servers and the AT&T SMTP servers are misconfigured. And you will have to do it each time you start Thunderbird. You may also have to do it more than once if you keep Thunderbird is open for a long time, as the mail servers may challenge you again. Resist the temptation to click OK. If you do click OK, you must close all Thunderbird windows and restart Thunderbird. If you do not see this window pop up, you need to change your configuration item, security.default_personal_cert, to: ask every time. 2) Changes that should be made to improve Thunderbird user experience >>>>>>>> Fellahs and Gals: Only one change to Thunderbird is required: either a) add an option to the configuration item security.default_personal_cert: do not send any certificate or: b) add None to the dropdown in the User Identification Request window. (I have encryption certificates and None is not offered) See Comments 5 and 10, where the problem at AT&T+Yahoo!is explained. >>>>>>> I hope someone will own making this small change to Thunderbird. (Lots of us have been living with this for a third of a year now.) (Additional--and better--suggestions are made at Comment 5, too. It will be excellent when those are also implemented.) Cordially, Joaquin
Oops. Sorry. I think my second suggestion: or: b) add None to the dropdown in the User Identification Request window. is dumb. Cordially, Joaquin
Depends on: betterclientauth
Question: Why is this bug marked Depends on: 437683? Please see comments #48 and 49 of 437683. This bug, 45659o, can be resolved with a config change, adding an option to an existing config item: set security.default_personal_cert to Send no certificate (not a per account configuration) This bug is not assigned, will someone take it? Thanks everyone. Please forgive my ignorance of how Depends on: is used.
Are there any updates on this issue? Thunderbird 3.0 is approaching and I cannot see any improvement on this side. I either have to not use any certificate or always hit cancel if not willing to authenticate ssl with my own certificate. This is indeed annoying, especially given that along with "select automatically" and "ask every time" developers could easily add "never use certificates" into options (even hidden into the about:config would still be really appreciated!)
Whiteboard: [psm-clientauth]
Whiteboard: [psm-clientauth] → [psm-auth]
Today Wayne Mery asked whether I am still seeing this bug. Short answer: No. Long answer: See: Comment 12 Joaquin Miller 2008-09-24 15:50:17 PDT Then sometime later, too far in the past for me to remember when, but certainly years ago, my problem with AT&T Yahoo! went away. I regret that I can not tell you whether this was due to a new version of Thunderbird or due to a change at Yahoo!. I expect many mail readers had the same problem, so maybe Yahoo! or AT&T decided to back out this change. Please let me know if Nelson's suggested change to Thunderbird has been implemented. The security (and reliability) of the e-mail infrastructure is damaged whenever mail readers fail to implement security capabilities fully and promptly. If Nelson's or some other change has not been implemented in Thunderbird, then my guess is that all large e-mail server providers (except for those targeted at the enterprise or government market) have decided that they can't implement client certificates. If so, that decision is not good for humans. Bad. (Don't get me wrong. Support in the software world for certificates is second rate at best. That's ain't Mozilla's or Thunderbird developer's fault. But by supporting the security standards that have been adopted fully, Thunderbird developers and Mozilla can do a great service to society. When Thunderbird fails to provide such support, Thunderbird developer's and Mozilla are part of the problem.) See also https://bugzilla.mozilla.org/show_bug.cgi?id=188988 . Outstanding for years. Discouraging humans from using end to end encryption of e-mail. I am required by my work to use encrypted e-mail. So I can't search my messages. ****!
> Please let me know if Nelson's suggested change to Thunderbird has been implemented. If you are asking whether bug 437683 and it's blockers (bug 511384, etc mostly filed by kaie) were fixed, the anser is no. > sometime later, too far in the past for me to remember when, but certainly years ago, my problem with AT&T Yahoo! went away. I regret that I can not tell you whether this was due to a new version of Thunderbird or due to a change at Yahoo!. I expect many mail readers had the same problem, so maybe Yahoo! or AT&T decided to back out this change. I don't know how yahoo client auth has evolved over the years. perhaps javi or alice will know.
Flags: needinfo?(leofigueres)
Flags: needinfo?(alice0775)
I do not have AT&T Yahoo! mail
Flags: needinfo?(alice0775)
I am not an AT&T customer so I am unable to reproduce. Since being using Yahoo as my mail provider I have experienced some eventual problems while sending or querying for new messages, but they are not only on Thunderbird.
Flags: needinfo?(leofigueres)

It sounds like this email provider has fixed their configuration, and they no longer request client auth certificates from any CA. No reports in many years. Resolving as worksforme.

Remaining suggestions for improvement are tracked in other bugs.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Severity: major → normal
You need to log in before you can comment on or make changes to this bug.