Talk:Transport Layer Security

message: Can someone please add Authentication Algorithm section in the Algorithm heading? This's a separate thing which's negotiated during the handshake.  — Preceding unsigned comment added by DE logics (talk • contribs) 04:35, 12 October 2014 (UTC)
replies: text: * Do others believe this is still relevant? If so, anyone want to provide content? I'm assuming the unsigned request was for a new sub-section under Algorithm.  - Dyork (talk) 19:28, 12 March 2020 (UTC)
thread_title:  Authentication Algorithm fields 

message: There should be a table listing email clients and supported ssl/tls versions, similar to the one about browsers.  — Preceding unsigned comment added by 134.106.59.183 (talk) 09:57, 15 October 2014 (UTC)
replies: text: * While I agree such a table could be useful, creating the table and keeping it up to date would involve a LARGE amount of effort. A critical question, too, would be how to scope the number of email clients (although perhaps it could be limited initially to Microsoft Outlook, Apple Mail (for Mac and iOS), Thunderbird, Android mail, and whatever others people add). There would need to be substantial interest from other editors to take this on.  Anyone interested? - Dyork (talk) 19:34, 12 March 2020 (UTC)
thread_title:  Mail clients 

message: I think this would make a good nomination for a GA.  Does anyone have any strong feelings on this?  If not, I'd like to put it forward.  FalconK (talk) 07:56, 7 October 2016 (UTC)
replies: text: *  Are you still interested in nominating this page for GA? Since you asked this question in 2016, there were not any responses one way or the other. I have not personally been involved with a GA nomination and so don't have an opinion yet. - Dyork (talk) 19:38, 12 March 2020 (UTC)
thread_title:  GA nomination 

message: This subsection was always of tenuous value.  I note that another editor has now deleted the sub-subsection on DNS Chaining.  This leaves two sub-subsections: Certificate Pinning and the Perspectives Project.  The former mechanism was deprecated by the Google Chrome team in late 2017 because of its complexity and dangerous side-effects. The text really doesn't tell the reader anything useful about TLS (thought there is a WP article on it that can be linked to under See Also).  The latter (Perspectives) hasn't gone anywhere since it was tentatively introduced circa 2014. 
I'm hesitant to delete the "Dealing with Man-in-the-Middle Attacks subsection without further feedback, but it may be time to ask:  is it time to delete this subsection?  It doesn't really give the reader any useful information about contemporary TLS and its historical value is rather picayune (though the "See also" link to certificate pinning could be important to ensure comprehensive coverage).
Ross Fraser (talk) 01:17, 31 January 2019 (UTC)
replies: text: *  Noting that Ross Fraser made this change in an edit on 17 March 2019. - Dyork (talk) 19:47, 12 March 2020 (UTC)
thread_title:  Dealing with Man in the Middle Attacks 

message: This article is incomprehensible. I don't see how any nonspecialist can understand it.
If you don't already know what this is, you won't find out here. ---Dagme (talk) 02:32, 11 April 2019 (UTC)
replies: text: *  I do agree that this text is very dense. Do you have any suggestions for making it easier to understand? - Dyork (talk) 19:52, 12 March 2020 (UTC)
thread_title:  Incomprehensible 

message: WTF?  — Preceding unsigned comment added by 77.3.172.153 (talk) 13:17, 8 January 2020 (UTC)
replies: text: * Given that this is a comment from an unsigned IP, it's hard to find out exactly what they think should be added. I had to do a web search on "JA3" and I see that it seems to refer to this technique: TLS Fingerprinting with JA3 and JA3S. There is also ja3er.com that is "a project about collecting and sharing JA3 hashes." There is also GitHub repo with a sample implementation. As best I understand this after quickly skimming the article, I gather that the fingerprinting would allow an IT team to potentially identify connections from malware applications, even without being able to decrypt the actual TLS connection. It seems to me, though, that this could also have privacy ramifications.  Perhaps it might make sense to have a new sub-section about Fingerprinting under Transport_Layer_Security#Security Security or Transport_Layer_Security#Attacks_against_TLS/SSL Attacks_against_TLS/SSL. Clearly some sources need to be found that explain this mechanism and the ramifications of it. Anyone else have any ideas around this? - Dyork (talk) 21:42, 12 March 2020 (UTC)
thread_title:  JA3 SSL Fingerprint tracking 

