5 Answers
5

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.

When should SSLv3 go away and it be replaced by TLS? Any situations today or in the near future that this would be relevant?
–
LamonteCristoSep 3 '10 at 16:06

@MakerOfThings7 In terms of browser support, it will go away once 90% of actively browsing users support TLS without failing back to SSLv3. That'll probably happen some time in the next 5-7 years. That may change if an easy to exploit weakness is discovered in SSLv3 that would force a more rapid roll-out.
–
sysadmin1138♦Sep 3 '10 at 16:09

+1, The biggest difference is that SSL is implicit encryption, meaning the connection starts with an encryption handshake and doesn't do anything until that's successful. TLS is explicit, the connection starts and at some point the client asks to start encrypting the communication.
–
Chris SSep 3 '10 at 15:49

@Grawity, I think you're confusing TLS's fallback mode with SSL. Many apps will use a TLS wrapper that recognizes an SSL negotiation and starts the handshake immediately. If an app is running pure TLS (w/o fallback) then it must issue the STARTTLS (or equivalent, it's protocol dependent, though most protocols use that) before the encryption handshake begins.
–
Chris SSep 3 '10 at 17:13

All of those comments apply to SSL/TLS being used by other protocols. SSLv3 and TLSv1.0 are almost identical with differences only known to the protocol experts.
–
NaskoSep 3 '10 at 18:25

SSL as already people pointed out is a protocol designed by Netscape in the past. At some point the IETF standards body decided to adopt the SSLv3 protocol as a standard one, so it got change very subtly and it was named TLSv1.0.

So for most people, TLSv1.0 is almost equivalent to SSLv3. The reason people still call the family of protocols SSL is because of historical reasons - everyone is used to the name, so they keep on using it. It is quite possible for the VPN to be using TLS under the cover, but the marketing name still stays as SSL VPN.

Since TLSv1.0, there have been two revisions of the standard and it is now at TLSv1.2, which while still compatible, has some significant changes. Because of the SSL/TLS design, both client and server can negotiate which version of the protocol they want to use, so clients using TLSv1.0 can still talk to servers implementing TLSv1.2 and vice versa.

Considering the interoperability between all the versions of the protocol, there is no "making a switch", since they are the same family. It is a question of "do I need to use newer version?". As with any other area, the answer to this question will depend on whether the current version you are using has any limitations or not. Currently there are no problems with using SSLv3, but the majority of clients and servers out there work with TLSv1.0.

I hope this clarifies the picture a bit. If not, let me know what is still confusing I will try to explain further.

Is TLS the "new" version of SSL? What
features does it add, or security
issues does it address?

TLS is T ransport L ayer S ecurity and generally refers to the STARTTLS command in SMTP mail servers. It may or may not use SSL (SEE palm versamal for an example) but in general SSL is the main security system used. TLS has also been used for other purposes (like HTTP ) and the latest RFC spec is at version 1.2

Can anything that supports SSL support
TLS? What would be involved in making
the switch? Is the switch worth it?

Usually but by anything, with TLS being the consideration, you are referring to mailservers, so specifically mailservers that have an SSL cert can use TLS to transfer mail and recieve mail.

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 ?

This smells like the marketing meatheads got in the room. "Opportunistic TLS" simply means that if starttls does not return a 220 (Ready to start TLS) go ahead and send the email anyway. Note that TLS is a SENDER option not a reciever option it might be possible with some mail servers to refuse non-TLS mail but that would be the exception not the rule.

TLS also supports mutual authentication and not simply encryption of a connection.

Sending an email over a VPN (whether SSL or another security scheme) simply makes the mailservers security essentially irrelevant, you can use TLS over a VPN (and you can even use TLS as the VPN security scheme) but it doesn't necessarily affect how the mail is transported if only the VPn connection is encrypted between mailservers (so from the source and destination mailservers, they might be transmitting standard cleartext)

I beg to differ. TLS does not generally refer to STARTTLS command in SMTP. Any documentation that you read will refer to TLS as the TLS protocol, which is used by SMTP to protect its traffic. Now when it comes to "Opportunistic TLS", then you can involve higher level protocols which have the "opportunity" to use TLS or not.
–
NaskoSep 3 '10 at 18:29

You are certainly welcome to disagree however if you ask 10 admins what TLS is used for 9 will say email. Even the question presumes emails regarding TLS. I also mention that TLS is used for other things. RFC 2434 defines which ciphers can be negotiated in the serverhello message- it has nothing to do with opportunistic TLS. SMTP doies nto define any encryption. RFC 3207 defines starttls as a server extension
–
Jim BSep 4 '10 at 4:21

"TLS" only refers to "STARTTLS" incorrectly. STARTTLS is just a keyword to generalize the approach, but it requires integration in the initial protocol. The STARTTLS command looks similar in SMTP and IMAP, but needs to be integrated in the syntax in LDAP; the same mechanism in S-HTTP (not HTTPS) doesn't use that keyword. It's not because mail clients offer a choice between "SSL" and "TLS" to mean a choice between initial and opportunistic SSL/TLS that their use of the name is right. I bet some SMTPS servers support TLSv1 very well, upfront. You might also see some SSLv3 after using STARTTLS.
–
BrunoSep 8 '10 at 19:17

1

That answer is wrong. STARTTLS is a command used in many protocols (e.g., SMTP) to initiate TLS or SSL. Other than that they are irrelevant.
–
NikosJan 7 '13 at 9:03

"SSL has been around for about a decade from its inception at Netscape. TLS is based on SSL 3.0, mainly so the IETF could have an open, community supported standard which could then be expanded with other Internet standards.

Basically, there isn't a world of difference between SSL and TLS. You will often see them supported in the same applications (SSL/TLS). They do not interoperate (one has to be picked at negotiation), but TLS can transform itself into SSL3 if necessary. As far I as I know, not much has been going on with TLS as a standard (it works well, just like SSL3). It was upgraded to comply with HTTP 1.1 and supports all the popular ciphers.

In server related projects, especially open source ones, TLS is basically superceding SSL. For clients, SSL3 is pretty much a standard (usually TLS is default, but it routinely downgrades to SSL3). You can support both TLS and SSL, so there is no conflict there.

You can make your own SSL certificate for encrypted communication with a program called openssl. Your server (of any type) will have documentation on supporting SSL/TLS.

A certificate only means so much, because it doesn't actually verify you are the indentity you claim you be. You could claim to be BusinessXYZ and actually be a scam artist. For third party verification, you have to use a service from a company like Verisign (not sure if they bought out all their competitors or not). Verisign is what is known as a Certificate Authority (CA), because they act as a third party to identify you as in fact you. Users coming to your site engaging in SSL/TLS communication will be notified by a prompt if your site cannot be identified by a CA. If you go with a CA, they can help you with all the details."

Might be nice to link to the source which you copied that from?
–
jscottSep 3 '10 at 15:36

sorry i have google about the same bcoz i was looking the same answer
–
RajatSep 3 '10 at 16:08

1

@Rajat: I find nothing wrong with using Google. I just think you do a lot of copying/pasting without any attribution, here, and on your blog. FWIW, I did not give you -1. But, again, it would be nice if you updated your answer to link to the source.
–
jscottSep 3 '10 at 16:15

2

You really shouldn't paste from another persons content without attribution. I think it's poor form and in many cases patently illegal. Is it really so much to add the link to the text?
–
Jim BSep 3 '10 at 17:06

4

@Rajat : It appears you have internet access now. Can you edit your post and make sure your post is correctly attributed to the source?
–
Stefan LasiewskiSep 3 '10 at 18:52