Ssl – Apache TLS (SSL) Performance

Short answer:

SSL is the precursor to TLS. SSL was a proprietary protocol developed by Netscape Communications, later standardised within IETF and renamed as TLS. In short, the versions go in this order: SSLv2, SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2.

Contrarily to a relatively wide-spread belief, this is not at all about having to run a service on a distinct port with SSL and being able to on the same port as the plain-text variant with TLS. Both SSL and TLS can be used for the two approaches. This is about the difference between SSL/TLS upon connection (sometimes referred to as "implicit SSL/TLS") and SSL/TLS after an command was issued at the protocol level, typically STARTTLS (sometimes referred to as "explicit SSL/TLS"). The key word in STARTTLS is "START", not TLS. It's a message, at the application protocol level, to indicate there needs to be a switch to SSL/TLS, if it hasn't been initiated before any application protocol exchange.

Using either modes should be equivalent, provided the client is configured to expect SSL/TLS one way or another, so as not to be downgraded to a plain-text connection.

Longer answer:

SSL v.s. TLS

As far as I'm aware, SSLv1 never left the labs. SSLv2 and SSLv3 were protocols developed by Netscape. SSLv2 has been considered insecure for a while, since it's prone to downgrade attacks. SSLv3 internally uses (3,0) as its version number (within the ClientHello message).

