Talk:Transport Layer Security/Archive 1

Archive 1

Archive 2

Name of article?

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)

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)

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)

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)

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

Redundant internal links

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)

German English Diagram

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) —Preceding comment was added at 17:45, 31 January 2008 (UTC)

I notice this diagram has now been removed. I thought it was a useful diagram so I corrected it but was unable to upload it. Would anyone like the corrected diagram to be added? Nerwal (talk) 18:10, 7 October 2008 (UTC)

SSL vs. TLS

What's the diff? --lenehey

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

Distinction finally made clear at the end. SSL goes to protocol V3. Subsequent versions are TLS

Terms we use

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)

Backslash?

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)

Security?

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)

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).

What about hardware that could decrypt SSL traffic?

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)

Regarding recent move

Meetabu moved this article from Transport Layer Security to Transport 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)

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)

Inclusion in protocol suite

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?

Incorrect uses

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)

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)

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)

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)

TLS/SSL Interoperability? Differences?

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)

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)

Applications

« 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)

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)

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)

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)

TLS 1.1 section outdated

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)

Server hello done

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)

See Also : Comodo

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

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

---

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

We need a section for laymen

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)

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)

Incorrect external links

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)

Pornography

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)

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

Remove Unreferenced tag

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.

Common misconceptions section?

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

• I was thinking about this as well, but maybe it would be better to add a paragraph in the security section, and discuss how DNS vulnerbilities can be avoided with SSL by doing hostname check or some other post connection check. I have a hard time finding online references about this, though. I know it is discussed in Network Security with OpenSSL by By John Viega, Matt Messier and Pravir Chandra, ISBN: 9780596002701. —Preceding unsigned comment added by 12.130.157.75 (talk) 17:32, 2 October 2008 (UTC)

FAQ?

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

Developer section?

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...

Reference change needed

"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

• Good idea. Stephen Charles Thompson (talk) 20:33, 24 October 2008 (UTC)

Record Layer?

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).

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)

Inconsistency between sections

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)

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)

First sentence of the description

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)

Tables

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)

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)

Is Web SSL certificate server dependable?

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!

Use of SSL and TLS in relation to STARTTLS

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)

Version ambiguity

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)

Transport Layer

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)

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)

tgbf, I don't get your point. Why is TLS an application layer protocol, rather a transport layer protocol? —Preceding unsigned comment added by 84.67.178.127 (talk) 15:08, 9 March 2008 (UTC)

TLS fits at layer 4 or 5 in the OSI model; TCP is at layer 4, IP is at layer 3. The application sits at layer 7. —Preceding unsigned comment added by 161.44.66.190 (talk) 15:06, 30 May 2008 (UTC)

vs Comcast

Comcast blocks all incoming http requests through its traffic shaping, preventing users from running http servers. Does SSL (https) obfuscate the packets in such a way that traffic shaping cannot trivially detect them as http(s) requests? Ham Pastrami (talk) 11:47, 19 February 2008 (UTC)

Yes and no. If someone wanted to filter TLS, they'd just have to look for the handshake. Filtering on the http in HTTPS, on the other hand, would be more difficult. TLS would encrypt the http traffic, obscuring it to the filter. Now, if they're *proxying* that connection... Mmernex (talk) 17:03, 19 February 2008 (UTC)

I think the WP:RD is the place to ask such question, but as far as I'm concerned, it depends if comcast filter the http port (in which case you can run a webserver but not on port 80 and have an url like [1], https wouldn't change anything and in fact might be a blocken port too) or if it filter -http- in general. If it filter http by heuristic methods, it can detect (but it remain unknown if they filter that) the handshake as easely as they can detect the http messages - 70.55.215.234 (talk) 23:54, 29 April 2008 (UTC)

download privacy

i am downloading files from rapidshare in my workplace(a private company).According to the fact that rapidshare uses ssl, can my company's network authorities or the company's isp find out what i am downloading? —Preceding unsigned comment added by Flyer1984 (talk • contribs) 11:06, 12 May 2008 (UTC)

Do you trust the computer you're using? Do you trust the installation of the browser? Did you verify the certificate sent during the connection? SSL connections *can* be proxied, and it's really up to the user to agree the server's certificate is what you think it is. Also see my comment above. Mmernex (talk) 19:12, 12 May 2008 (UTC)

Request for references no longer needed ?

