Talk:Transport Layer Security

Authentication Algorithm fields

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)

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

Mail clients

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)

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

GA nomination

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)

• @Falcon Kirtaran: 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)

Dealing with Man in the Middle Attacks

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)

•  Done Noting that Ross Fraser made this change in an edit on 17 March 2019. - Dyork (talk) 19:47, 12 March 2020 (UTC)

Incomprehensible

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)

• @Dagme: 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)

Article split

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)

This needs MUCH more discussion by editors of this article before it is summarily cut up into several ancillary articles. Quite apart from the issues of whether the article is too long (itself debatable), there is the issue of which sections should be moved to their own WP pages. For example, I'm not at all convinced that the very essence of TLS -- its security, which has continued to evolve and change in response to threats -- should be moved into an article with the confusing title "Transport Layer Security Security."

I think there may be a reasonable case to be made for your split off of adoption. It is mostly a long table and the ongoing adoption of various TLS versions by various browser vendors is distinct from TLS itself. I'd like to hear whether other editors think this is a good candidate for splitting off into its own article.

Please discuss proposals here before making more large-scale edits.

Ross Fraser (talk) 05:31, 31 July 2019 (UTC)

I raised this before and no response. So there comes a time to act, otherwise nothing gets done. So will YOU talk put back at least the adoption? As to the article size, see [1]. It is way too big. Tuntable (talk) 01:51, 1 August 2019 (UTC)

I might add that while a general discussion of security is good, a list of every known vulnerability could easily be forked. But I do not really care. Propose a different split up. But do it. Don't just revert other people's contributions. Tuntable (talk) 01:53, 1 August 2019 (UTC)

Well Ross Fraser, I don't see much talk going on. So much easier to revert than to contribute. But if you are going to be a revert artist then do it properly. Fix the duplicated adoption page as listed below. Tuntable (talk) 05:34, 29 August 2019 (UTC)

Transport_Layer_Security_Adoption

I have fixed duplication with Transport Layer Security Adoption. (I changed it to be a redirect and merged in the only relevant edit to that article into this article.) I'm open to discuss this article split, but only if there is a proper discussion and no premature contested content moves. Anton.bersh (talk) 08:12, 15 May 2021 (UTC)

JA3 SSL Fingerprint tracking

WTF? — Preceding unsigned comment added by 77.3.172.153 (talk) 13:17, 8 January 2020 (UTC)

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

the word data should include all bits

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)

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

Has anyone considered adding the old 'locked' and 'unlocked' padlock images that show on URLs on some browsers to the main content page?

This might be a useful addition. (Undated and unsigned)

Created new Archive 2 page due to length of this page

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)

update text of deprecated, add date

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

Hi there. If you look at the history timeline and chart, you will see that the last version of the protocol formally known as "Secure Sockets Layer" or "SSL" was SSL 3.0, announced in 1996 and deprecated in 2015. Starting in 1999, the protocol has formally been called "Transport Layer Security" or "TLS".

However, it is very common for people and companies to still talk about "SSL", even now in 2020, although formally that protocol is now called "TLS". There are many code functions and libraries that still have "SSL" in the name (ex. OpenSSL). And some web hosting companies still talk about getting you a "SSL certificate". Even though they all talk about "SSL", the protocol that is actually being used underneath it all is now the TLS protocol. - Dyork (talk) 21:41, 2 June 2020 (UTC)

TLS 1.0 and 1.1 Removal

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)

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)

Blocking obsolete TLS, cypher suites, and key exchange mechanisms

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)

Remove Opera from table of web browsers?

Someone at an IP address removed Opera from the table in the section on web browsers with this edit summary:

remove opera as very minor marketshare, else many other browsers with minor marketshare have to be added.

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)