TLS is the result of the standardisation as a more open protocol within IETF. (I think I have read somewhere, perhaps in E. Rescorla's book, that the name had been chosen in such a way that all participants were equally unhappy with it, so as not to favour a particular company: this is quite common practice in standards body.) Those interested in how the transition was made can read the SSL-Talk List FAQ; there are multiple copies of this document around, but most links (to netscape.com) are outdated.

TLS uses very similar messages (sufficiently different to make the protocols incompatible, although it's possible to negotiate a common version). The TLS 1.0, 1.1 and 1.2 ClientHello messages use (3,1), (3,2), (3,3) to indicate the version number, which clearly shows the continuation from SSL.

There are more details about the protocol differences in this answer.

When do I use which? When do I not use which?

Use the highest version you can if possible. In practice, as a service provider, this will require your users to have clients that support these versions. As usual, it's always a risk-assessment exercise (preferably backed with a business case if appropriate). This being said, cut off SSLv2 anyway.

In addition, note that the security provided by SSL/TLS isn't just about which version you use, it's also about proper configuration: it's certainly preferable to use SSLv3 with a strong cipher suite than TLSv1.0 with a with a weak (or anonymous/null-encryption) cipher suite. Some cipher suites, considered too weak, have been explicitly forbidden by newer versions of TLS. The tables in the Java 7 SunJSSE provider (and their footnotes) can be of interest if you want more details.

It would be preferable to use TLS 1.1 at least, but not all clients support them yet unfortunately (e.g. Java 6). When using a version under 1.1, it's certainly worth looking into mitigating the BEAST vulnerability.

I'd generally recommend Eric Rescorla's book - SSL and TLS: Designing and Building Secure Systems, Addison-Wesley, 2001 ISBN 0-201-61598-3 to people who really want more details.

Implicit v.s. Explicit SSL/TLS

There is a myth saying that TLS allows you to use the same port whereas SSL can't. That's just not true (and I'll leave port unification out for this discussion). Unfortunately, this myth seems to have been propagated to users by the fact that some applications like MS Outlook sometimes offer a choice between SSL and TLS in their configuration options when they actually mean a choice between implicit and explicit SSL/TLS. (There are SSL/TLS experts at Microsoft, but it seems they weren't involved in the Outlook UI.)

I think the reason why this confusion happen is because of the STARTTLS mode. Some people seem that have understood this as STARTTLS = TLS, but this is not the case. The key word in STARTTLS is "START", not TLS. Why this wasn't called STARTSSL or STARTSSLORTLS is because these extensions were specified within IETF, which only used names used in its specifications (assuming that the TLS name would eventually be the only standing, I guess).

• SSL on the same port as the plain-text service: HTTPS proxy.

Nowadays, most HTTPS servers can handle TLS, but a few years ago, most people were using SSLv3 for HTTPS. HTTPS (strictly speaking, standardised as HTTP over TLS) normally establishes the SSL/TLS connection upon TCP connection, and then exchanges HTTP message over the SSL/TLS layer. There is an exception to this when using an HTTP proxy in between. In this case, the client connects to the HTTP proxy in clear (typically on port 3128), then issues the CONNECT HTTP command and, provided the response was successful, initiates the SSL/TLS handshake by sending a ClientHello message. All of this happens on the same port as far as the connection between browser and proxy is concerned (obviously not between proxy and the target server: it's not even the same machine). This works just fine with SSLv3. Many of us in situations behind a proxy will have used this against servers that didn't support at least TLS 1.0.

• SSL on the same port as the plain-text service: e-mail.

This one is clearly out of specifications, but in practice, it often works. Strictly speaking the specifications talk about switching to TLS (not SSL) after using the STARTTLS command. In practice, SSL often works too (just like the "HTTP over TLS" spec also encompasses using SSL instead of TLS too). You can try it by yourself. Assuming you have an SMTP or IMAP server that supports STARTTLS, use Thunderbird, go into the preferences, advanced options, config editor and turn off security.enable_tls. Many servers will still accept the connection, simply because their implementations delegate the SSL/TLS layer to an SSL/TLS library which will generally be able to handle SSL and TLS in the same way, unless configured not to do so. As the OpenLDAP FAQ puts it, "While the mechanism is designed for use with TLSv1, most implementations will fallback to SSLv3 (and SSLv2) if necessary. ". If you're not sure, check with a tool like Wireshark.

• TLS on a distinct port.

Many clients can use TLS 1.0 (at least) for protocols where the secured variant is on a different port. Obviously, there are a number of browsers and web servers that support TLS 1.0 (or above) for HTTPS. Similarly, SMTPS, IMAPS, POPS and LDAPS can use TLS too. They're not limited to SSL.

When do I use which? When do I not use which?

Between explicit and implicit SSL/TLS, it doesn't really matter. What matters is that your client knows what to expect and is configured appropriately to do so. More importantly, it should be configured to reject plain text connections when it's expecting an SSL/TLS connection, whether it's implicit or explicit.

The main difference between explicit and implicit SSL/TLS will be in the clarity of the configuration settings.

For example, for LDAP, if the client is an Apache Httpd server (mod_ldap -- its documentation also mislabels the difference between SSL and TLS, unfortunately), you can use implicit SSL/TLS by using an ldaps:// URL (e.g. AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) or use explicit SSL/TLS by using an extra parameter (e.g. AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS).

There is perhaps generally speaking a slightly lesser risk when specifying the security protocol in the URL scheme (https, ldaps, ...) than when expecting the client to configure an additional setting to enable SSL/TLS, because they may forget. This is arguable. There may also be issues in the correctness of the implementation of one versus the other too (for example, I think the Java LDAP client doesn't support host name verification when using ldaps://, when it should, whereas it is supported with ldap:// + StartTLS).

In doubt, and to be compatible with more clients if possible, it doesn't seem to do any harm to offer both services when the server supports it (your server will just be listening on two ports at the same time). Many server implementations for protocols that can be used with either modes will support both.

It is the responsibility of the client not to let itself being downgraded to a plain-text connection. As a server administrator, there is nothing you can technically do on your side to prevent downgrade attacks (apart from requiring a client-certificate perhaps). The client must check that SSL/TLS is enabled, whether it's upon connection or after a STARTTLS-like command. In the same way as a browser shouldn't let itself be redirected from https:// to http://, a client for a protocol that support STARTTLS should make sure the response was positive and the SSL/TLS connection was enabled before proceeding any further. An active MITM attacker could otherwise easily downgrade either connections.

For example, older versions of Thunderbird had a bad option for this called "Use TLS, if available", which essentially implied that if a MITM attacker was able to alter the server messages so that it didn't advertise support for STARTTLS, the client would silently let itself be downgraded to a plain-text connection. (This insecure option is no longer available in Thunderbird.)

I had similar problem, commenting below line helped fixing the error. Final code looked like below -

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#ssl_ciphers PROFILE=SYSTEM;