Time to remove Refimprove|date=December 2007 ? It is quite obtrusive & the article seems quite well sourced —Preceding unsigned comment added by 81.2.101.220 (talk) 10:23, 26 July 2008 (UTC)

SSL vs TLS

I went to this page to find out why SSL was renamed to TLS. [[2]] says it was renamed to TLS by the IETF since SSL was trademarked by Netscape. Should this be added to the page? — Preceding unsigned comment added by 195.212.29.94 (talk) 14:21, 13 July 2012 (UTC)

Proposed Move

The formal name of this protocol, as defined by the Internet Engineering Task Force (IETF) and recognized by Internet Assigned Numbers Authority (IANA)[3] is Transport Layer Security Protocol (TLSP). By Wikipedia article naming conventions, this article should be renamed (moved) to the title that best represents its official name. Stephen Charles Thompson (talk) 20:33, 24 October 2008 (UTC)

Nay. I can't find any references to that acronym (nor have I heard it called TLSP). Other protocols such as Secure Shell seem to follow the current format as well. Mmernex (talk) 21:08, 15 June 2009 (UTC)

I have to agree with Mmernexon this one, the move is not justified. RP459 (talk) 21:38, 15 June 2009 (UTC)

I have to disagree too. Even the RFC abstract of TLS ([4]) also refers to TLS as the TLS protocol. Notice the lower case 'p', indicating that it is not part of the acronym. --mgarde (talk) 21:11, 2 December 2009 (UTC)

RC4 and SSL

I realize the answer is most likely very obvious to anyone with minimal knowledge in the field, so I apologize for having to ask this question: How can SSL 3.0 be strong when part of it can be chosen to be based on the weak RC4 scheme? Does that weaken the protocol in any way? -- 24.174.1.66 (talk) 21:46, 24 November 2008 (UTC)

From what I understand from RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4 the problems with WEP is that it uses RC4 in such a way that the weaknesses in RC4 becomes very important. That is using weak key generation and re-using keys. TLS use RC4 in a different way so that the weaknesses doesn't allow a practical attack. But for the long term TLS users should probably switch to AES. JTragardh (talk) 20:16, 30 November 2008 (UTC)

For future reference about questions, please see WP:TP. But yes, RC4 as used by WEP vs. TLS is completely different. But weaknesses to RC4 itself apply to both, obviously. Mmernex (talk) 21:16, 15 June 2009 (UTC)

SSL vs STARTTLS

I believe that there should be a separate page for STARTTLS vs TLS/SSL. STARTTLS uses TLS/SSL but over an existing TCP connection; this distinction is not made in the article. Contrast that with https; the connection is encrypted from the beginning. Please rethink about the redirection to TLS/SSL. A rough analogy is saying any search on petroleum products should be redirected to some page on combustion engine. —Preceding unsigned comment added by 68.164.7.104 (talk) 12:03, 5 December 2008 (UTC)

On a related note; https has its own page even though https uses ssl/tls. In essence this relates to consistency. Everything that uses ssl/tls should point to one page or not. https is http over ssl/tls. The same is true for starttls. Personally starttls and https should have their own distinct web pages and related to ssl/tls. —Preceding unsigned comment added by 68.165.57.239 (talk) 20:13, 7 December 2008 (UTC)

Suggesting a link

I just released a free SSL sniffer, as far as I know there isn't any true free SSL sniffer that isn't a proxy, I'd like to post this link [5], I think it's relevant here (if you disagree on the link or link location let me know ofcourse), I wanted to post this link going via the conventional way. Barakw (talk) 04:54, 6 December 2008 (UTC)

For future reference about questions, please see WP:TP. It may be great software, but a link wouldn't apply to the article. Mmernex (talk) 21:18, 15 June 2009 (UTC)

SSL decrypytion?

On the Skype page/talk page, there is mention that German Security Services had a trojan made so they can intercept. From what I can tell, also mentioned in this paper, was the company that made the trojan sells an SSL decryption service for around 2500 euros.

I know very little about security, so would appreciate if anyone could look into whether this is relevant to this article, and what types of SSL may be 'broken', under what conditions, etc. Thanks. Ceasefyred (talk) 10:51, 31 December 2008 (UTC)

According to the article posted on wikileaks they intercept the voice data before it gets to Skype because they can't break Skype's security. They claim to break SSL using a man-in-the-middle attack but as far as I'm aware that's not possible with the current version of SSL/TLS. Nerwal (talk) 06:46, 8 February 2009 (UTC)

Here is another story that looks relevant:

"SSL broken! Hackers create rogue CA certificate using MD5 collisions" http://blogs.zdnet.com/security/?p=2339

Ceasefyred (talk) 03:54, 1 January 2009 (UTC)

There was a section about the rogue CA hack, but it was just removed on the grounds that the hack wasn't on SSL/TLS itself, but on the Public Key Infrastructure it depends on. Any opinions on whether this should be discussed here and/or in the PKI article? Speaker to Lampposts (talk) 05:58, 3 January 2009 (UTC)

IMO, if mentioned here at all it should only be a brief (one sentence) reference to a more relevant article. Leotohill (talk) 15:57, 3 January 2009 (UTC)

The weakness is in MD5 not SSL or PKI. I agree with Leotohill - a brief mention at most. Nerwal (talk) 06:46, 8 February 2009 (UTC)

The question is where is an appropriate place to write about weaknesses in "the public key infrastructure used to back SSL/TLS". The Public key infrastructure article seems to be about the general concept of a public key infrastructure. The X.509 article seems to be about technical details of the protocol not so much about it's practical deployment. Plugwash (talk) 13:45, 8 August 2013 (UTC)

SSL Implementation: Delphi Indy ?

The article mentions Indy in the Implementation section as is a Delphi library for SLL like OpenSSL. The Article about Indy however says "Indy includes support for OpenSSL[2] and Zlib in the protocol implementations." - so Indy should not be listed as a SSL implementation here.

--89.52.158.48 (talk) 09:46, 17 January 2009 (UTC)

mod_ssl link

I found (IMHO ) a nice introduction into cryptographic terms like Certificate, Digest, Certification Authority and such in the manual of apache's mod_ssl. It ends with an explanation of SSL (which seems to be of the same quality): http://www.modssl.org/docs/2.8/ssl_intro.html —Preceding unsigned comment added by 141.51.95.5 (talk) 12:57, 30 March 2009 (UTC)

Version History, Bit Size

There is no specific treatment of version history. There is no description of bit size. These are basic elements and should be included. Stephen Charles Thompson (talk) 23:27, 27 April 2009 (UTC)

Agreed, please feel free to add to the article... RP459 (talk) 21:39, 15 June 2009 (UTC)

Reorganization

recent edits (moved from private talk page)

TLS and SSL both always reside over a reliable transport, including TCP, per the RFC http://www.ietf.org/rfc/rfc2246.txt. Other variations based on SSL functionality may use UDP, etc., but they should probably be their own article. The TLS article is getting very fat and confusing for an encyclopedic entry. Just my 2¢. Mmernex (talk) 20:03, 16 June 2009 (UTC)

Well, the article could indeed be better organized, I agree. But it should mention that TLS today is not just for reliable transports, true the datagram implementation has its own set of RFCs, but those refer heavily on reliable TLS documents, and only discuss DTLS as a set of differences. A general article on TLS should reflect this. To not get lost in specific RFC citations, I only provided the wikilink to the WP article, but since you are pointing to the TLS RFC (which is outdated, btw) as justification, perhaps the DTLS numbers should be given too. Beyond my edits, indeed the extension uses should be covered in other articles. The article could certainly be streamlined by being much more selective in the choice of protocol examples given, as it could grow indefinitely since almost every protocol these days has been encrypted by some form of TLS. But I objected also to the indiscriminate removal of all lists. TLS is an important and widely used method and the article will be long in any case, which can be handled by proper reorganization. I will see how this can be done (not over night). This can be discussed in article talk with wider audience. Kbrose (talk) 20:26, 16 June 2009 (UTC)

Third Opinion

Is there any reason that both the original RFC implementation, and the current, more permissive usage models can't both be discussed? Dictionaries tend to add new definitions, while retaining even archaic ones. Is there a way to do that here? Jclemens (talk) 16:56, 23 June 2009 (UTC)

=Streamlining of this article

I don't think the exhaustive listing of packet formats and protocol parameters is beneficial at all in this article. Wikipedia's articles are not intended to be a technical reference manual. Furthermore, these diagrams are almost completely out of context and useless without discussion. Entire books have been written on that subject alone. Since this is an important topic with many applications the article could grow large and should focus on the important aspects of reason, history, applications, implications, security. Kbrose (talk) 20:38, 16 June 2009 (UTC)

Streamlining: Another example

