This is the
talk page for discussing improvements to the
Transport Layer Security article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1, 2 |
This
level-5 vital article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
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)
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)
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)
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)
I note another editor has edited the "Perspectives Project" write-up into the past tense, as this project no longer exists. As per my comments above, I think it's time to delete the whole "Dealing with Man in the Middle Attacks" subsection and replace it with a link under "See also" to Certificate Pinning (i.e., HTTP Public Key Pinning). Unless anyone objects here, I'll delete the section in another week or two. Ross Fraser ( talk) 00:29, 12 February 2019 (UTC)
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)
The article was and remains far too long. I have split it up a bit but more could be done. Tuntable ( talk) 01:18, 31 July 2019 (UTC)
WTF? — Preceding unsigned comment added by 77.3.172.153 ( talk) 13:17, 8 January 2020 (UTC)
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)
This might be a useful addition. (Undated and unsigned)
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)
"now-deprecated predecessor" I need know, when deprecation start. Add year of date or full date this event. In php documentation i not found lot informations. Only, start-tls working from php7. But php7 is actual version! (not old as php3, php4, php5). This is mystify magic, create function for php7, and next day is deprecated? :) https://www.php.net/manual/en/function.ldap-start-tls.php — Preceding unsigned comment added by 2001:718:2601:258:4DBC:3838:5A25:F2E0 ( talk) 07:14, 2 June 2020 (UTC)
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)
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)
Someone at an IP address removed Opera from the table in the section on web browsers with this edit summary:
As that is a rather large change, and there would also be changes needed in the supporting text, I have reverted this change for the moment and am asking here. Do editors agree that Opera should be removed from the table of web browsers with support for TLS? (Please comment with 'Keep'/'Remove') - Dyork ( talk) 21:52, 4 February 2021 (UTC)
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)
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)
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 @ Tuntable: and @ Ross Fraser:.
Anton.bersh ( talk) 11:23, 15 May 2021 (UTC)
Question for editors who work with Microsoft Windows - should something be added to this article about TLS support in "SChannel / SSPI" in addition to IE?
On 17 Oct 2021, an IP editor added a reference to 'SChannel' near the Internet Explorer references. The reference pointed over to Security Support Provider Interface. The editor said in their summary "(Add info about SChannel to highlight that these infos are not related to browsers only)."
I reverted the change because the link was added to areas specifically about web browsers and so didn't make sense to me. I don't use Microsoft Windows nor know much about its recent interfaces.. but would it make sense to add something about SChannel / SSPI to this article? I defer to those editors who know more about Windows. - Dyork ( talk) 23:24, 17 October 2021 (UTC)
If no API should be inside, whole Android Section would need to be removed too. 87.123.175.26 ( talk) 10:34, 19 October 2021 (UTC)
I think the word "SChannel" should be explained. "Support for TLS 1.3 was first added to Schannel with Windows 11 and Windows Server 2022.[44]" — Preceding unsigned comment added by 195.93.192.193 ( talk) 13:32, 6 September 2022 (UTC)
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)
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 [1]. 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)
References
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)
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)
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)
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)
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)