[1] In the case we're calling "SSL", the client connects to the SMTP/IMAP server (usually on port 465 for SMTP, 993 for IMAP), and immediately starts an SSL handshake.
[2] For "TLS", the client starts a normal SMTP/IMAP connection on the standard port, queries the server as to whether it supports SSL, and then begins an SSL handshake if it does.
Right, via the STARTTLS command. Several protocols use this same pattern, including SMTP, POP, IMAP, LDAP, BEEP, and others. There is a reason for this, more below.
FWIW, the thing people think of as "SSL" comes in four different versions. In the fourth of these, it was decided that "Transport Layer Security" was a more accurate term than "Secure Sockets Layer". So, in a way, TLS version 1 == SSL version 4.
Actually it's literally SSL version 3.1, if you look at the numbers in the protocol message. SSL was developed by Netscape on its own. When an IETF working group was formed to make this technology an IETF standard, the name TLS was chosen as a neutral term since Microsoft at the time was promoting a SSL alternative, which was later abandoned. In retrospect they should have just stuck with the SSL name since everyone knows what it means (more or less).
Also, in general, the IETF is trying to get people to move away from option [1] above, in favour of [2].
That is understating the point. For all protocols for which STARTTLS is defined there is no standards status for the separate-port approach; that is, there is no RFC that mentions it. So to be standards-compliant an implementation has to support the STARTTLS approach. Implementations can support the separate-port approach if they want to (and of course most do), but it's outside of any standard (though of course for most protocols the foo-over-SSL port remains allocated). For SMTP there was a particular push to deprecate the separate-port approach because there were legitimate concerns that it could destabilize Internet email if MTAs didn't know which ports service was being offered on and had to depend on resets and timeouts to figure it out.
At the very least, it makes writing smarter, self-configuring clients easier.
Let me stress this point, since it is often misunderstood (for example Thunderbird is still entirely screwed up in this regard). The separate-port-for-SSL approach probably was necessary in the case of HTTP to get SSL adopted, but it is really a terrible approach to adding security to a protocol. The key with making optional features work in general is to permit their use to be negotiated, which is what the combination of CAPABILITY and STARTTLS do for TLS. Without the ability to negotiate, the use of SSL/TLS has to be explicitly selected by the user (theoretically clients could try probing ports by default but that just seems like a bad idea). So with the separate-port approach, the default is no SSL, and if you want SSL the user has to go into a mysterious config screen and check a scary box. Sites are reluctant to force users to do this, for fear of support costs, so they just run without SSL and suffer stolen passwords. This sucks.
With STARTTLS, a site like ours that wants to protect people's passwords can set our IMAP servers to advertise TLS and require that it be negotiated by a client in order to log in (or they can use SASL/GSS/Kerberos, but that's another story). A client that has been thoughtfully designed will be set to use TLS if it is offered by the server. This way the client will work just fine, securely, with our site *without the user having to configure it*. And it will still work fine with plain old sites that just use cleartext. So everybody wins. But note this means that the client has to ship with "use TLS if offered" as a default. It is sometimes argued that client providers don't want to do this because it can mean users will see funny SSL error messages (can't validate cert etc) if a server supports STARTTLS but hasn't set it up right. But it seems profundly wrong to me that such misconfigured sites should cause the default to be set wrong for all the rest of us.
This is kind of a pet issue of mine.
- RL "Bob"
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