The second paragraph digresses into a discussion of browsers, the semantics of server authentication, CAs, PKI, the "locked padlock", browser usage guidelines, etc. These topics pertain to one application (albeit the most common one) of TLS, not to TLS itself. As its name implies, TLS operates at the transport layer. It might better explicate that architecture if the Wikipedia organization was likewise layered, with higher-layer concerns discussed elsewhere (e.g., PKI, CA, or HTTPS topics). If someone feels this application example is needed to motivate the discussion, perhaps it should come later, after TLS has been properly introduced. Ccpearson (talk) 06:29, 6 August 2009 (UTC)

I agree. I moved those paragraphs into a separate section.

I also removed the claim that it is incumbent on the end-user to "cipher something using the public key contained in the certificate and assure that the server can understand it". That is nonsense, as this is already done as part of the protocol: the client sends the session key encrypted with the server's public key. The protocol cannot proceed unless the server is able to decrypt the session key.

I found these two paragraphs suspect, as they cite no sources. I tagged them as "original research" until somebody supplies sources. 142.177.158.103 (talk) 03:32, 20 October 2009 (UTC)

Not only are they unsourced, but I'm fairly certain that the statements made in those paragraphs are wrong for most if not all current implementations (all browsers I'm aware of will fail to authenticate (unless overridden by the user) if the URL does not match the certificate, for example). I would suggest deleting the "Meaning of authentication" section entirely on several grounds:

1. The issues discussed are a general security/PKI question and have nothing specifically to do with TLS itself.
2. The issues and examples used appear to be only talking about web browsers, and thus belong, if anywhere, in the HTTPS article, not in TLS anyway.
3. The text is badly written and (while ostensibly clarifying them) actually confuses the concepts of validation, authentication, and identification and uses the wrong terms in the wrong places.
4. The statements made about web browser behaviors, and thus the implied conclusions about security for users, are, frankly, wrong anyway.

-- Foogod (talk) 19:49, 27 October 2009 (UTC)

Deleted it. --66.168.1.178 (talk) 18:15, 2 December 2009 (UTC)

The Picture of "'SSL handshake with two way authentication with certificates'"

I just want to make a simple comment/suggestion I think that picture could be been made better. It is kind of hard to see and read and i think it could show a little more descriptive. It's kind of hard to get a idea from that picture. 98.117.34.180 (talk) 22:17, 9 November 2009 (UTC)

• One more thing i want to add is that it seem poorly made and should be updated to meet quality standards! 98.117.34.180 (talk) 22:18, 9 November 2009 (UTC)

Lengths vs. Strengths

I recommend that instead of saying "with 1024 and 2048 bit strengths" it should read "bit lengths" since the "strength" of RSA is not predicated upon bit length, the strength of RSA is predicated upon contemporary and developing factoring technologies which may or may not find one bit length to be any "stronger" than another. Fredric Rice (talk) 22:27, 24 February 2010 (UTC)

Non sequitur

"If this is the case, please contact your ISP." What? This makes it sound like the article was copied from a help guide. Who is going to be debugging TLS at this low level and yet needs to be told "contact your ISP if the packets don't exactly match what they should"? Who is to say I'm doing TLS over the internet? Or that I'm using an ISP? Or that I'm not using TLS to secure a atypical medium like serial? I'm going to delete this phrase, hopefully nobody objects. Otherwise, a very nicely written article with great detail. 70.168.62.101 (talk) 06:33, 2 November 2010 (UTC) jgowdy

Is data signed?

Is the application data signed during transport? What I mean is: In case of HTTPS, if I record the transferred file (and headers, if needed), do I have a signature that proves the file was served by that web server (later)? Or is this outside of scope of SSL/TLS? Xerces8 (talk) 18:17, 9 January 2011 (UTC)

Not specifically. The only proof that a client is talking with a particular server is the server's certificate. And even then, it's up to the user to decide whether the certificate is really trusted. Mmernex (talk) 15:12, 12 May 2011 (UTC)

"Symmetric cryptography"?

Within the introduction it states that TLS uses "symmetric cryptography" whereas in the section entitled "Description" it clear demonstrates the use of both a public and private key which is asymmetric cryptography. —Preceding unsigned comment added by 94.2.216.224 (talk) 04:25, 6 May 2011 (UTC)

Like many systems it uses both. Asymetric cryptography is used to establish a shared secret. The shared secret is then used to encrypt the data with symmetric cryptography. Plugwash (talk) 15:17, 2 September 2011 (UTC)

Layer