• Keep - My vote would be to keep Opera listed. While it may be small in market share, I think it is useful to understand the degree of TLS support that it includes. - Dyork (talk) 21:52, 4 February 2021 (UTC)
• Keep – A look at statscounter.com for January 2021 (not very scientific, but fast) shows Opera at 2.62%, above IE (1.95%), but below Edge (7.79%) and Firefox (8.1%). Besides, I dislike hit-and-run deletions (i.e. without discussion). Cheers! — UncleBubba ^{( T @ C )} 22:39, 4 February 2021 (UTC)
• Keep - My vote would be to keep Opera listed as well. It has a small market share, and is it Wikipedia's place to effectively promote certain browsers?
• Keep - A case could be made to delete everything except Chrome, Safari, and Edge, but as UncleBubba points out, deleting a particular browser without specific criteria for exclusion doesn't seem helpful. Plain Text (talk) — Preceding undated comment added 21:54, 19 February 2021 (UTC)

(Comment) Or, we could set (and document clearly) the criteria a browser must meet to be listed. If it's a marketshare threshold, I think the limit would need to be very low, numerically, because 1/10 of 1% on the Internet is still a really big number. Cheers! — UncleBubba ^{( T @ C )} 19:16, 20 February 2021 (UTC)

not contact NirawatPuechpian1123 (talk) 09:35, 9 December 2021 (UTC)

Shorter Intro

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)

• What hidden category are you referring to? (I was not aware there could be hidden categories) - Dyork (talk) 00:37, 22 March 2021 (UTC)

Irrelevant material in History and development

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)

Article is too large, should be split up

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)

• @Anton.bersh: 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)

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

Should Windows SChannel / SSPI be added?

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)

Nearly all on Windows (MS own products) use SCannel, like IE, IIS, (old)Edge, Office etc

So in real data shown in Table reflect the SCannel config not the behavior by IE (excapt some special case in past)

Therefore i would keep it. Maybe next Windows 11 will not contain IE anymore, but SChannel still base of many other stuff.

87.123.164.213 (talk) 12:42, 18 October 2021 (UTC)

Sure, but SChannel is not a "web browser". It's an API, correct? The section it is being added into is a table for web browsers. SChannel is already listed in the section on Libraries, which is more appropriate, in my opinion. - Dyork (talk) 00:23, 19 October 2021 (UTC)

• I will note that I reverted the reversion of my change as an IP editor was again adding the SChannel text back into the table about web browsers when SChannel is not a web browser and is already listed in the table of libraries. Hopefully between this note here and my long edit summary for the revert, the editor will understand that SChannel is already listed in the article and does not need to be in the web browser table. - Dyork (talk) 00:33, 19 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)

The page is broken

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)

Seems to be OK now. ~Kvng (talk) 14:19, 6 November 2021 (UTC)

Layer of operation

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

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)

References

TLS v1.3 new alert code and major spec change

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)

YouTube.Com

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)

Split the Cipher table into three types instead of two

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)

Endianness

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)

Remove the OSI model classification, or clarify the problematic in assigning TLS to a layer

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)

Key exchange or key agreement

Under the heading Algorithms and paragraph Key exchange or key agreement there are a table showing algorithms in SSL/TLS versions.

For almost all of them "No" is shown with a red or grey label, and "Yes" is shown with a Green label. For the two algorithms "DH-ANON" and "ECDH-ANON" the colors are opposite, with Red "Yes" and Green "No". Is there any reason for this, or is this a bug? Currently it is a bit confusing table, and the table below for Cipher is much clearer.

Color change was introduced at 11:31, 22 December 2023, in this revision: https://wiki.riteme.site/w/index.php?title=Transport_Layer_Security&direction=next&oldid=1189958262

@Lionel_Elie_Mamane Gakk (talk) 15:00, 25 November 2024 (UTC)

As per my commit message for that change:

Make TLS 1.3 non-support of insecure ANON variants green (good thing)

The DH-ANON and ECDH-ANON ciphersuites are insecure (subject to MITM attacks) and thus refusing to use them (not supporting them), is a good thing. Lionel Elie Mamane (talk) 15:53, 25 November 2024 (UTC)