sslssl-certificatetlsvpn
Is TLS the "new" version of SSL? What features does it add, or security issues does it address?
Can anything that supports SSL support TLS? What would be involved in making the switch? Is the switch worth it?
Why is it that emails are sent over "Opportunistic TLS" and VPN's often called SSL VPN? Is there a difference in the technology, perhaps creating room for a "TLS VPN" product line ?
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:
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.
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).
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.
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.
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.)
In order to download the certificate, you need to use the client built into openssl like so:
echo -n | openssl s_client -connect $HOST:$PORTNUMBER -servername $SERVERNAME \
| openssl x509 > /tmp/$SERVERNAME.cert
That will save the certificate to /tmp/$SERVERNAME.cert.
The -servername is used to select the correct certificate when multiple are presented, in the case of SNI.
You can use -showcerts if you want to download all the certificates in the chain. But if you just want to download the server certificate, there is no need to specify -showcerts. The x509 at the end will strip out the intermediate certs, you will need to use sed -n '/-----BEGIN/,/-----END/p' instead of the x509 at the end.
echo -n gives a response to the server, so that the connection is released
openssl x509 removes information about the certificate chain and connection details. This is the preferred format to import the certificate into other keystores.
Best Answer
TLS and SSL are closely related technologies.
First, email and Opportunistic TLS. ESMTP has the option of performing the actual data transfer portion of the conversation over an encrypted link. This is part of the protocol and has been called TLS for most of its existence. It works roughly like this:
Once the TLS session has been started, new login methods might be available. This is an example of a protocol that includes Transaction Layer Security in it directly. The certificates used are the same kind of certificates used for SSL over HTTP.
For an example of a service that doesn't include TLS directly, take POP3-over-SSL. In that case, the secure session is negotiated before the actual protocol is negotiated. In essence, POP3 is being encapsulated inside a secure session.
In general, if a service supports SSL it can be extended to support TLS. Whether or not that has been done is up to the maintainers of the service. This does mean that TLS can replace SSL in "SSL VPNs".
SSL VPNs are distinct from their IPSec based cousins in that the secure session is done at a different level. SSL VPNs do their work much the same way that POP3-over-SSL does, in that traffic is encapsulated over an existing TCP connection. IPSec VPNs create an IP-level secure tunnel, where SSL VPNs create a TCP-level secure tunnel. The reason SSL VPNs seem to be taking over is that they're easier to set up and are more tolerant of bad network conditions. SSL VPNs can and do use the TLS protocol for securing the session, though it does depend on the maker of the VPN itself.
As for the exact protocol level differences between SSL and TLS, that I can't get into. TLS as a standard was arrived at later than SSL and therefore includes some of the lessons learned in the early SSL versions. SSLv3 was ratified back in 1996 and TLS1.0 in 1999, and further protocol development appears to be limited to the TLS suite. It has taken a LONG time for SSLv1 and v2 to go away. TLS is the clear successor of the SSL suite.