I wish someone more knowledgeable than me would please address a seeming contradiction in the definition of TLS. Paragraph one says "TLS and SSL encrypt the segments...above the Transport Layer" Immediately below and to the right is an illustration that lists TLS/SSL in, not above, the transport layer. 66.173.66.194 (talk)Thank you. Phil Norcross, webmaster@sdsusa.com —Preceding undated comment added 21:37, 3 June 2011 (UTC).

TLS is in the transport layer to show that it operates in this layer and therefore encrypts information above the transport layer (the application layer, which HTTP is part of) Ercrt (talk) 04:23, 14 June 2011 (UTC)

Functionally speaking TLS is an extra layer sitting between the transport layer provided by TCP and an application layer protocol. Implementation wise at least on *nix it is normally handled by a user level library called by the application (either openssl, gnutls or mozilla nss). Really the whole idea that there are a fixed number of named layers in a network simply does not reflect the way internet protocols are designed. Plugwash (talk) 14:57, 2 September 2011 (UTC)

Somwhere it should be stated

That TLS as typically implemented is only as secure as the least secure CA in the trusted list. Not stating this is a recipie for huge overconfidence in the security of SSL. I'm not sure how best to work this into the article though. Plugwash (talk) 15:17, 2 September 2011 (UTC)

The TLS 1.0 BEAST Edit

Someone added ... "The TLS 1.0-specific BEAST attack can be prevented by removing all CBC ciphers from your list of allowed ciphers—leaving only the RC4 cipher..."

That quote was referenced as a single response to a question in a forum. If OpenSLL and Netscape Security Suite have already fixed the issues many years ago, Why switch to RC4 (quote from wiki "RC4 has weaknesses that argue against its use in new systems")? Also see - http://www.openssl.org/~bodo/tls-cbc.txt Rombust (talk) 13:23, 29 September 2011 (UTC)

Resumed TLS handshake

According to RFC 2246, In Abbreviated(Resumed) Handshake, server sends it's Finished message prior to Client's. Please refer "Fig. 2 - Message flow for an abbreviated handshake". But this article uses the message flow similar to simple(normal) handshake even for resumed handshake. Please either correct the article or correct me. — Preceding unsigned comment added by Thulasi.goriparthi (talk • contribs) 05:09, 15 April 2012 (UTC)

Merger proposal

of Next Protocol Negotiation to here: For: an extension of TLS (scope), article size Against: separate issue? Widefox (talk) 09:34, 28 July 2012 (UTC)

support and no other comments in almost a year, so someone just needs the time to do it. Thanks. W Nowicki (talk) 15:47, 26 May 2013 (UTC)

Privacy vs Confidentiality

While historically the uses of these words were the same, in modern context Privacy refers to information about a person, while confidentiality refers to the secrecy of data. See http://inpropriapersona.com/confidentiality-vs-privacy/ for a good intro, which contains links to other technical and research sources. Based on this, I changed the word "privacy" to "confidentiality" in the first paragraph. 107.60.106.42 (talk) 14:55, 9 August 2012 (UTC)

Unclear references

In the 'Description' section in steps 3. and 6. there are reverences to '(see Server Authentication for details)' and '(see Client Authentication for details)'. It is not quite clear what they refer to. Maybe some links could be added. Petter Ljungqvist (talk) 07:22, 17 August 2012 (UTC)

Agreed - I cam here explicitly looking for details on Server Authentication, it doesn't appear to be addressed in the article, despite the reference in the Description section. — Preceding unsigned comment added by 86.182.158.99 (talk) 11:39, 23 November 2012 (UTC)

"Secure website" redirect

"Secure website" redirects to this article. Would it be more logical to retarget it to HTTP Secure, since "website" implies that HTTP is the application-layer protocol? SoledadKabocha (talk) 15:12, 11 September 2012 (UTC)

Patent

Would it be appropriate to include commentary about SSL patents? For example information from: http://www.forbes.com/sites/andygreenberg/2012/11/09/meet-the-texas-lawyer-suing-hundreds-of-companies-for-using-basic-web-encryption/ Kevink707 (talk) 19:18, 12 November 2012 (UTC)

• I don't know about the US, but I believe that in many countries you get only a few years to develop a patent into a product. If you can't do that, then you can't stop others from developing the idea. Otherwise it surely would have been possible to patent the blue ray laser before it was even invented. LittleBen (talk) 05:30, 13 November 2012 (UTC)

JA3 SSL Fingerprint tracking

WTF?