message: As this is a network protocol, the word data should include all bits that are physically detectable between the 2 computers.
"The server and client negotiate the details of which encryption algorithm and cryptographic keys to use before the first byte of data is transmitted" refers to an action which is 0 bits of "data". 75.130.143.161 (talk) 20:15, 11 January 2020 (UTC)
replies: text: * I am not sure I understand the concern. I gather the person thinks the use of "data" is inappropriate here, but I'm not sure how they would suggest it be changed. Are they perhaps saying that in truth "data" IS being exchanged in the handshake happening between the server and client? But the "data" used in "the first byte of data" is actually the "payload" of the packet after the TLS handshake has been finalized?  I'm not clear on what exactly they think needs to be fixed here. I suppose I can see a nuance there, but I also think it reads fine as it is. - Dyork (talk) 21:47, 12 March 2020 (UTC)
thread_title:  the word data should include all bits 

message: This Talk page was so long and had so many sections from back in 2012-2015 that it was incredibly difficult to understand what were current issues. Following the WP:ARCHIVE process, Talk:Transport_Layer_Security/Archive_2 is now available and searchable from the header at the top of this page. I moved over most of the Talk content prior to 2019 and retained a few items that seemed to still be open issues. If anyone believes something I archived should still be on this main Talk page, please feel free to move it back. -Dyork (talk) 19:24, 12 March 2020 (UTC)
thread_title:  Created new Archive 2 page due to length of this page 

message: Most web browsers are now removing support for TLS 1.0 and 1.1 because they are not secure. Should the browser history of TLS support table be changed so supporting TLS 1.0 and 1.1 is red instead of green? Herbfur (talk) 21:40, 30 June 2020 (UTC)
replies: text: Hmm... that's a good point about the deprecation of TLS 1.0 and 1.1. I'm not sure changing it to red makes sense, though, given that this is really a historical view of the development, and the point of the chart is to have a historical timeline of whether browsers supported different versions of TLS - and when. I do see that newer versions of browsers now have yellow squares with "Disabled by Default" in them. This seems like perhaps the better approach. Over time we will hopefully see that for all the new releases. - Dyork (talk) 21:20, 2 July 2020 (UTC)
thread_title:  TLS 1.0 and 1.1 Removal 

message: Parking lot - no time to incorporate now, but NSA just provided recommendations on blocking obsolete TLS versions, cypher suites, and key exchange mechanisms to improve security. https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF RookWolf (talk) 14:32, 6 January 2021 (UTC)
thread_title:  Blocking obsolete TLS, cypher suites, and key exchange mechanisms  

message: I have made an attempt to shorten the introduction by moving some of the expansive details to the "description" section.  While the change seems big, the content and detailed information is preserved in the more appropriate section.
Also worth noting: the RFC magic links seem to be cleaned up.  So, it may be a good idea to verify and remove it from that hidden category. ILMostro (talk) 05:46, 21 March 2021 (UTC)
replies: text: * What hidden category are you referring to? (I was not aware there could be hidden categories) - Dyork (talk) 00:37, 22 March 2021 (UTC)
thread_title:  Shorter Intro 

message: Why are SDNS, an obscure corner of the failed OSI project, and SNP, a proposed secure socket API that's more in line with IPsec than TLS, listed as if they were part of the history of SSL?  Neither have anything to do with SSL, or at least more to do with SSL than a dozen other random things that could be thrown in.  
On the other hand it completely omits to mention PCT, which was a direct part of the history of TLS, being one of the major motivating factors for both the creation of TLS and its name.
— Preceding unsigned comment added by 806f0F (talk • contribs) 04:46, 28 March 2021 (UTC)
thread_title:  Irrelevant material in History and development 

message: This article prose is over 300kB long, while WP:LENGTH says that articles over 100 kB "almost certainly should be divided". I propose spliting out section "Applications and adoption" into a separate page (and writing short summaries of these sections here).
This treatment would be consistent with other articles on other protocols: Secure Shell Protocol is separate from Comparison of SSH clients and Comparison of SSH servers; Simple Mail Transfer Protocol is separate from List of mail server software and Comparison of mail servers; Hypertext Transfer Protocol and HTTP/2 are separate from Comparison of web server software; File Transfer Protocol is separate from Comparison of FTP client software and Comparison of FTP server software packages... and many more. Virtually all protocol articles on Wikipedia follow this convention.
There is also a problem of "Security" section being duplicated by Security of Transport Layer Security. I believe the best way forward is to reconcile the two versions into one in this article, then fix it, and move it to a permanent location.
Courtesy ping to  and . 
Anton.bersh (talk) 11:23, 15 May 2021 (UTC)
replies: text: *  I agree that this article is too long, particularly with the very lengthy - but very useful - tables with comparison of TLS implementation in different web browsers and applications. I know people who have been referencing the tables here, particularly for the web browsers, but it does make for an extremely long page. Your proposal makes sense to me. - Dyork (talk) 01:20, 17 May 2021 (UTC)
replies: text: * Just to clarify: I agree that the tables are very useful, I do not propose to alter them in any way. I propose only to move them to dedicated pages for ease of use. Anton.bersh (talk) 09:48, 20 May 2021 (UTC)
thread_title:  Article is too large, should be split up 

