Talk:Transport Layer Security

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)

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)[1] 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 ([2]) 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 [3], 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)

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)