Contents

Talk:Transport Layer Security: Difference between revisions

Revision as of 17:45, 31 January 2008

Template:FOLDOC talk

Cryptography: Computer science Unassessed

This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles ??? This article has not yet received a rating on Wikipedia's content assessment scale. ??? This article has not yet received a rating on the importance scale. This article is supported by WikiProject Computer science.

Template:CryptographyReader

Merged TLS and SSL. Hooray! The Anome

"Both practices have been found present in many commercial websites such as those of Bank of America, Washington Mutual, JPMorgan Chase & Co. [4], and PayPal."

The cited link is dated 2005. Seeing as it is now 2007, perhaps "as of 2005" should be added to the above sentence? --Anonymous

Shouldn't this now be moved to Secure Sockets Layer, since that is by far the most common term? anthony (see warning)

I agree with anthony. Internet Explorer and Mozilla Firefox, to name just two browsers, only have SSL 2.0/3.0 enabled by default; TLS 1.0 is not even supported by default. The term "TLS" is much less known and should be put in second place. --Eruionnyron 12:43, 9 Feb 2005 (UTC)

Firefox 1.5 has TLS 1.0 enabled by default now --JavidJamae 21:14, 21 Mar 2006 (UTC)

Agreed. That was my first question after seeing it listed on Wikipedia:Peer review. If SSL is more popular, or is the more common term (and includes TLS), then the article should be moved. -- Wapcaplet 19:39, 14 Feb 2005 (UTC)

I also agree (although we may have to move it back again in a couple of years...) — Matt Crypto 02:19, 15 Feb 2005 (UTC)

Disagree. TLS is name of Standard Track successor to SSL. While SSL is commonly used as a synonym for TLS, TLS is correct name of the protocol as implemented in modern Internet clients and servers. I believe article should be named "TLS" and TLS first meantioned. Kdz 03:41, 11 June 2006 (UTC)[reply]

SSL is diferent than TLS. So an interesting composition for me is each one having it's own article. There are informations that applies only to SSL and despite the creation of TLS, there still are informations only pertinent to SSL. And with TLS, a new and/or parallel thread/chapter/path in the history of communication security has began. SwH27 01:32, 4 August 2006 (UTC)[reply]

Yes, SSL is different from TLS, and the argument of TLS being in the same section as SSL was made on the use of TLS in web browsers. TLS is not limited to web browsers. It is now widely used in various other applications like VoIP. Hence, it deserves a separate section - Siddhartha Gavirneni.

Agreed. Many things changed: version, name, security, became IETF standards tracked, enabled in browsers. In addition it is confusing to say "SSL" and mean one or the other or both. Mmernex 14:10, 11 April 2007 (UTC)[reply]

Why were the two articles merged in the first place? Granted they have things in common, but that's not reason enough to put them under the same article. It makes the protocols seem interchangeable, which is not necessarily the case. If there wasn't sufficient reason to merge them, then I suggest that they be restored to separate articles. VanishingUser 20:06, 22 April 2007 (UTC)[reply]

They should just have diffrent articles, afterall they are not exactly the same.

I removed a few (redundant) internal links. The text use to be:

• RFC 3268: "AES Ciphersuites for TLS". Adds Advanced Encryption Standard (AES) ciphersuites to the previously existing symmetric ciphers, like RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and Triple DES.

Any objections? --Eruionnyron 14:39, 9 Feb 2005 (UTC)

Seems like an obvious improvement to me. — Matt Crypto 02:19, 15 Feb 2005 (UTC)

Not sure this diagram is 100% correct as I have an SSL/TLS essentials book here that has other items. Besides this, the image has a mix of German / English (e.g. "mit...") which has no place on English Wikipedia. Can we replace? I can scan one in from my book if this is legal. 62.31.122.158 (talk)

What's the diff? --lenehey

Reminder/Todo Mmernex 12:20, 12 July 2007 (UTC)[reply]

We currently say "The term "SSL" as used here applies to both protocols unless clarified by context." I suggest we use the term "SSL/TLS" for this purpose. That way, it's clearler which protocol is being discusses at any given point. — Matt Crypto 13:05, 16 Mar 2005 (UTC)

Any reason for using a \ (SSL\TLS) instead of SSL/TLS? -- LukeyBoy

