Wandering Thoughts archives

SSL/TLS and forward secrecy

Here is an interesting question: does SSL have perfect forward secrecy, so that an attacker who compromises a server key still can't decrypt the server's conversations?

(While lots of people talk about SSL, the real name of the whole protocol is TLS, more or less. 'SSL' is the name Netscape gave to the original protocol; TLS is the name that it was officially standardized as.)

The answer turns out to be 'sort of', as I have found out through a bunch of web searching and reading. As far as I can tell, the situation is more or like this:

• in general, SSL (the original Netscape thing) does not have forward secrecy.

• some versions of SSL in some circumstances will generate ephemeral server keys, giving you forward secrecy; my reading suggests that this happens when a server is talking to an 'export-restricted' client (a client that had the key lengths it could use crippled due to old US export regulations). Such clients are likely to be very extinct by now.

• TLS has optional perfect forward secrecy. TLS (like SSL) supports a variety of ciphers, and some of those ciphers include using Diffie-Hellman ephemeral key exchange, which gives you perfect forward secrecy.
• however, various sources suggest that many TLS implementations do not use these ciphers by default, and must be specifically configured to enable them. Unfortunately it's hard to tell, since many clients don't report the cipher used at this level of detail.

(Such TLS ciphers all have names that start with TLS_DHE_. Note that there are other ciphers starting with TLS_DH_; these apparently do not provide forward secrecy. Some programs may report the cipher names without the TLS_ on the front.)

(Update: some TLS ciphers that use ephemeral Diffie-Hellman have names that start with TLS_EDH_ instead of TLS_DHE_.)

Sidebar: the versions of SSL and TLS

Since I just sorted this out myself:

• SSL v2 is the original version released by Netscape in their first products. After a while it was discovered to have relatively fatal security flaws.
• SSL v3 is Netscape's second attempt, closing the holes in SSL v2.
• TLS 1.0 is what was standardized by the IETF; it is based on SSL v3 but is not the same thing. There have been two subsequent revisions, TLS 1.1 and TLS 1.2; I believe both were done to fix security issues.

None of the protocols are interoperable with each other, although they are compatible enough that the initial handshake between the client and the server will let the two figure out the most advanced version that can be used.

(Although it is very depreciated by this point, SSL v2 support still lingers on in many libraries and programs, mostly for backwards compatibility reasons. There are probably still SSL v2 servers and clients still running in the wild.)

Why you want sysadmins, not users, to be providing the computing

One possible reaction to how we don't really control user desktops is to shrug and let users go their own way if they don't want to have one of the short list of provided desktop environments. You won't fight it, but you won't do anything to support it either; you'll let them run Ubuntu, or OS X, or whatever, but they're entirely on their own.

This is a great way to make a terrible mistake. You really do want 'IT' to be providing the computing environment, even if it means bending over backwards to support odd things, because the real job is to keep the organization working, or to put it another way, (part of) our real job is to keep the organization from getting harmed by IT issues.

(This 'real job' doesn't necessarily have anything to do with our official responsibilities. Consider it our speciality within the organization, if you want.)

If users build their computing environment themselves and do it badly, and it blows up, the organization still has a problem, possibly a bad one. And the more we wash our hands of environments, the less chances we have to mitigate potential disasters before they blow up in everyone's face. So over all the organization is best served if 'IT' provides the computing so that users don't have to try to do it themselves, and as we've seen that means trying to support things that the users like even if they don't entirely fit into our neat plans.

(I am not saying that users are always going to do build their computing environments badly. But I do think that they are predisposed to do so simply because it's not officially part of their job, so they don't get the time and resources to do the work. Overworking people is a recipe for problems in any field, and when something is not officially your job it has to take second place to your job's work.)

Disclaimer: this often doesn't work out in practice, but that's another entry.

Why SMTP needs a way of communicating partial success for message delivery

As illustrated in yesterday's entry, one of the problems of the (E)SMTP protocol is that after a SMTP server has accepted all of the message's destination addresses and gets to see the actual message, it has no way to tell the client that the message was delivered to only some of those addresses. This decision made perfect sense at the time that SMTP and then ESMTP were being created, because back then most of the plausible per-address problems could be detected at RCPT TO time and if not, well, you could just send a bounce message. These days it is now an inconvenient limitation and ESMTP could really use an extension that added more smarts to the process.

As shown yesterday, you can sort of fake it by selectively deferring some RCPT TOs, forcing the sender to break the destination addresses up into chunks of your choice (the ultimate version of this is to only accept one destination address per transaction). The problem with this is that the 'reject without enabling dictionary scanning' case is actually the simple one, because you know before you see the message body what the real answer for each address is; this lets you make an immediate decision about how to force the sender to break up the addresses.

Consider a politically complicated environment, where some people just want their email tagged, some people only want to reject email that is all but certain to be spam, and some people are willing to reject more widely. Here you don't know how you want to group the addresses until you've seen the message body, by which time it's too late.

While you can force the sender to split the addresses into groups by the type of filtering (if any) that the person has opted in to, the problem is that this forces the split on every email message, even the ones that don't need it, which makes things increasingly complicated and inefficient (and you are relying on mailers reacting sensibly, where by 'sensibly' you really mean 'the way you want them to'). One unwelcome effect is that users will probably get even their good email more slowly, as legitimate sending mailers get confused by your forced retries.

(Of course, this just brings up the thought that ESMTP could also use an extension to let the server advertise the recommended retry interval on any temporary failure. Increasingly the server has very definite ideas about this; either it wants you to retry very fast, or it knows that there is no point in you retrying before, say, half an hour because you'll just get another temporary failure. Some servers even put this sort of information in the text portion of their 4xx replies, which is at least very useful for sysadmins as we try to figure out why outgoing email to somewhere is being delayed.)