Thunderbird - It’s All Yours
Yesterday I read about the availability of a new version of Mozilla Thunderbird, which is all-around a pretty decent mail client. The new version is 3.0.x, and I’m currently using 2.0.x, so I figured it was due for an upgrade. I downloaded the new installer, uninstalled the previous version, and launched the installer. Everything appeared to be going fine.
Probably when the installer finished it offered to “Launch Thunderbird now”, and I took it up on the offer. For some reason, Thunderbird opened with an empty configuration, i.e., none of the mail accounts I had set up under 2.0.x were listed. I remembered having had previously been offered to “import settings” every other time I had installed a Mozilla product, so I launched that wizard. When it got to the step where I was supposed to select the application from which to import settings, the dialog box was blank and only the ‘Cancel’ button was enabled.
Although I felt it was a little strange that Thunderbird would not be able to keep its settings across an upgrade, I decided to press on. After all, I switch operating systems often enough that I usually end up redoing all that config once in a while anyway. So I selected ‘File’ -> ‘New’ -> ‘Mail’. The resulting dialog asked me just three questions: name, email address, and password. I became slightly suspicious when I noticed that the font sizes on the buttons didn’t match, but little did that prepare me for what happened next…
I am dumbstruck to see the the dialog box enlarge and display changing hostnames and port numbers which have no basis in reality. They are simply variations on a theme: my email address’ hostname with various mail-related prefixes and protocols attached. Essentially, it was doing a port scan against my domain. I knew that this port scan could have but one sinister purpose: to transmit my password to whomever was willing to pick up on the other end of the line!
Hostnames looked up:
imap.example.com
smtp.example.com
pop.example.com
pop3.example.com
mail.example.com
example.com
Ports probed:
tcp port 143 imap
tcp port 993 imaps
tcp port 587 submission?
tcp port 465 smtps
tcp port 25 smtp
tcp port 110 pop3
tcp port 995 pop3s
Since not everyone is deeply familiar with the protocols involved here, I will point out the problem in case you haven’t guessed it. These are classic protocols used for transferring email. Like most older protocols, they were originally specified to transfer the password in-the-clear, and all of them have had some degree of protection for it added later. This has resulted in a situation where multiple versions of each protocol exist, sometimes simply wrapped in SSL/TLS and run on a different port number, and sometimes a negotiation is made to upgrade the security of a connection made to the original port. If the attacker can simply disrupt access to the secure connection, the application is induced to transmit the credentials over the insecure one. This is the crudest form of downgrade attack.
I also tried accounts for a couple of popular free email providers, Gmail and GMX. Interestingly, this detection process returned instantly even with a bad password and blocked connection. They both supported SSL/TLS unequivocally. Perhaps these providers have registered for special handling in Thunderbird (and in so doing increased the effective security for their users).
Admittedly, this auto-detection scheme probably looked dynamite to the user interface designers at Mozilla wanting to improve the experience. But (bless their hearts) it is quite the security bungle.
Thunderbird - It’s All Yours [mozillamessaging.com]
Easier to Get Started
All you need to provide is your name, email address, and password and Thunderbird will find your email settings and set up your email accounts for you. It’s that easy.
The generous explanation is that security concerns were weighed against usability concerns, and after soul-searching deliberation it was felt that, on balance, this represented a net improvement for their users. (A common mistake in security design is modeling the user as an aggregate statistic.) Some other explanations are that they didn’t think of the security concerns, the concerns didn’t come from influential parts of the organization, or they dismissed them out-of-hand because they just don’t care that much. I have no idea.
Of course there was no way it was going to arrive at reasonable settings for my single-user domain, I tunnel all that stuff over SSH and don’t have the ports listening. But Thunderbird gave me no informed consent before it started poking around for insecure connections to make, and even if it had managed to auto-detect some usable set of connection parameters, I assume it wouldn’t have explained the risks of using them. Given the protocols involved, it must have been willing to leak the credentials in order to determine if the parameters were usable.
It may be that the auto-detection logic doesn’t actually use your password. I didn’t actually set up insecure servers to verify that either way. Regardless, it is not a difference in practice since the password must obviously be transmitted the first time it is used.
I find this somewhat non-intuitive, but really the only secure way to configure these email settings is to have them conveyed from your email admin all the way to your mail client via a trusted channels of communication. The actual admin is able to tell you “this is the name to use for the mail server and be sure to check the box that says ‘require SSL/TLS’”. But no auto-detection scheme can know to check that box.