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

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)

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.