No difference to the name/protocol. Seems to be a grammar or culture difference. Mmernex 14:11, 11 April 2007 (UTC)[reply]

How secure is SSL/TLS? What sort of attacks is it susceptible to? How much can it be trusted in various applications? The article should address some of these questions.

Indeed, I believe at least a mention to SSL version 2 vulnerabilities, such as the downgrade man-in-the-middle attack are very significant. SSL version 2 should be phased out as soon as possible, and this should be mentioned. Servers and clients which support version 2 as well as newer versions could still be subject to these attacks. There is a reason that Mozilla and MS IE are doing away with it. -- TDM 14:15, 22 November 2006 (UTC)[reply]

Agreed, this is a security protocol, the article is lacking in details on security and attacks. —The preceding unsigned comment was added by Mmernex (talk • contribs) 14:05, 11 April 2007 (UTC).[reply]

Shouldn't there be something about how vulnerable SSL is, especially in a work environment where the boss could put in hardware like Finjian Vital Security Applicance. How secure is SSL to this kind of thing, or is there anyway to get around this problem.

Afaict SSL is safe as long as YOU control the client (and you trust the root CA and the server ofc). If your boss controls the client (as they will in a workplace) they can either just tap stuff before its encrypted or put on a new root cert (which will then let them mitm your connections) Plugwash 19:49, 6 March 2006 (UTC)[reply]

Meetabu moved this article from Transport Layer SecuritytoTransport Layer Security-SSL. I object to this for two reasons. The most obvious one is that there is no such term as "Transport Layer Security-SSL". The second is that the move left many, many double redirects. Can an admin please undo the move, and then we can discuss properly what the name should be (although such a discussion was already carried out in February, see higher up on this page)? Haakon 11:44, 30 November 2005 (UTC)[reply]

Update: thanks to the speedy assistance of JoanneB, it has been moved back. I think there is consensus on this current name. In the future, if someone wants to move it (or any other article), please familiarize yourself with Help:Moving a page, and discuss it here unless you only move to fix spelling etc. Thanks. Haakon 12:05, 30 November 2005 (UTC)[reply]

I see an Internet protocol suite widget beside the main article of SSL. But SSL doesnt figure in the widget! Can it be included there?

The article says that the following are incorrect uses:

   * Only securing the form submission page, while failing to secure the login page
   * Displaying a secure page mixed with non-secure media

While I agree with the second one, I think the first one is pretty pointless. Both links describe why this is wrong: if the attacker (man in the middle) can change the unsecure login page, he can then change the target of the form and submit to an insecure server.

The attack can be more inconspicuous. The attacker could steal the user's password using AJAX and still submit the page to the legitimate server without the user being the wiser. --Any honey 27 Feb 2006

The point about MITM-type attacks on forms-based authentication is correct. Encrypting the form itself (auth request) has no effect on the auth response. It is commonly done anyway so that the encryption icon will appear in the browser, giving the user a (false) sense of security. Therefore, if the form has been tampered with, TLS encryption provides zero security for authentication. This is actually a pitfall in the forms authentication system. To fully contextualize these concerns, the article could be updated to say, "Using TLS to encrypt forms-based authentication is an incorrect use, because the recipient (target) is unknown to the user regardless of what takes place at the transport level." Miqrogroove 14:36, 23 July 2007 (UTC)[reply]

It is safe to say that if the attacker can change the login page, he can already change the one page before it, and point the user to the spoofed secure login page. The only way to counter this would be users accessing the first page by typing https://... directly into the browser, but that's a whole another story.

The attack you propose is more conspicuous. A user just needs to look at the address bar to realize that they are not at their bank's website. With the current attack, passwords can be stolen while the user remains at the legitimate website, up until the time their passwords are submitted. --Any honey 27 Feb 2006

Besides, wouldn't the browser show the certificate verification screen before the user's form is submitted anyways?

The attack could be performed with AJAX as my comment above. But also, most users have that verification dialog disabled, because it is annoying. --Any honey 27 Feb 2006

I meant the certificate verification dialog, the "Accept/Accept once/Refuse" one. I don't think it's even possible to disable that dialog. Regarding your top two comments: my point was that unless the first page the user accesses is https, it's pretty much irrelevant if the login page is secure or not.