message: Who made it look like code in a monospace font at the beginning of the page? 207.81.187.41 (talk) 11:31, 2 November 2021 (UTC)
replies: text: Seems to be OK now. ~Kvng (talk) 14:19, 6 November 2021 (UTC)
thread_title:  The page is broken 

message: The summary states that TLS runs in the applications layer but this seems to have no citation and doesn't seem accurate based on sources I've chanced upon. Other sources I've read describe that TLS technically operates between the transport and application layers but is generally considered a transport layer protocol https://docs.oracle.com/en/java/javase/15/security/transport-layer-security-tls-protocol-overview.html#GUID-83C9697A-35B7-4962-972F-06795E705BE9. It would surprise me if a protocol called "Transport Layer" Security didn't actually operate in the transport layer.
EditorPerson53 (talk) 04:28, 22 November 2021 (UTC)
replies: text: The problem is even harder with the OSI model. This article claims it belongs in the presentation layer, which is debatable. 80.31.41.157 (talk) 14:54, 13 April 2024 (UTC)
thread_title:  Layer of operation 

message: A new alert code `no_application_protocol` was introduced with code 120 or 255
According to TLS v1.3 RFC and it is always fatal like other TLS 1.3 alerts
This article needs to be updated.
"All the alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal and MUST be treated as error alerts when received regardless of the AlertLevel in the message. Unknown Alert types MUST be treated as error alerts. " 4n0nymou2 (talk) 01:16, 27 February 2022 (UTC)
thread_title:  TLS v1.3 new alert code and major spec change 

message: Google.com m.youTube.com and youtube.com  di account private sutrisnaagung466@gmail.com  — Preceding unsigned comment added by 2001:448A:1164:1BED:A4AC:31DC:928F:ACD (talk) 14:55, 11 January 2023 (UTC)
thread_title:  YouTube.Com  

message: The current classification does not align with the TLS protocol inself. Section 6.2.3. of RFC 5246 defines three types:
6.2.3.1. Null or Standard Stream Cipher
6.2.3.2. CBC Block Cipher
6.2.3.3. AEAD Ciphers
The classification in the table is very confusing for readers trying to understand TLS and HTTPS. HTTP/2 and TLS 1.3 forbids ciphers of type block cipher and stream cipher. I suggest moving ChaCha20-Poly1305, GCM and CCM to a third type called AEAD. Coffeevortex (talk) 13:36, 21 April 2023 (UTC)
thread_title:  Split the Cipher table into three types instead of two 

message: In the Protocol Details it describes the bit order for the length as (bits 15-8) (bits 7-0). Is there a precedence in using 'bits' to denote the exponents, rather than establishing that [TCP/IP]/TLS uses big-endian? (The value 02 00 [512] seems like it could be interpreted as 00 20 [32] under the current scheme) ItsSharples (talk) 00:34, 5 February 2024 (UTC)
thread_title:  Endianness 

message: In the TCP/IP model shown in the right bar, TLS appears correctly classified as Application layer. However in the second paragraph of the article it says:
It runs in the presentation layer
This claim is dubious. The problem is that this protocol, as many others (eg.: QUIC) don't fit well in the OSI model. TLS performs encryption, which traditionally has been associated with the presentation layer, but it is not a mere translation of a stream of data provided by the previous layer. In particular, TLS also does a handshake and negotiates the maintenance and termination of a secure connection between two points. This can be seen as belonging in the session layer (layer 5).
I recommend entirely avoiding the OSI model classification in this article. 80.31.41.157 (talk) 14:51, 13 April 2024 (UTC)
thread_title:  Remove the OSI model classification, or clarify the problematic in assigning TLS to a layer