Still waiting for IMAP and TLS
IMAP was a hero to most, but it never meant shit to me. (To paraphrase Public Enemy.)
I’ve never been a user of client-end, GUI mail software. My first Internet MUA was PcElm (as distributed by Demon as part of their. KA9Q-based software package). After a brief dalliance with Pine I came back home to Mutt. I have always used terminal based apps to read mail from a local mailstore (usually via ssh) Even on the occasions I needed to use a POP3 account, a fetchmail/exim combo was my MDA.
No HTML, no images, no attachments. Just pure text distilled into an 80×25 box.
And while this is fine for my own mail, I’m forced to use the more mainstream mail clients at work. Situations where I can no longer indulge the Holy Right of Obstinance granted to all Unix sysadmins. So, I decide to take a spin with a couple of free mail clients, and enable an IMAP daemon on my server.
Fully encrypted connections, and secure authentication is an absolute
necessity, natch. The most recent update of the IMAP specification,
RFC3501, has now been available for a year, and includes explicit support
for TLS encrypted sessions.
Before IMAP had TLS support you could use the hack of wrapping the IMAP daemon in SSL and run it on another port (commonly “imaps 993/tcp”, assigned for this purpose). But “imaps” wasn’t eventually adopted as the standard solution. Rather, the encryption is initiated from within the normal IMAP protocol using the STARTTLS command.
Now I appreciate that the idea of an quasi-application-level transport encryption layer is confusing. Perhaps a rough pop-culture analogy would help?
The dedicated SSL port is like that Whitehouse-Kremlin hotline that you used to hear about during the Cold War. It’s dedicated to the purpose of a secure line, and non-secure calls would need to be made with a different phone.
Application-level-initiated TLS is like that scene in Mission: Impossible
where Ethan Hunt screws open a Prague payphone handset, inserts a little gadget, phones an anonymous voice and requests the line be secured. It’s initiated as a regular phone connection but the security is enabled mid-call. Like magic.
So… I’ve installed an IMAP server that lists “STARTTLS” as a capability. I’ve tested it by connecting to “imap://lee@imap.example.org/” - mutt gets it right and negotiates a TLS connection.
I later attempt to configure a couple of “real world” mail clients to do the same: Thunderbird under Windows and Evolution under Gnome. I want to configure them to both always use TLS. Except… I can’t.
The IMAP configuration from Thunderbird (v0.5) makes no mention of TLS. It does have an check box for “use secure connection (SSL)”. I understand “secure connection” is what I want, but the addition of ”SSL” suggests it’s referring specifically to a SSL wrapped port rather than the generic concept of layer security? Clicking on the option changes the chosen port number to 993 (apparently not user changeable). So this is clearly for SSL wrapped IMAP only.
Evolution (v1.5.5) presents a similar option allowing a secure connection
“Always/Whenever possible/Never”. ”Wherever possible” is nice to have. However, setting it to “Always” means the connection fails if port 993 is unavailable remotely. Encryption is with IMAP/SSL only, then. (In fact, it’s just as well I made a point of checking – since it appears the only way to check on the encryption status of a “Whenever Possible” connection is by running something like netstat or lsof. If I’d have just selected “Whenever possible” with the knowledge that the remote server would offer encryption, then I’d have been left blissfully communicating in the clear.)
The bottom line is: Neither of these clients when connecting to a standard IMAP (OK, technically “proposed standard”) server are able to initiate an encrypted connection. The only way to secure their connections is arrange to run an extra server on a different port. Something that should be unnecessary by now.
Yes, I’m using “beta” software (but then in opensourceland, one-point-oh is usually an indication that the developers have lost interest). No, I haven’t trawled through the bugzillas yet. But, it’s not like STARTTLS is a new thing - RFC2595 (which documents the extension) dates from June 1999. While it takes time for standards to trickle down into libraries and toolkits, I can only assume that this one has been largely overlooked.
So why do mainstream clients support SSL rather than TLS? (Yeah, I’m sure your mail software supports it just fine. I’m not asking for recommendations.)
Partly, I think it has to do with the mindshare “SSL” has. It’s 2004, SSL should be considered legacy by now, but I’d guess that far more people recognise “SSL” (and have some understanding of what it is) than ”TLS”. In fact, SSL/TLS still tends to be referred to as “SSL” when used in a generic sense.
And if you’re not sure why it is we have two standard yet incompatible transport layer encryption systems, perhaps a quick explanation would help.
Back when the web was young, Netscape (ask your parents) designed and implemented a solution to the problem of HTTP traffic being transmitted in the clear, where sensitive information could be read by nefarious cyber-criminals. (Initially a proprietary Netscape extension.) Microsoft later proposed a similar, yet incompatible, solution called PCT. While both PCT and SSL where both submitted as drafts to the IETF, neither became full RFCs. Thanks to the dominance of Netscape Navigator, SSL (version 3) became the de facto standard for HTTP security, and a raft of alternative ports were registered with IANA to apply it to the other widely used protocols.
Microsoft and Netscape then worked together via the IETF TLS Working group to establish a successor to SSL as a single, open, Internet standard - TLS version 1 (January 1999).
However, before the completion of the TLS standard, it was decided that the practice of issuing separate port numbers for “secure” ports would be considered deprecated. The are a few good reasons for this:
- It would half the number of available “well-known” ports if every protocol required a “secure” and (by extension) “not secure” port.
- Having encryption negotiation occur at the very beginning of the session can cause problems. For a start it means that the certificate must always be the same. For many applications (including IMAP) this might not be an issue – but in the case of http it is. With the common HTTP over TLS/SSL (https) method, the certificate is presented before the client has a chance to specify which site they wish to request. Effectively this means that https sites must be allocated their own IP addresses, and the address-sharing approach used by “virtual hosts” cannot be used. (The application-level encryption activation method for HTTP which does not suffer from this problem is documented in RFC2817).
- Different URLs need to be used. Encryption is something that can be negotiated automatically between clients and servers – but when different URLs are used to distinguish between them, this is a choice usually presented to the end user.
- Socket level encryption may be unnecessary if end-to-end encryption is already in effect at a lower level (especially in the coming IPSEC utopia).
- Again, this is something that might be taken into account when client and server negotiate.
But on the plus side for SSL-wrapped protocols – if you already have an SSL toolkit, they’re simple for developers to implement on the server side. And when the server side is available, there’s pressure for implementation on the client side (which I imagine is easier to do with wrapped protocols). And if there’s wide enough client support, that’s what the servers will support. And so on. imaps will be with us for another decade if only because Outlook Express will be (fear!).
On a practical level, if you do already have access to an IMAP/SSL server running on port 993, this is all irrelevant. Both of the programs are capable mail clients, and probably far better than that piece of crap you’re using at the moment.
I guess I’ll just check if a couple of belligerent bug reports are required, before returning to my shell. Fight the power.