I don't see how those two are related. Even if the first page the user access is https, which links to a normal http login page, the user is still vulnerable. --Ant honey 28 Feb 2006

Your address bar argument really doesn't hold, since you can make a page which loads the malware AJAX and the real (https) page inside a frame that occupies the entire viewport. I've tried and it works flawlessly. --Jaka Jancar 15:27, 27 February 2006 (UTC)[reply]

I don't understand your point. So your situation is that you have a site at http://mybank.fakesite.com/ which has an IFRAME that loads http://mybank.com/. Is that situation supposed to fool the user? I doubt it would, because the URL that is displayed in the browser will be the malicious one. My address bar argument is that the user would be at http://mybank.com/ and they would see that in the address bar, yet they wouldn't know that it is unsafe. This is a more dangerous scenario than yours. --Ant honey 28 Feb 2006

Two already mentioned this in the comments on the Microsoft blog link, but the blogger didn't respond at all... --Jaka Jancar 20:04, 26 February 2006 (UTC)[reply]

In the public encryption reference I see some confusing information. If things are as I suspect, it would a lot clearer and more correct to say that "SSL/TSL can use RSA for public key encryption and that public/private key exchange/loading can be facilitated by Fortezza, Diffie-Hellman, DSA, and RSA." The only public key encryption standard for actually securing data session that I recognize and find elsewhere in Wikipedia is RSA. If somehow correct (doubtful) there needs to be some explanation of how SSL can use Fortezza and DSA, symmetric (private key only) algorithms to do public key encryption (asymmetric). I suspect that Fortezza cards are merely used as smart cards to store and load digital certificates. I further suspect that DSA is merely used as a public standard for signing and maybe encrypt keys or certificates exchanged. I would expect the Diffie-Hellman is also merely used for securely exchanging private keys. It would be very interesting to see confirmation that the DSA or Diffie-Hellman algorithms were actually extended to session encryption of actual SSL/TLS sessions. I don't totally exclude the idea that open source coders might have hacked extensions but I would like to see an explicit statement that is what is being said...plus some comments on the cyprographic validity of the extensions. Yes I am well aware that most SSL uses symmetric key encrypted sessions. But I also keep seeing references that some versions have an option to use public key encyption for the sessions themselves. 15 Nov 2006

I would like the article to also include the reason why symmetric encryption is used after the key exchange. This would seem to be a vital piece of background information. According to RFC 2246, "Cryptographic operations tend to be highly CPU intensive, particularly public key operations." I'm not sure if that is the direct reason, but it's the best one I know of at the moment. Miqrogroove 14:41, 23 July 2007 (UTC)[reply]

The article suggests that that TLS 1.0 is essentially the same as SSL 3.0, and infact (inconsitently) uses the term "SSL" to designate either or both. Does that mean they are interoperable? If not, what distinguishes them and which is in greater use today? I don't mean to sound too critical. I have found the page as is very useful and enlightening. --Lenehey 21:23, 4 April 2006 (UTC)[reply]

Section 7 of the article says that TLS 1.1 uses a newer version of PKCS#1 to protect against the Bleichenbacher attack. However, rfc 4346 section 7.4.7.1 says that TLS 1.1 retains the original encoding. Instead, it includes an implementation recommendation (responding with a random premaster secret if the RSA block is incorrectly formatted) which should make TLS 1.1 immune from this attack. --12.130.8.219 18:41, 17 July 2006 (UTC)[reply]

« SSL runs on layers [...] above the TCP transport protocol » : doesn't it also run above UDP, as in OpenVPN ? --Olivier Debre 09:52, 13 April 2006 (UTC) Without any negative comments, I added it in the article. --Olivier Debre 07:24, 21 April 2006 (UTC)[reply]

Actually, I will have to disagree (with 363 days of delay). From what I understand, and from what I see in the RFCs, only TCP is mentionned. TLS over UDP has apparently a draft somewhere, but is not a standard in any way. DTLS provides TLS services using datagram transport protocols, such as UDP, but not TLS.

Imho, this modification should be removed because it could lead (it did for me) to false statements. --Papadopa 11:47, 11 April 2007 (UTC)[reply]

Per the RFC: "At the lowest level, layered on top of some reliable transport protocol (e.g., TCP), is the TLS Record Protocol. I also vote to be consistent with TLS and SSL above a "reliable transport protocol", and move references to anything else (DTLS) to its respective page. Mmernex 14:02, 11 April 2007 (UTC)[reply]

Confirmation also on OpenVPN site: "Because SSL/TLS is designed to operate over a reliable transport, OpenVPN provides a reliable transport layer on top of UDP" (http://openvpn.net/security.html). Btw, someone did the modification already, so its fine now... --Papadopa 07:32, 13 April 2007 (UTC)[reply]

The TLS 1.1 section of the article states that "TLS 1.1 is currently a draft and is expected to be published as an RFC late 2005." This should be updated since 'late 2005' has now passed. --Michael McMullen 00:12, 19 April 2006 (UTC)[reply]

There is no mention of the server hello done message which is imo required by rfc and not optional.

Fixed. Mmernex 13:58, 11 April 2007 (UTC)[reply]

No actual reference to SSL in that particular link. It just redirects to Komodo (the lizard).

Strange. I removed it. Thanks. Haakon [[[[[[Image:

${\displaystyle <math>['''''18:57,5June2006(UTC)''''']}$</math>]]]]]]

I feel that this article is far too complicated for the average layman who is curious about SSL but has never read about it before. There are many concepts appearing in the article that the average layman is not to be expected to know anything about.

Can someone with knowledge in this field please write, say, a section targeted at laymen? That section could for instance include an example like: How does RSS work step by step when you login to your online bank account by providing the site with a username and password? What happens to the username and password? How is it transferred and why is it secure? Just explain this and things like it in laymen's terms.

After reading a general thing like that, the technical discussion might be easier to understand.

I concur, but being a novice in the field I'm unable to do it my self. Is there a "make this simpler"-tag that can be applied? -Jackcall 18:47, 17 July 2007 (UTC)[reply]

I consider myself a 'layman' in this particular area, but after having read the article I'm going to propose an analogy as follows:

• There are three people, Chris the Client, Ian the Internet, and Sean the Server. Chris has a green padlock with two keys. Sean has a red padlock with two keys.
• Chris wants to send a secret message in a locked box to give to Ian to pass to Sean.
• Chris puts a green key in the box and puts the green padlock on the box.
• Chris gives the box to Ian (who can't open the box) who gives it to Sean.
• Sean puts the red padlock on the box.
• Sean gives the box (now with two padlocks) back to Ian (who still can't open it) who gives it back to Chris.
• Chris takes the green padlock off using his other key, leaving the red padlock still on the box.
• Chris gives the box back to Ian (who can't open it) who gives it back to Sean.
• Sean takes off the red padlock, opens the box, and takes out the green key.
• Sean puts a red key in the box and does a similar series of secure exchanges to get it to Chris
• Sean and Chris both have red and green keys. They combine the patterns on the keys to produce a common blue key that can open a common blue padlock.
• Chris puts his message in the box, puts on the blue padlock, and gives it to Ian.
• Ian (who can't open the box) gives it to Sean.
• Sean, now armed with a blue key, can open the box and read the message, and can return secret messages of his own to Chris.

I know the analogy breaks down a little when you get to combining keys, but I think it's reasonably easy to follow. Can any experts tell me if it's appropriate? --Eamonnca1 23:39, 1 November 2007 (UTC)[reply]

I cut the following link from the "External link" section.

• SSL Interactions Described as a Sequence Diagram (PDF)

At the end of the handshake protocol, this document states:

At this point, the client can send the symmetric secret key to the server after encrypting it with the public key received in the server's SSL certificate. This encrypted secret key can only be decrypted using the private key. Thus only the server is able to decrypt the message.

I am afraid this is not entirely correct. The "Premaster secret" is sent with the "Client Key Exchange" message. Not at the end of the handsaking protocol.

What do you think about it ?

Anyway, the collection of protocol diagrams pubblished in the same web site seems to be very usefull.

Regards by M.G.F. --212.34.227.53 20:36, 26 December 2006 (UTC)[reply]

I heard somewhere that the rise in popularity of Internet pornography brought about the creation of SSL, is this true? W3bbo 21:53, 14 February 2007 (UTC)[reply]

It's probably fair to say it was an influence, but so was banking, e-commerce, data backup, etc.

I don't understand why there is a blurb stating the article does not reference its sources. It points to the RFCs that define SSL/TLS.

There seem to be common misconceptions about SSL. For example, some people think that because DNS is not secure, SSL can not be secure.

Is there an SSL FAQ? Would be nice to get a link to it.

Links or info to developers who want to add SSL support for their products. There are some do's and dont's that one should follow...

TLS is mentioned as a Record layer protocol, but no link is provided to define this term. Indeed, searching "Record Layer" in Wikipedia seems to return no relevant results. Can anyone insert a short explanation for this term, or better yet, create a link to a Record Layer article? —The preceding unsigned comment was added by 201.9.210.80 (talk) 15:02, 21 April 2007 (UTC).[reply]

Good point. This should be clarified as "TLS Record Protocol", rather than a general "Record Layer". It's unique to TLS/SSL, but not novel in any way. Mmernex 12:32, 12 July 2007 (UTC)[reply]

There is an inconsistency between the "Applications" and "History and Development" sections.

The "Applications" section states that "In 1997 the Internet Engineering Task Force recommended that application protocols...offer a way to upgrade to TLS".

The "History and Development" section holds that "TLS version 1.0...[was] first defined...in January 1999".

How would the IETF recommend that application protocols offer a way to upgrade to TLS two years before the introduction of TLS?

One of these two sections probably needs an update. I suspect that the "TLS" in "Applications" should instead refer to SSL, but have no sources to verify my suspicions.

Fritzophrenic 10:25, 17 May 2007 (UTC)[reply]

I will 2nd your motion, and tagged it for a missing reference. I believe the first official tls standard was Jan 99. Mmernex 15:05, 17 May 2007 (UTC)[reply]

Wouldn't it be more meaningfull to describe that the goal of TLS is to provide privacy and integrity and thus could prevent eavesdropping, tampering and message forgery? --Jamiefiere 09:31, 25 June 2007 (UTC)[reply]

I just turned some lists into tables, which looks better, but I'm wondering, why are there so much lists and tables? I think there should be less lists and tables and text in it's place. (I would do it, but i don't know anything about the article.) —Andrew Hampe ^Talk 23:56, 1 July 2007 (UTC)[reply]

It's a balance of how much information to include so it can be understood vs. all the gory technical details. There's much more to ssl than is listed (each handshake message, etc.), so maybe this should transition to a wikibook, with a good summary here?Mmernex 17:53, 2 July 2007 (UTC)[reply]

I suppose SSL cert is a standard, and should not depends on what server/software we are using.

totalz

Then why in applying a certificate from [www.thawte.com], it asks :-

- web server software If your server software platform does not appear in the list you should select the 'other server software' option (we recommend you request a 'test certificate' first, if your software is not listed).

Please note: if you select the 'other server software' option your certificate will be set as non-resignable on our system. This means you will need to submit a new CSR upon renewal as our system has no way of knowing if the renewed certificate can be installed to the original private key on your server. Please click 'here' for more information on re-signable and non-resignable platforms.

totalz

This actually creates some kind of confusion as SSL is server dependable!

Very good article. Suggestion: how about adding a section on the use of the terms SSL and TLS when configuring software such as Mozilla Thunderbird and University of Washington Pine, where TLS essentially means use STARTTLS, and SSL means don't use STARTTLS. (If I understand correctly, with such software, selecting SSL versus TLS in the configuration does not select the SSL versus TLS crypographic protocol.) Isn't this part of the common confusion about the terms SSL and TLS ?

nishri —Preceding comment was added at 00:48, 6 November 2007 (UTC)[reply]

Which version(s) of the protocol(s) do the "Description" and "How it works" sections describe? A thumbnail explanation of the differences between versions would also be useful. -- Beland 20:44, 30 November 2007 (UTC)[reply]

Shouldn't TLS be a 4th tranport layer protocol? Afterall, it is even in the name! —Preceding unsigned comment added by 198.24.6.134 (talk) 21:17, 3 January 2008 (UTC)[reply]

The whole notion of "layer 3" versus "layer 4" versus whatever is an anachronism. It works well as a teaching tool, but doesn't actually model TCP/IP. For your specific question, you can run IP over TLS (as with any SSL VPN). It's true that the name indicates that TLS is a contrast to IPSEC, though. --- tqbf 17:49, 7 January 2008 (UTC)[reply]