Talk:Transport Layer Security/Archive 2

Archive 1

Archive 2

Chrome 67 citation needed for TLS 1.3 support

Information can be found here: https://www.chromium.org/Home/tls13

2003:CD:E701:9374:1938:3CD6:3918:151F (talk) 17:29, 18 August 2018 (UTC)

Firefox Update

I read that this page refers to Firefox v2, a really old release, thus it is not appropriate to give information about security response as if this would be the latest. I suggest an "upgrade". — Preceding unsigned comment added by 151.88.22.12 (talk) 08:59, 28 November 2012 (UTC)

The page says Firefox 2– , so all version 2 and newer, which includes the current (as of Feb 2013, version 19) Widefox; talk 23:07, 26 February 2013 (UTC)

MTM vulnerability?

How do products like Websense manage to subvert TLS by intercepting and scanning traffic when acting as an explicit internet proxy server? Might be worth expanding the article to explain how this is possible. Socrates2008 (Talk) 04:55, 23 January 2013 (UTC)

Normally this sort of thing is used in corporate/instituional environments where the entity controlling the filter also controls the end systems. That means they can install their own CA certificate on the end systems and then use that CA certificate to generate certificates for any site they like. If an end user connects using an end system that is outside the administrative control of the corp/institution and therefore does not have the CA certificate installed they will get a certificate warning (which they can choose to either heed or ignore). Plugwash (talk) 14:00, 8 August 2013 (UTC)

Different Levels of Some Technical Articles

I commend the author of this article on its thoroughness. However, I feel Wikipedia would benefit by having perhaps 2 levels for its technical articles: Novice & Expert. For instance, I wanted a brief, non-technical explanation of Transport Layer Security. I understand that there has to be some technical jargon. But when I run across an article like this, I come away feeling frustrated, because the depth of the article is over my head. Wikipedia often does such a good job at simple explanations of complicated things. I feel that a site-wide policy of having two levels of articles (where applicable, of course) would benefit everyone. Hope I explained myself clearly. spectrekitty (talk) 23:04, 24 January 2013 (UTC)

Which technical jargon is hard to understand? Daniel.Cardenas (talk) 02:37, 25 January 2013 (UTC)

Dear spectrekitty and every other human: please edit this and other articles to make them easier for people to understand, both here at the main English Wikipedia and also at the Simple English Wikipedia.

I agree that Wikipedia would benefit by having a site-wide guideline of having 2 levels for its technical articles:

Every article should begin with a brief, non-technical explanation up front. When we haven't yet figured out how to explain certain details without technical jargon, that jargon should come much later in the article.

Let us call this guideline the Wikipedia:Make technical articles understandable guideline.

--DavidCary (talk) 17:18, 27 December 2013 (UTC)

Firefox TLS

(moved from my talk page Widefox; talk 19:14, 26 February 2013 (UTC)) Hiya. TLS 1.1 is implemented in the current Fx release build. To quote from [1]: "NSS 3.14 has TLS 1.1 support (see bug 565047 comment 118) which is included in the current Fx 19 Beta". We're on Fx 19 as the release version as of writing.[2] makes it clear that Fx 18 used 3.14.1, but the sources that were cited already establish this. I don't know where you're getting your information from, but it's clearly not these sources or MXR. -Rushyo^Talk 19:00, 26 February 2013 (UTC)

Hi, I think you're not only mistaken but as interpretation is required to understand the bug record (and the last comment is incorrect that it is implemented in FF 19 - check for yourself - there's no GUI checkbox for TLS 1.1 in >Advanced > Encryption as stated in that bug, and the bug is not marked closed) - so the situation is as I've just added to TLS article, with the explanation in the notes and edit summary. If you check the FF 19 rel notes you'll see no TLS 1.1 announcement which would be a WP:RS, this is all WP:OR currently. Widefox; talk 19:07, 26 February 2013 (UTC)

Perhaps it would help to clarify that bug 733647 only refers to implementing TLS 1.1 (in Gecko) by default. Bug 565047 covers the implementation of TLS 1.1 RESOLVED FIXED and pushed out in the libraries used in Fx 18. -Rushyo ^Talk 19:02, 26 February 2013 (UTC)

565047 is just that NSS has 1.1. Chrome has been using it for a while now. Still not done in FF I'm afraid. Believe me, there will be announcements when done. Widefox; talk 19:14, 26 February 2013 (UTC)

Something does not need to be in the release notes, nor user accessible, to be considered implemented. For example, add-ons have access to the public interface of the NSS libraries. Just because something isn't user accessible doesn't mean it's not implemented. I've made changes to Fx that didn't go in the release notes and aren't user visible, but they're definitely implemented. Now if we were asking whether it's usable by a typical end-user then no, it's not. But is that what we're actually asking? I don't believe so. Addendum: If we are, then, say, 95% (completely arbitrary figure) of the code base can't be considered implemented. -Rushyo ^Talk 19:16, 26 February 2013 (UTC)

Find a WP:RS for this and then add it. Two separate questions: 1. what makes you think it is implemented in FF (and which version) 2. do you have a WP:RS ? This is WP:OR and WP:SYN and not even factually correct - have you even tried testing FF to see if it connects with TLS 1.1 ? Widefox; talk 19:54, 26 February 2013 (UTC)

There's a better website but I don't have access to the URL this minute... but this will show you FF is using TLS 1.0 [3], use another browser and it will show TLS 1.1 (e.g. Chrome). I tested with FF 19 (and 64-bit "22.0a1 (2013-02-26)" nightly) both on W 7.Widefox; talk 20:34, 26 February 2013 (UTC)

It looks like the Firefox implementation is coming on, and now it may be best described as {{some}}, as it looks like it would create problems if turned on (which is why it isn't by default). Widefox; talk 17:05, 15 June 2013 (UTC)

The development versions like Chrome 29 (dev) and Firefox (nightly or whatever versions the new TLS 1.2 implementation are in) shouldn't really be listed in the table as supported versions, but I kept them in greyed out. Details are likely to change (e.g. the Chrome TLS 1.1 backout) / version numbers slip / PCs catch fire etc. Widefox; talk 13:59, 2 July 2013 (UTC)

Update: Chrome 29 is beta, and Firefox Aurora still has TLS 1.1 and 1.2 support. My WP:OR - TLS 1.2 is still in my Aurora 24.0a2 (2013-07-17), so did they just back it out of the beta or release? "some" carries the jist of it - it may come and go, but some support is in there (although yes, not this minute of course) - it was implemented, and so users can use it, backing out was similar to Chrome 21 - we can mention it as it's out there. That's the problem including these dev versions - more work to keep up, and WP:OR needed. The chrome beta and IE preview releases are notable, and refs can at least be found for the former. Widefox; talk 11:59, 17 July 2013 (UTC)

As far as I know, Firefox 19-22 have no way to enable TLS 1.1 even though backend NSS 3.14.x library supports TLS 1.1, because they have only security.enable_ssl3 (for SSL 3.0) and security.enable_tls (for TLS 1.0) prefs. Only Firefox 23 and above have security.tls.version.(min,max) and can enable TLS 1.1/1.2 (Bug 733632 and Bug 733642, changeset 128472:04dbe811e4a0 checked in mozilla23 on Apr 11 2013). --113.38.82.142 (talk) 03:04, 11 August 2013 (UTC)

TLS - need a ref for this, plus is it just 8.1 or also W7? and are they off by default?)

(Moved from my talk page - please sign your talk page comments) No ref yet. I am just testing preview and noticed that it eventually turned on. It is ON by default without any conditions. IE11 is only for W8.1, so there it is not applicable for W7 or W8. Only W8.1 (unsigned comment by User:Chaliy 08:02, 6 July 2013)

We need a source to include this, else your experience counts as WP:OR and is not included. Also, see IE 11 (http://www.engadget.com/2013/06/26/microsoft-internet-explorer-11/) where IE 11 is reportedly coming to W7, hence my querying if just limted to Windows 8.1. I will add a dubious tag until you find a reference. Widefox; talk 12:38, 6 July 2013 (UTC)

There are many references on Twitter and answers.microsoft.com but from Googling, no official word yet. This policy appears to be in Windows 8.1 Preview client, but has not spread to the Windows Server 2012 R2 preview, from a Google bug report I saw. In many ways, we can't talk about IE 11 yet on this page -- not because it won't become default *at some point if not now* but because it's still a Preview, and TLS is a low-level enough standard that it might not change on different platforms, even though IE 11 will be supported on Windows 7. It's possible this change might only apply to 8.1 for easier support costs in enterprises? --Louis St-Amour — Preceding unsigned comment added by 76.9.199.178 (talk) 18:11, 11 July 2013 (UTC)

Twitter can not be used as a reliable source (RS), and probably not the forum answers.microsoft.com (WP:UGC). We can include anything covered by a RS. Everything else is WP:OR. Widefox; talk 08:45, 27 July 2013 (UTC)

Wikipedia and SSL use

Has anybody wonder, why does Wikipedia and all its related sites not using SSL/HTTPS protocol? Maybe this question is not to be put together with this article, but I believe this is a major security deficiency. Without any effort passwords can be read in plain text for example in a internet caffee. --waxi _Count. 17:03, 21 March 2013 (UTC)

It does Wikipedia:Secure server. You can login (and edit) using HTTPS - Help:Logging in. Additional info at Wikipedia:User account security. (FYI, as of today, it is TLS 1.0, with no 1.1 or 1.2) Widefox; talk 16:21, 22 March 2013 (UTC)

I see WP servers now just been upgraded to TLS 1.2 support (but still using RC4 128/SHA1/RSA). Widefox; talk 17:43, 30 July 2013 (UTC)

Client authentication

Is there an explanation of what "client authentication" means?--Nowa (talk) 14:01, 19 May 2013 (UTC)

I added link to Mutual authentication. Widefox; talk 14:51, 19 May 2013 (UTC)

Super. Thanks. This is the part I'm still confused about:

The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.

What is a "signature over the previous handshake messages"? How is the "signature" "verified"?--Nowa (talk) 16:28, 19 May 2013 (UTC)

Could someone please update the article to make it less confusing? I think I understand what it means, but I'm having difficulty putting it into words that don't violate the "Wikipedia:Make technical articles understandable" guideline.

Summary:

It's the system described in article "digital signature", involving a "signing algorithm" and a "verification algorithm".

Details:

In Basic TLS, a certificate authority uses the signing algorithm to generate a signature inside the Certificate message that (possibly years later) the server ("Sam") sends to the client ("Chuck").

In Client-authenticated TLS, a certificate authority uses the same signing algorithm to generate a signature inside the Certificate message that (possibly years later) Chuck sends to Sam; and Chuck uses the same signing algorithm again to generate a signature inside the CertificateVerify message that Chuck sends to Sam.

In Basic TLS, Chuck uses the verification algorithm to verify that the Certificate message that Sam sends to Chuck originally came from a certificate authority that Chuck trusts.

In Client-authenticated TLS, Sam uses the same verification algorithm to verify that the Certificate message that Chuck sends to Sam originally came from a certificate authority that Sam trusts; and Sam uses the same verification algorithm again to verify the signature inside the CertificateVerify message that Chuck sends to Sam.

The "signature over the previous handshake messages" means that both the client ("Chuck") and the server ("Sam") store the handshake messages as a big block of data in some file or buffer. Then Chuck calculates a digital signature value from that block of data and from Chuck's own secret private key. Then Chuck sends that digital signature value (as part of a CertificateVerify message) to Sam.

The "This signature can be verified" sentence is unnecessarily confusing. It is alluding to the process where Sam extracts Chuck's public key from Chuck's Certificate message, Sam also extracts the new digital signature value from the CertificateVerify message that Chuck sent, and uses those two values -- plus her own local copy of the big block of data -- to "verify the the signature" using the digital signature verification algorithm described in the digital signature article.

Is there some way to summarize all this in a way that (a) is easier to understand and at least as accurate as the current text, but (b) doesn't require repeating the entire digital signature article all over again inside this article?

Nowa, if you ever figure this out, please update the article to make it less confusing for the next person, OK? --DavidCary (talk) 18:02, 17 January 2014 (UTC)

I'll give it a shot.--Nowa (talk) 22:08, 17 January 2014 (UTC)

Perfect forward secrecy

I've added a new (sub)section on perfect forward secrecy. In light of the current stories about the NSA, there is much confusion in the media and online about what can and cannot be done with an intercepted https-protected browser session. Editors are encouraged to expand this section with well-sourced information -- as opposed to the wild or technically inaccurate speculation currently found online! Ross Fraser (talk) 00:09, 14 June 2013 (UTC)

I note that several attempts have been made to edit this section by merely removing text -- leaving the remaining text to give the reader the impression that either TLS already has forward perfect security or that it is trivial to obtain it. Neither is the case. While I welcome additions to this section by all editors, it is not OK to merely delete text and credible references if it misleads the reader. Ross Fraser (talk) 03:17, 9 July 2013 (UTC)

Please see http://gnutls.org/manual/html_node/Priority-Strings.html for evidence that GnuTLS can do perfect forward secrecy. Jesse Viviano (talk) 06:28, 10 July 2013 (UTC)

I figured that removal of bad information would be as good as trying to list all of the TLS suites that can do PFS, which would be incomplete at best. I don't have the time to do the latter. Jesse Viviano (talk) 06:35, 10 July 2013 (UTC)

Thanks for the feedback. I've modified the text to clarify the point that while many TLS software suites are capable of implementing PFS (I previously noted for example that OpenSSL can), they do not do so by default and must be configured to do so during implementation. For example, in the GnuTLS suite, it isn't clear from Table 6.2 that DHE-RSA will take precedence over RSA unless the allowable key-exchange algorithms are expressly configured this way.

The following article picks up on this issue: http://www.theregister.co.uk/2013/06/26/ssl_forward_secrecy/ Interestingly, the article is dated after the inclusion of PFS in this WP article. I also added a link to this article from Qualys SSL Labs: https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy Ross Fraser (talk) 08:53, 10 July 2013 (UTC)

Coming browsers support for TLS 1.1 and 1.2

See above #Firefox TLS. Widefox; talk 12:42, 6 July 2013 (UTC) (now continued here...)

Hi Widefox

I'm responding to your message on my talk page, I believe you undid my edit on the TLS page earlier. I'm using the latest version of Safari on OS X 10.8.4. Even on the most up to date version of OS X it appears that Safari only can connect over TLS 1.0, and does not have support for TLS 1.1 or 1.2. Here's a quick rundown of some tests.

As I listed in my note, some research using an SSL/TLS test suite such as https://cc.dcsec.uni-hannover.de/ highlights that this is definitely the case. Chrome has had support for TLS 1.1 since Chrome 22, and as such a quick check of that test site with the current version of Chrome 28 displays the following; it connects via TLS 1.1, and you get the following readout on the site:

"This connection uses TLSv1.1 with DHE-RSA-CAMELLIA256-SHA and a 256 Bit key for encryption."

This comes at an opportune time for testing as TLS 1.2 support appears in the next version of Chrome. A quick check of this same TLS test suite using Chrome Canary and, as well as Chrome displaying in the info box that it connects via TLS 1.2, you get the following readout on the site:

"This connection uses TLSv1.2 with DHE-RSA-AES256-SHA and a 256 Bit key for encryption."

Following this and the results learned, the obvious next thing to do was to test Safari. Safari 6.0.5 on OS X 10.8.4 on my MacBook Pro. The readout on the site is:

"This connection uses TLSv1 with AES128-SHA and a 128 Bit key for encryption."

This pretty much confirms that Safari does not have TLS 1.1 or 1.2 support.

There may be some TLS related functions in OS X, but they are not used in Safari. All in all, this makes sense. Safari is in dire need of some major work, which is sad but true, and it wouldn't make sense if out of all the major browsers Safari was the only one to currently support TLS 1.1 and 1.2. Apple would also understandably make a point of its 1.2 support on the Safari page on the Apple website, but they don't, they just say Safari supports TLS (1.0).

I didn't make the edit lightly or on a whim, I did it because I had discovered without doubt that the most up to date version of Safari does not support TLS 1.1 or 1.2. I understand you didn't undo my edit for any bad reasons. And it's good that you care to moderate over these things. Hope this clears things up.

Thanks, YL — Preceding unsigned comment added by Yellow Lilt (talk • contribs) 01:23, 18 July 2013 (UTC)

From the (not very WP:RS) references) [4] [5] , we know SecureTransport in 10.8 supports 1.2 and 1.1, and seems it will try to default connect using 1.2 and fallback. Safari may only be using kTLSProtocol1 per [6] ?. We know on iOS Safari support for 1.2 is well documented [7] etc. Safari on OS X may have problems [8]. Try again with [9]. I marked as an issue in the meantime. I can't see any WP:RS yet. The Qualys SSL report simulates Safari 5.1.9 connecting with TLS 1.0 not 1.1 or 1.2 - that doesn't specify which version of OS it is simulating so doesn't help with 10.8, but at least it gives us a reference for Safari 5.x not supporting 1.1 or 1.2. It all looks consistent with your findings now. There's an open question at [10] Widefox; talk 11:21, 18 July 2013 (UTC)

---

Hi again,

I think the TLS page should be changed back to my edit. As it stands according to test suites and all other information available it is clear that the most up-to-date version of Safari (6.0.5) 100% does not support TLS 1.1 or 1.2.

I have also just done some further research to confirm even more.

There is another TLS test site alongside https://cc.dcsec.uni-hannover.de/, called https://sni.velox.ch/. On this TLS test suite the exact same results come back: Chrome 28 (which supports 1.1) connecting to the site using TLS 1.1. Chrome 29 (which supports 1.2) connecting to the site using TLS 1.2. Safari connecting to the site using TLS 1.0.

Regardless of any underlying OS X features Safari itself does not use TLS 1.1 or 1.2. Just like HTML5Test is for HTML5 browser support, this is a credible source. It may not be a tangible document on the Apple website but results don't lie, and they're easy to test. Based on all information reflecting the exact same I think this is open and shut.

YL

Yellow Lilt (talk) 03:11, 19 July 2013 (UTC)

Please double check the article - it says this for OS X. iOS is different. The rest of your edit [11] goes against the iOS source, and breaks the logic of the version numbers. Widefox; talk 06:15, 19 July 2013 (UTC)

Secure

Ross Fraser I'm leaning on you for your advice "AES GCM suites are now the only truly secure option in TLS" [12]. Unfortunately, our table Website protocol support details the level of "secure". Seems to me that we can use this ref there to say only TLS 1.1, 1.2 AES GCM is secure (with compression off). That ref could also be used to (part) fix the {{cn}} at Transport Layer Security#Dealing with RC4 and BEAST. Opinion? Maybe splitting off the secure aspect from the website table would simplify so we can put the focus on the security of the ciphers (rather than mixing adoption with different ciphers) ? Widefox; talk 11:27, 30 July 2013 (UTC)

Using that logic, we would have to mark all of the AES ciphers as weak because all versions of AES have been broken, but the breaks are infeasible. 3DES provides 112 or 113 bits of security but uses a 168-bit key depending on whether or not you consider that third round a single bit of security or not due to the meet in the middle attack that sinks double DES, so it too would be marked as weak and academically broken. Anyways, CBC in TLS 1.1 and 1.2 is apparently properly used with no breaks against this implementation, and we have nothing to indicate that CBC mode has been broken, so CBC mode must be marked as secure unless the block cipher being used is broken, the mode itself is broken, or a break that attacks a misuse of this mode. Jesse Viviano (talk) 11:25, 31 July 2013 (UTC)

The cipher table is good, just needs some refs to support it. That's one of the reasons I split the website adoption from the ciphers as the info comes from one ref so we don't do synergy. The ref [13] details % of sites with weak or insecure ciphers. I've resisted putting in (we already have a lot of now information) but it maybe should go to the right of the protocol support table to show adoption and link the two tables. Widefox; talk 14:42, 31 July 2013 (UTC)

Re: "we have nothing to indicate that CBC mode has been broken": FYI, the Lucky 13 attack weakens all of the CBC implementations in TLS 1.1 and 1.2, regardless of cipher chosen. Fortunately, Lucky 13 isn't as viable an attack strategy as RC4 -- yet. See http://arstechnica.com/security/2013/02/lucky-thirteen-attack-snarfs-cookies-protected-by-ssl-encryption/ for a good description. Ross Fraser (talk) 07:51, 1 August 2013 (UTC)

I'm flattered that you should lean on me but warn that I'm a rickety support at best! I've added your suggested reference to the Transport Layer Security#Dealing with RC4 and BEAST subsection to deal with the {{cn}} and tried to rearrange the whole TLS security section to make it easier for the reader to follow. As for the table Website protocol support, I'm always worried when the word "secure" is bandied about. Secure for what purpose? If "secure" is to be interepreted as "reasonably secure for the moment, if you aren't running from the NSA", then the table is probably OK as it is. The RC4 attack is still a bit conjectural, as the number of encryptions needed to reliably recover a set of 16 consecutive targeted plaintext bytes is around 10⋅2^30, so you are safe from your common or garden variety hacker. But once an attack is discovered, it tends to be improved upon over time, so this may need revision in the not-too-distant future.

As for your suggestion of perhaps focusing on the security of the ciphers, I'm worried that this might not mislead the readers into thinking it was all about the cipher suite chosen: for example, the excellent trustworthyinternet.org/ssl-pulse web site you mention shows that 8% of web sites still allow renegotiation attacks. And your choice of cipher won't help if an attacker can renegotiate you back down to an earlier insecure protocol.

Let me know what you think, but I'd suggest leaving the table as is until future credible references can support deprecating some of the blocks now marked in green from the point of view of, say, a reader worried about online banking. What I think is currently missing from the article is an overall sense that TLS is the subject of active security research and that both TLS attacks and counter-defences are evolving (as opposed to the current text and table that implies "if you choose version x with protocol y then you are safe"). I'm not at all sure how best to convey this. Ross Fraser (talk) 01:25, 1 August 2013 (UTC)

Yes, you both have improved it a lot. Jesse put in the renegotiation flaw. Can we agree on SSL 3.0 (being Weak rather than Insecure/Broken) and also the wording "Insecure" or "Broken" - as I've kept the rating and wording to the source - we're talking about implementations in websites and browsers which they rate as yellow. lucky13 still needs to go in, but how do we boil down the rating - "Secure" (my preference), "Weak", or other say "Less secure"? Widefox; talk 12:48, 1 August 2013 (UTC)

In relation to a protocol, I think "broken" should only be used if the protocol doesn't work under certain circumstances (e.g., hangs the browser in an infinite loop). The problem with SSL 3 is that it isn't broken: many hundreds of thousands of people use it every day and browser vendors are happy to accommodate them. If it were truly broken (i.e., didn't work at all), we wouldn't need to discuss it further. "Deprecated" is the proper term to refer to a superannuated standard but neither the IETF nor ISO will ever deprecate SSL because it isn't one of their standards. "Less secure" doesn't really inform the reader (less secure than what? an earlier version? doesn't that go without saying? otherwise why introduce the new version?). "Insecure" is probably the best term to use here -- i.e., the protocol version fails to meet its security objectives. "Weak" also usefully points out that the protocol version does not meet its security objectives under certain conditions. Ross Fraser (talk) 18:45, 1 August 2013 (UTC)

Broken should be used in case someone can reliably extract complete information out of a session without caring what conditions were used to break it, and that nothing can be done to patch it reliably. BEAST breaks SSL and TLS when there is active content making mulitple sessions to the server. The renegotiation flaw permits a MITM attack against SSL itself that cannot be patched without making the implementation noncompliant to SSL 3.0. The Lucky 13 attack apparently can be defeated without violating TLS. Jesse Viviano (talk) 02:52, 2 August 2013 (UTC)

 Done for the ciphers too. Now that leaves lucky13 still missing as a note which when added leaves the CBCs in TLS 1.1, 1.2 as Secure rather than Weak, agreed? Widefox; talk 19:58, 1 August 2013 (UTC)

Defending the green squares for TLS 1.1 and 1.2 may be something of a losing battle... I've added text to the security section to describe the truncation attack and the BREACH attack (fresh from the Black Hat conference this week). Neither has a known mitigation, though the exploits are somewhat limited. As I noted above, I worry when the word "secure" is bandied about. While there are a rich collection of citations to support the "insecure" and "weak" squares, I can't find a credible source that would, as of August 2, 2013, say "despite all the newly discovered attacks and the outstanding problems, TLS 1.1 and !.2 are secure". Yet the reader is led to interpret the green "Secure" squares as "everything is OK if some stuff in the notes is taken care of by web designers and browser developers". Do we keep adding qualifying notes? Do we change the text to "Secure(?)" with a question mark? "Partially secure?" Ross Fraser (talk) 20:17, 2 August 2013 (UTC)

BREACH is a nice attack, but it does not attack TLS by itself and is probably not going to be used except by possibly APTs. It attacks a combination of factors: HTTP compression is on, and the victim is infected with malware. Most miscreants will probably not have the patience for BREACH to work. This attack can be disabled by disabling HTTP compression. By the way, could someone please put something about the BREACH attack into HTTP compression and this article? I don't know enough to do it myself. Jesse Viviano (talk) 03:41, 3 August 2013 (UTC)

BREACH is indeed beautifully crafted. FYI, it doesn't require that the victim's computer be infected with malware; only that the attacker be a man-in-the-middle. Ditto, the truncation attack, which is potentially even more serious and a direct attack on the protocol. As you requested, I have added text to the HTTP compression article. Ross Fraser (talk) 08:25, 3 August 2013 (UTC)

I'd vote to mark all CBC ciphers as "depends on mitigations", given than now we have a normative reference (https://tools.ietf.org/html/rfc7366) that says it's not possible to mitigate the timing channel completely in Mac-then-encrypt construction. Tomato86 (talk) 18:19, 24 November 2014 (UTC)

If someone has to not comply with a protocol to make it weakly secure instead of completely broken, doesn't it mean that the protocol is broken? The renegotiation vulnerability can easily lead to a MITM attack that is much easier to break than using BEAST, which requires that the server be compromised to serve active content that allows BEAST to work. If we have to use the fixes in RFC 5746 in SSL 3.0, we get some strange hybrid of SSL 3.0 and TLS which isn't SSL 3.0. Jesse Viviano (talk) 02:32, 2 August 2013 (UTC)

I agree with your factual analysis of the situation, I just would avoid "broken" as it implies it doesn't work (for example can't connect). Breaking the encryption is different from the protocol being broken (the protocol security has been broken). Insecure covers it well. It works (not broken) but is insecure, just like not using TLS/SSL (but with a false sense of security). ..OK, this is all WP:OR. We need sources. I'm just trying to keep it to the source, which uses yellow for SSL 3.0, which I agree is a fair assessment based on the implementations preventing a downgrade attack. It would be fair to say SSL 3.0 is Insecure itself, but the table is about SSL 3.0 implementations in use which use (if actually done) use a modification of the protocol, hence the note. That way we keep to the source. Can we also keep the table small by not doubling the note.Widefox; talk 16:54, 2 August 2013 (UTC)

[14] restates TLS 1.2 GCM is a green.

The two listings of SSL 3.0 in the cipher table should be reduced to one, or at least put in the protocol table. The cipher one is too wide, I suggest reducing the font size for now. Widefox; talk 12:38, 6 August 2013 (UTC)

SSL and TLS a bad joke

SSL and TLS are a bad joke. Just plug a Packet Forensics Series5 into the line and you get the plaintext of the communication. See http://cryptome.org/ssl-mitm.pdf 80.226.24.2 (talk) 09:58, 17 August 2013 (UTC)

MiTM attacks like that (sslstrip) can be detected - for example with some browser extensions HTTPS Everywhere, Perspectives, signature-check. Widefox; talk 21:50, 16 September 2013 (UTC)

Opera with Blink

Does Opera 15 support TLS 1.2? I have tested Opera 15 on https://www.mikestoolbox.org/ and the result shows Opera 15 does not support TLS 1.2, support only TLS 1.1. In addition, Opera Next 16 supports TLS 1.2 again.

extended content

Opera 12.16 on Win7 x64 {{Client Version: TLS 1.2 Client Random: (snip) Client Random Time: (snip) Client Session ID: Client Cipher Suites: 006B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 006A TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 0069 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 0068 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 003D TLS_RSA_WITH_AES_256_CBC_SHA256 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0037 TLS_DH_RSA_WITH_AES_256_CBC_SHA 0036 TLS_DH_DSS_WITH_AES_256_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA 0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 0040 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 003F TLS_DH_RSA_WITH_AES_128_CBC_SHA256 003E TLS_DH_DSS_WITH_AES_128_CBC_SHA256 003C TLS_RSA_WITH_AES_128_CBC_SHA256 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0031 TLS_DH_RSA_WITH_AES_128_CBC_SHA 0030 TLS_DH_DSS_WITH_AES_128_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 0004 TLS_RSA_WITH_RC4_128_MD5 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 000D TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0010 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA Client Compression: 0 NULL Opera 15.0.1147.153 and Chrome 28.0.1500.95 on Win7 x64 Client Version: TLS 1.1 Client Random: (snip) Client Random Time: (snip) Client Session ID: (snip) Client Cipher Suites: C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0087 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA C00F TLS_ECDH_RSA_WITH_AES_256_CBC_SHA C005 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 0044 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA 0066 TLS_DHE_DSS_WITH_RC4_128_SHA 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA C00C TLS_ECDH_RSA_WITH_RC4_128_SHA C00E TLS_ECDH_RSA_WITH_AES_128_CBC_SHA C002 TLS_ECDH_ECDSA_WITH_RC4_128_SHA C004 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 0096 TLS_RSA_WITH_SEED_CBC_SHA 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 0004 TLS_RSA_WITH_RC4_128_MD5 002F TLS_RSA_WITH_AES_128_CBC_SHA C008 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA C00D TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA C003 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA FEFF SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA Client Compression: 0 NULL Opera Next 16.0.1196.45 and Chrome 29.0.1547.57 on Win7 x64 Client Version: TLS 1.2 Client Random: (snip) Client Random Time: (snip) Client Session ID: (snip) Client Cipher Suites: C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 006B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 0035 TLS_RSA_WITH_AES_256_CBC_SHA 003D TLS_RSA_WITH_AES_256_CBC_SHA256 C007 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA C023 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 C011 TLS_ECDHE_RSA_WITH_RC4_128_SHA C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA C027 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 0004 TLS_RSA_WITH_RC4_128_MD5 002F TLS_RSA_WITH_AES_128_CBC_SHA 003C TLS_RSA_WITH_AES_128_CBC_SHA256 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA Client Compression: 0 NULL}}

TLS and Cipher Suites support of Opera 15 seems to be same as that of Chrome 28, and that of Opera 16 seems to be same as that of Chrome 29. Does current Opera use NSS library as same as Chome? Does anyone know official information about TLS support of Opera with Blink? --113.42.219.90 (talk) 04:49, 21 August 2013 (UTC)

see Opera (web browser), Presto (layout engine). Widefox; talk 13:54, 22 August 2013 (UTC)

So, I think it's better to change Opera table like this.

Browser support for TLS

Browser	Platforms	TLS 1.0	TLS 1.1	TLS 1.2
Opera 5–7	Linux, Mac OS X, Windows	Yes	No	No
Opera 8–9	Linux, Mac OS X, Windows	Yes	Yes, disabled by default	No
Opera 10–12	Linux, Mac OS X, Windows[e]	Yes	Yes, disabled by default	Yes, disabled by default
Opera 14–current	Linux, Mac OS X, Windows[f]	Yes	Yes	No
Opera 16- (Next, Developer)	Linux, Mac OS X, Windows[f]	Yes	Yes	Yes

Notes:

• e) Opera 10 added support for TLS 1.2 as of Presto 2.2. Previous support was for TLS 1.0 and 1.1.[27] TLS 1.1 and 1.2 are disabled by default (except for version 9[28] that enabled TLS 1.1 by default).
• f) TLS support of Opera 14 and above is same as that of Chrome, because Opera has migrated to Chromium backend.

ref

"Changelog for Opera 5.x for Windows" at Opera.com

"Changelog for Opera [8] Beta 2 for Windows" at Opera.com

same as Chrome 22-28

same as Chrome 29-current

--113.42.219.90 (talk) 03:51, 23 August 2013 (UTC)

Website cipher security table should be rotated

The table as presented spans past the width of even a full-sized browser window. It would be better arranged with protocol versions on the horizontal axis and ciphers on the vertical axis. Dredmorbius (talk) 06:48, 7 September 2013 (UTC)

Does it fit now for you Dredmorbius? A smaller font is possibly preferable, as done in bigger tables. Widefox; talk 18:04, 14 September 2013 (UTC)

talk It's still overly wide. As I said, swapping the vertical and horizontal aspects of the table would be preferable. This is a screenshot showing what I see in a 1400px wide window: http://imgur.com/Q4171Yr Let's see if I can't edit into something reasonable .... OK, see my Sandbox page: User:Dredmorbius/sandbox. It doesn't have all of the fancy formatting and linkages (I may go back and add those, I'm not fully up to snuff on Mediawiki table edits), but at least the basic layout fits reasonably on screen. Dredmorbius (talk) 16:08, 19 December 2013 (UTC)

How about this? (normal font size, added ChaCha20+Poly1305 and some RFCs).--Claw of Slime (talk) 16:52, 19 December 2013 (UTC)

Cipher	Protocol version
	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2
3DES CBC	Insecure	Depends	Depends	Depends	Depends
AES CBC	—	—	Depends	Secure	Secure
AES GCM	—	—	—	—	Secure
AES CCM	—	—	—	—	Secure
Camellia CBC	—	—	Depends	Secure	Secure
Camellia GCM	—	—	—	—	Secure
SEED CBC	—	—	Depends	Secure	Secure
IDEA CBC	—	—	Depends	Secure	—
DES CBC	Insecure	Insecure	Insecure	Insecure	—
RC2 CBC	Insecure	Insecure	Insecure	Insecure	—
RC4	Insecure	Insecure	Insecure	Insecure	Insecure
ChaCha20+Poly1305	—	—	—	—	Secure

Notes

References

Done.[15]--Claw of Slime (talk) 17:08, 22 December 2013 (UTC)

That is much better, thanks! Dredmorbius (talk) 06:00, 12 January 2014 (UTC)

In light of the NSA revelations

There should be a section discusing the posible compromise of the security protocol. — Preceding unsigned comment added by 200.26.180.203 (talk) 06:58, 9 September 2013 (UTC)

The main sources of this news story are The Guardian and the New York Times. The wording of these stories is vague - perhaps deliberately - and does not explicitly support the claim that the NSA can crack TLS/SSL at will.--♦IanMacM♦ ^{(talk to me)} 11:06, 9 September 2013 (UTC)

"SSL added and removed here"

This story in the Washington Post raises an intriguing point. What does "SSL added and removed here" (followed by a smiley face) actually mean? There are two main possibilities: a) The NSA has the private key involved. b) The NSA can break into SSL communications without being detected. Possibility b) is the important one, and has been suggested by previous Snowden material. This should be added to the article in some form.--♦IanMacM♦ ^{(talk to me)} 08:15, 31 October 2013 (UTC)

The post above is more than a year old but I thought I'd respond anyway. The part of the diagram marked "SSL added and removed here" refers to the frontier of a service provider's network. When you access Gmail, for example, Google encrypts/decrypts your connection at the frontier to their network, and then your data moves around unencrypted internally within their network. The NSA exploited this by intercepting the internal communication within Google's network. That's what the article and diagram describes. The article tells us nothing about the NSA's ability to break SSL. Origin238 (talk) 06:55, 15 February 2015 (UTC)

Key agreement/exchange

This article has does a good job of describing ciphers and the risks inherent in choosing a weak one. But I've been concerned for some time that the article says nothing about key agreement/exchange and could leave the non-expert reader with the impression that good TLS security rests entirely in picking, say, Camellia over RC4. A TLS cipher suite has three components: a key exchange/agreement protocol, a cipher, and a hashing function. Until now, the article has only covered ciphers. I've made a start on a section on Key agreement/exchange and welcome further contributions. Perhaps the information should be turned into a table similar to the one used for ciphers, with columns for TLS_RSA, TLS_DH, TLS_DHE, TLS_ECDH, TLS_ECDHE, etc.; rows for forward secrecy, secure server authentication, certificate private key compromise, etc. and the same ratings (insecure, weak, and secure used elsewhere in the article) with attendant notes.

Perhaps there should also be a section on the third part of the TLS cipher suite -- the hashing algorithm. Not sure what could be said about the security of the various hashing algorithms. If anyone has some gripping information to reveal about using AES_128_CBC_SHA vs. AES_128_CBC_SHA256, now would be a good time to come forward.  :) Ross Fraser (talk) 23:54, 9 September 2013 (UTC)

Agree. I'm actually wondering if we should separate off the implementation security aspects into say a list article, as they're a moving target more than the protocol page - say to targets such as Cipher security summary, Comparison of web browsers, Comparison of TLS implementations, or a new one. Widefox; talk 18:11, 14 September 2013 (UTC)

I'm not in favour of a separate article right now as there is a great deal of controversy swirling through the Internet in the light of the NSA revelations with speculation along the lines of "TLS is broken", "TLS isn't secure anymore", "TLS never was secure", etc. The current interest shows in the page view statistics: the article regularly gets 5,000 views a day (peaking at 7,500 views on Sept 6). As it is now written, the article does a good job of showing a security protocol that has evolved, and is still evolving, to address security threats that have been revealed over time. This is actually a much more interesting aspect of the article (and of TLS itself) than the protocol's handshake details, record formats, etc. Moreover, attacks against implementation aspects have actually impacted the protocol and shaped its changes from SSL 3 to TLS 1.0 to 1.1 to 1.2, so the protocol itself has become (and probably always will be) a moving target progressing through versions to address security problems. Finally, an attempt to push some of the security problems in implementations off into a list article might be misread by some as an attempt to sweep TLS security problems "under the rug" (e.g., Comparison of TLS implementations only gets about 100 views a day).

Perhaps in a year or two, when more is known about NSA's/GCHQ's attacks against TLS encryption, this article and its supplementary articles can be reorganized to help the reader focus on highlights. Ross Fraser (talk) 05:31, 16 September 2013 (UTC)

yes I agree. I had a wholly unsuccessful attempt to get this to be the primary topic of TLS due to the popularity (~1/3 million in last 3 months). I'm aware that our "secure" "insecure" ratings are WP:SYN due to the nibbling away of aspects over time. The trustworthyinternet source was the start of these ratings but we've diverged due to updates, with as you say with the whole topic under the cloud of unknown details about NSA subversion, possibly making all our ratings moot. Maybe instead of "secure" and "insecure" we should switch to something like Cipher security summary where we just detail the known breaks - leaving things with no known breaks as white instead of green? Going back to our previous discussion, something like (red) "Insecure" (for "security broken") (yellow) "Weak" (theoretical break), and (white) <empty> when there's no known issue. Separately, do you think due to BREACH, all should be marked yellow? Jesse Viviano - this is basically your idea, does that sound good to you? Widefox; talk 14:10, 19 September 2013 (UTC)

When I came up with the table, I chose "Secure" to mean that there exists options for each instance marked "Secure" that would exclude all feasible attacks. Disabling HTTP compression takes care of BREACH for now under that criterion. Also, there are other options listed at https://community.qualys.com/blogs/securitylabs/2013/08/07/defending-against-the-breach-attack that could bust BREACH as well. However, it is starting to look like we might need a new version of TLS that does not worry about compatibility with SSL or previous versions of TLS except at the time to choose the TLS version at the time of TLS session setup. Jesse Viviano (talk) 21:00, 19 September 2013 (UTC)

Agreed re: BREACH -- there are available methods to block it. Also agreed it's time for TLS 1.3, but that's out of our hands.

Like Widefox, I'm concerned about those reassuringly green squares. Perhaps we need a table legend that makes clear what you've described as your rationale for the table: "In the table, variants of TLS are marked in green and labelled 'Secure' in those cases where it is still possible to mitigate against all the publicly known attacks that can feasibly be mounted against these TLS variants". Doubtless, you could come up with better wording, but the presence of such a legend would make it clear that green/secure is not a blessing from a third party; merely the absence of a fatal curse. Ross Fraser (talk) 07:09, 20 September 2013 (UTC)

Maybe version 2.0 would be better than 1.3 if we are going to not care about compatibility. 1.3 would be appropriate if the TLS working group just made the changes to defeat today's attacks while maintaining as much legacy code as possible. Jesse Viviano (talk) 03:21, 21 September 2013 (UTC)

I removed the green colour per above. Now, as we're well into WP:OR territory with our synergistic interpretations, Jesse Viviano, Ross Fraser, why are we saying that SSL 3.0 and TLS 1.0 (ie 3DES CBC, AES CBC, IDEA CBC) are all insecure, when BEAST can (and has) been mitigated (for example in NSS), so they are practically securable, the same rationale for giving the secure rating in 1.1 and 1.2? We're not consistent, so should make those 5 boxes white, unless I'm missing something? To clarify, I changed the two tables accordingly, but they should all be the same colour - either all white or all "depends" (pink). I would personally go with white. Widefox; talk 21:30, 24 September 2013 (UTC)

I marked SSL 3.0 and TLS 1.0 insecure because BEAST can only be mitigated by the client with some sort of hack I think is known as 1/n-1 record splitting or by the server by moving to RC4, and RC4 as used in TLS was broken in July. The server cannot enforce the use of this hack. Jesse Viviano (talk) 02:07, 25 September 2013 (UTC)

Yes, exactly. It can be mitigated so can be made secure per our logic above - in the same way as the other issues that can be made secure - all covered by the notes. We should treat them the same. ...Except - Safari still doesn't have default record splitting so maybe leaving as "Depends" until they have (any any other notable software has) would be appropriate. It also means we are roughly back to the rating/colouring on the source, so feels a bit less OR. Widefox; talk 14:11, 25 September 2013 (UTC)

Conflation of CRIME and BREACH

CRIME and BREACH is repeatedly being conflated by an WP:SPA editor. I think some consensus is needed more than just me reverting those edits. I would appreciate your input. Widefox; talk 13:04, 17 September 2013 (UTC)

Sorry for the delay in responding, but I've been fighting a battle over the proper Canadian spelling of "honourary"! The essence of the last edit by Thompor was the insertion of the phrase "using the CRIME attack techniques"; the rest was mostly awkward grammar and phrasing arising from a perhaps hasty edit or from a desire to avoid another revert by adding and changing as few words as possible. I think the effect it had of implying that CRIME could also take as little as 30 seconds may have been unintentional. I'm not entirely sure what the underlying objection is, but it seems to focus on BREACH being a derivation and not wholly original, and also perhaps with giving credit back to the two CRIME researchers. I have no problem with Thompor's insertion of "using the CRIME attack techniques", as it is supported by the Dan Goodin article. It may help address the core of Thompor's concerns.

Ross Fraser (talk) 06:20, 18 September 2013 (UTC)

My understanding is that CRIME is that quick too, although I could only find the "30s" headline associated with BREACH, so just trying to keep to the sources. The main issue I have with conflating them is twofold 1. BREACH is not CRIME (despite a derivation of it) and 2. mitigation is completely different. Yes I agree, with a source and correct wording (so that BREACH isn't removed or conflated) I'm sure this would be an improvement - Thompor is that agreeable (to try some wording here)? Widefox; talk 13:41, 18 September 2013 (UTC)

Do it better than me, you can. I tried to add and change as few words as possible. CRIME and BREACH are the same discovery. CRIME against cookies is faster than CRIME against server HTML. The 30 seconds sentence is only Ars reporter headline choice. CRIME was not fixed. Only some CRIME cases were mitigated. If CRIME is fixed the same solution fixes BREACH. The fix is solving compression of secrets mixed with hacker data. - Thompor (talk) 16:32, 20 September 2013 (UTC)

BREACH improves on the original CRIME technique, to the point where I think it is fair to call it a new exploit. You can fix CRIME compltetly by turning off TLS compression. Alas, this has no effect at all on BREACH, which exploits HTTP compression. -- The Anome (talk) 16:50, 20 September 2013 (UTC)

BREACH does not improve CRIME in any way AFAIK. CRIME presentation included CSRF token attack, VPN, Mail, Chat. Every implementation of certificate MiTM with a nice name and a dot com domain to promote it must be included in the TLS Wikipedia page as a new attack? - Thompor (talk) 20:51, 20 September 2013 (UTC)

BREACH improved on CRIME in just one, tiny, but crucial, way: it defeated the countermeasure of turning off TLS compression that defeated CRIME. In retrospect, it's obvious, but it was not in any way obvious to anyone else at the time, including the security experts who believed that CRIME was a solved problem after disabling TLS compression. All the reliable sources I can see take the same line: BREACH is a significant new exploit, albeit one that is based on improving the mechanisms originally exploited in CRIME. I can see you feel quite strongly about this, but unless you can show evidence that BREACH is not a distinct security exploit based on WP:RS, we are just going to have to go with community consensus on this, -- The Anome (talk) 09:44, 21 September 2013 (UTC)

Yes BREACH does improve on CRIME in a crucial way - instead of attacking TLS compression, attacking HTTP compression. My understanding is that turning off compression on TLS level is an easy decision, turning off HTTP compression is a performance costly decision. Thompor - is there any source that says they are the same? If you truly believed that, the articles should be merged as one topic. I see no consensus for that here yet, awaiting a strong (source based) case to be made. Anyhow, in comparison, one of the sources says that BREACH is quicker than CRIME, anyone seen a RS for the speed of CRIME? Widefox; talk 10:56, 21 September 2013 (UTC)

Please read again. CRIME attacks HTTP compression and more. BREACH talk doesn't show new ideas only implementation against specific application. CRIME slides describe algorithms and BREACH uses them. Contact the authors. Thompor (talk) 23:02, 23 September 2013 (UTC)

I agree with you, [16] p38 does define CRIME as being also for HTTP compression (not just TLS and SPDY), but also p39 "Two Tries may work, but we haven't tested it yet." - which my WP:OR interpretation is that by definition CRIME works (in theory) on HTTP compression, but they hadn't actually done it yet. So in summary, a WP:PRIMARY source defines CRIME as including HTTP compression in theory but without a working example, but majority/all WP:SECONDARY sources focus/interpret CRIME just as the TLS (and SPDY) compression, and call the HTTP compression a separate attack called BREACH (essentially an implementation of the CRIME principle just for HTTP compression). I agree with you that we are lacking to not include/highlight this, so should add this yes. I extend my support to work with you on the wording that we all find acceptable...would you be happy to do this here on the talk page first (ie by consensus)? This may seem tiresome, but I'm repeating myself, and have to explain... we do favour secondary sources to primary (see those links). Most importantly, resolving such things is done through consensus not by repeatedly changing / removing info (which is adequately sourced with secondaries) - hope WP:NOTTRUTH help explain. Widefox; talk 11:05, 24 September 2013 (UTC)

I'm not going to remove or change info. Your mention of SPDY is helpful: SPDY attack is not fixed disabling TLS compression. Was it fixed? Then clearly CRIME is not fixed disabling TLS compression. If secondary sources say CRIME is fixed disabling TLS compression then those sources are wrong. Thompor (talk) 19:08, 24 September 2013 (UTC)

That's fine, so feel free to propose some wording changes to TLS, CRIME and BREACH: Widefox; talk 20:46, 24 September 2013 (UTC)

My suggestions follow.

• 1: the BREACH paragraph is longer for no reason. Most sentences can be moved to the generic CRIME paragraph. Use the BREACH paragraph to mention the risk of HTTP compression and that it was anticipated by CRIME slides and demonstrated by BREACH against APP and mention which important APP was vulnerable.
• 2: The 30 seconds sentence doesn't add useful information. Add a sentence saying that CRIME and BREACH are fast. CRIME against cookies is faster because does not need to wait for server responses. Speed is proportional to the length of the secret data.
• 3: Mention SPDY. Add a warning: SMTP/POP3, VPN and remote desktop SSL/TLS deployments could be vulnerable to CRIME.
• 4: Make sure people understand CRIME is possible every time compression is used and they must evaluate their implementation. Popular compression algorithms were not modified to fix cRIME. — Preceding unsigned comment added by Thompor (talk • contribs) 22:01, 24 September 2013 (UTC)

References

Google ChaCha20 and Poly1305 for TLS

Adam Langley has announced Google will implement on server and client draft-agl-tls-chacha20poly1305-01 [17]. Widefox; talk 22:10, 16 October 2013 (UTC)

Dual EC/TLS Vulnerability

http://dualec.org/ http://projectbullrun.org/dual-ec/ 80.226.24.13 (talk) 08:04, 2 April 2014 (UTC)

Web Browsers: IE 6 without Service Packs

According to MS support, IE 6 without service packs does not support SSL 3, but only SSL 2. I presume (but have no references) that this means that w/o SPs it does not support TLS 1.0 either. I think this requirement/limitation is worth a footnote in the IE 6 row of the Web browsers table.

FreeText (talk) 15:07, 2 April 2014 (UTC)

References

Triple handshake attack

Could someone please add something about the triple handshake attacks disclosed at https://secure-resumption.com/? I would if I could understand all of this. The summary at the site over-simplifies things too much to be useful here, but the details requires one to be an expert in TLS to understand. Jesse Viviano (talk) 21:29, 23 April 2014 (UTC)

Heartbleed Bug: why "was"?

To answer Claw of Slime's question, when reverting my change: just because OpenSSL has been fixed and a new release was issued, and most sites which were vulnerable have updgraded and issued notices to their users about it since. 76.10.128.192 (talk) 02:33, 2 June 2014 (UTC)

Regarding the browser table and POODLE

I added the stuff I knew about POODLE into the browser table. Feel free to combine the last two columns if you feel that POODLE should be combined into the vulnerabilities column. I did it this way because I felt it was critical to show which browsers are screwed by POODLE (e.g. Chrome because disabling SSL 3.0 requires a command line argument every time the browser is launched, which is not feasible with OS-launched instances of this browser, and Safari because it does not provide any option to disable SSL 3.0) and which browsers can be fixed (all versions of IE that support TLS allow an administrator to permanently shut off SSL 3.0, and current versions of Firefox can be configured with either a plugin or a setting in about:config), and I did not want to trash the work that went to the other vulnerabilities column without consensus. Jesse Viviano (talk) 03:07, 17 October 2014 (UTC)

Spurious failed verification

They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating. I just looked at the citation and X.509 and asymmetric / public-key cryptography are both mentioned. Suggest that the tags be removed as confusing to readers.

References

BEAST

As far as I know in 2011 all Browsers were vulnerable to BEAST, but the Table here says f.e. that Firefox were ever vulnerable. At the section about BEAST there is a ref. to the Patch for Mozillas NSS, so could someone fix the Table and if necessary for other Browsers/Bugs to? -- Der-Orden (German-Wiki) 19:12, 31 January 2015 (UTC)

No. Firefox is not vulnerable to BEAST. Mozilla Security Blog says:

Firefox itself is not vulnerable to this attack. While Firefox does use TLS 1.0 (the version of TLS with this weakness), the technical details of the attack require the ability to completely control the content of connections originating in the browser which Firefox does not allow.

— Attack against TLS-protected communications - Mozilla Security Blog

Bug 665814 is the bug to implement 1/(n-1) record splitting mitigation for NSS against BEAST and other BEAST-like attacks (chosen plain text attacks), not the bug to mitigate BEAST attack itself for Firefox.

• "I doubt that Firefox or Chrome would be exploitable in such a way, but it is straightforward to prevent this scenerio. My patch prevents that scenerio by never doing any I/O between the encoding of the one-plaintext-byte record and the encoding of a subsequent record." by Brian Smith
• "Firefox can't be used to do the chosen plain text part" by Steven Roddis

--Claw of Slime (talk) 04:02, 1 February 2015 (UTC)

Chrome is in the similar situation.

Although Chrome is not directly affected by the attack, the NSS network library was updated to include a defense against so-called BEAST.

— Chrome Stable Release

--Claw of Slime (talk) 04:19, 1 February 2015 (UTC)

Supposed contradiction in the first section

The first section has a "contradiction" tag but there's no discussion here on the talk page about it. I also can't see where there's a contradiction. If the person who put the tag there isn't going to explain it, should it just be removed? Origin238 (talk) 06:46, 15 February 2015 (UTC)

Discussion at Village Pump (Proposals)

There is a proposal to enable HTTPS by default for all readers on Wikipedia at the Village Pump. Your input in the discussion would be welcome. Thank you, Tony Tan⁹⁸ · talk 04:43, 21 February 2015 (UTC)

Should the external links use HTTPS if the external websites are HTTPS-only

It seems I engaged in an edit war with User:Kbrose. I updated the protocol of some external links to HTTPS, because these sites are HTTPS-only, and the consensus of a discussion in 2014 was to "use HTTPS links for HTTPS only sites, protocol relative links for sites that support both HTTP and HTTPS, and HTTP links for sites that don't support HTTPS at all". But User:Kbrose reverted my edits, with a summary "rv, if they enforce it then there is no need to do this rubbish". I left Kbrose a message on his/her user talk page to explain why I made these edits, but so far I got no reply.

I am sorry for edit warring, but I would like to discuss with the community if it is acceptable to update external links for websites that support HTTPS. Thanks! Chmarkine (talk) 21:59, 21 February 2015 (UTC)

Fine. I apologize! I have changed my mind. HTTPS is useless, and we should always use HTTP on Wikipedia. I will revert all my edits related to HTTPS until I get blocked. Chmarkine (talk) 03:55, 22 February 2015 (UTC)

Insecure?? Please replace with unsecure or non-secure.

Insecure?? Please replace with unsecure or non-secure.

Blatantly bad grammar :-)

185.21.210.74 (talk) 09:28, 27 March 2015 (UTC)

Hi, thank you for providing feedback! As far as I can tell, both the Merriam-Webster dictionary and dictionary.com have the word "insecure" in them with expected definitions. Please explain why it should be replaced or why there is currently a grammatical error. Thank you! Tony Tan⁹⁸ · talk 20:17, 27 March 2015 (UTC)

Avoiding Triple-DES CBC

The subsection "Avoiding Triple-DES CBC" in the SSL/TLS security section: 1) contains the text "some experts recommend..." without naming the experts 2) has only one reference -- a broken link 3) covers material that is already discussed elsewhere in the article (see references to "Lucky Thirteen attack")

Unless anyone strongly objects, I'd like to delete this subsection. It adds nothing and has an "advice to the reader" tone that is inappropriate for WP. Ross Fraser (talk) 00:54, 28 May 2015 (UTC)

1) Ivan Ristić (ref to 2) ) 2) link fixed now 2003:4C:6E0C:A800:2996:4B0C:E158:7DCF (talk) 15:35, 2 June 2015 (UTC)

I've moved all the existing text from this subsection into the Timing attacks on Padding subsection where the text fits logically. Ross Fraser (talk) 22:30, 16 October 2015 (UTC)

Lede needs a rewrite

It's time to revise the lede for this article. There are several current faults:

• it doesn't actually summarize the article, as per WP:lede
• it doesn't provide an accessible overview to non-technical readers. E.g., the Web isn't mentioned until the 5th sentence and you have to read to the very end to encounter the word "browser"; you'd think for an article on the Web's most important security protocol--used by sites like Google, Facebook and, um, that Wikipedia thing--that the Web would get more than a mention in passing among a list of examples)
• it overly relies on technical language. E.g., 2nd sentence: "They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to negotiate a symmetric session key."
• it contains detailed material that should be in the article, not the lede (e.g.: the whole 3rd para on the OSI model is mentioned here and nowhere else in the article).

This article gets 40,000 to 60,000 views a month and is rated of top importance to several computer-related portals. We can do better.

I welcome suggestions from editors as to how to improve the lede. I'll make a start on my own if no one else interested, but would prefer a good discussion of ideas here on the Talk page first. Ross Fraser (talk) 03:19, 18 July 2015 (UTC)

So far, no one has made any substantial edits to the intro to address the issues discussed above, so I've done a rewrite. The new version preserves much of the text of the previous version (though some of the more technical text was moved into the body of the article) and it better summarises the article itself as per WP:lede. I've also done as much as I can to make the intro readable to non-technical readers. This WP article still gets between 5,000 and 6,000 hits a day (rising to more that 14,000 on one day a week ago) and these readers can't all have degrees in computer science.

The description section could also do with a re-write to clarify, at a somewhat more detailed level, how TLS works. Ross Fraser (talk) 01:04, 18 October 2015 (UTC)

Where in the OSI layer?

The article currently needs a citation for the following statement from the third paragraph:

"In OSI model equivalences, TLS/SSL is initialized at layer 5 (session layer) and works at layer 6 (the presentation layer)"

... well I looked for an appropriate citation and found a respectable publication (Security VPN certification guide from Cisco Press) that contradicts this, explicitly placing SSL and TLS between the transport and session layers.

See https://books.google.com/books?id=5PJisOKJ0k8C&pg=PA22&dq=tls+OSI&hl=en&sa=X&ved=0CD8Q6AEwB2oVChMIwpGTy_CwxwIVj0uSCh1SeAkc#v=onepage&q&f=false

I would like to modify the paragraph to agree with this reference.

References

-bobB (talk) 20:02, 17 August 2015 (UTC)

I agree with the previous posts. When reading the article, I was puzzled about the classification as application layer protocol. There is not only a need for changing this page, but also for changing Template:IPstack. The page Internet protocol suite puts SSL/TLS between transport layer and application layer, conforming to the book cited by bobB. The name Transport Layer Security itself indicates a tight relation to the transport layer. The German page on TLS puts SSL/TLS on the transport layer above TCP. -- Chwinter (talk) 13:02, 4 January 2017 (UTC)

Doubly agreed. We need to use citations rather than doing original research. And since it seems that TLS doesn't fit neatly into the OSI model, we probably need to explain exactly that rather than trying to artificially an inaccurately simplify it down to a single layer. --Bigpeteb (talk) 20:14, 13 April 2017 (UTC)

Library support for TLS/SSL table has lost a coherent colour coding

The colour coding in the Library support for TLS/SSL table no longer appears to make any sense. Some cells marked "No" (as in not implemented) are marked in green (secure) and some cells marked "No" are marked in red (insecure). These colourings can't both be correct.

The same inconsistency happens with cells marked "Yes". The RSA BSafe row is marked as a red "Yes" in the SSL 3 column, and as a green "Yes" in the TLS columns. What does this mean?

I don't know how readers are supposed to interpret this colouring scheme. Ross Fraser (talk) 22:38, 16 October 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Transport Layer Security. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20071012205124/http://my.opera.com:80/yngve/blog/2007/04/30/10-years-of-ssl-in-opera to http://my.opera.com/yngve/blog/2007/04/30/10-years-of-ssl-in-opera
• Added archive https://web.archive.org/20120915224635/http://threatpost.com:80/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312 to http://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 03:37, 17 October 2015 (UTC)

TLS 1.3 removing weak elliptic curves

Concerning section "TLS 1.3 (draft)", please clarify "removing support for weak and lesser used named elliptic curves" by stating exactly which ECC are going to be removed. Thanks! • Sbmeirow • Talk • 10:11, 30 November 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 5 external links on Transport Layer Security. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20140606050814/http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf to http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf
• Added archive https://web.archive.org/20150120120428/https://www.openssl.org/news/openssl-1.0.1-notes.html to https://www.openssl.org/news/openssl-1.0.1-notes.html
• Added archive https://web.archive.org/20101106130105/http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf to http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf
• Added archive https://web.archive.org/20120306184633/https://developer.mozilla.org/NSS_3.12.6_release_notes to https://developer.mozilla.org/NSS_3.12.6_release_notes
• Added archive https://web.archive.org/20141216203704/http://www.imc.org:80/ietf-openpgp/mail-archive/msg06063.html to http://www.imc.org/ietf-openpgp/mail-archive/msg06063.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Ross Fraser (talk) 08:11, 5 January 2016 (UTC)

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 23:46, 4 January 2016 (UTC)

Data integrity table

I've written above about the problematic colour coding of another table in this article, but the Data integrity table is a disaster: it uses green to denote the use of MD5 hashes in SSL 2 through TLS 1.2. But MD5 has been broken for years and new research is kicking it to bits. I've never understood the colouring scheme (and there are no labels to help the reader) so I'm not in a good position to make the changes. Shouldn't "No" be grey instead of red? Then a given SSL/TLS version can be coded as red or green if it supports an insecure or secure HMAC, no? Ross Fraser (talk) 01:41, 7 January 2016 (UTC)

POODLE Vulnerability and Android

In the web browser table it is stated that the Google Android OS Browser is vulnerable for the POODLE attack on Android versions 4.1 to 5.0.2. But when I visit www.poodletest.com with the Android OS Browser in Android 4.4.2 or 5.0.1 I see the message that my browser is not vulnerable. Is this because the browser in principal is vulnerable but that it is fixed (e.g. by a google play services on-the-fly update), is the test on poodletest incomplete, or is the statement in the table incorrect? 139.63.209.126 (talk) 09:22, 8 January 2016 (UTC)

Let's answer this by myself: tests with zmap.io show that even Android 5.1.1 is vulnerable. 139.63.160.40 (talk) 08:44, 13 January 2016 (UTC)

update your TLS version to a version that is still current and still secure. — Preceding unsigned comment added by 14.97.32.187 (talk) 04:45, 28 September 2016 (UTC)

Interesting high level view of TLS

This is interesting, but how accurate is this compared to TLS reality? https://blog.cloudflare.com/tls-nonce-nse/ • Sbmeirow • Talk • 22:36, 12 October 2016 (UTC)

Can you list some specific issues or some questions about this article vs. your perception of TLS today? Ross Fraser (talk)

TLS 1.3 presentation video and slides

FYI

Video

• https://www.youtube.com/watch?v=RZdBcX_GJvI
• https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad

Slides

• https://speakerdeck.com/filosottile/tls-1-dot-3-at-33c3

• Sbmeirow • Talk • 01:12, 5 January 2017 (UTC)

Merge mcTLS into Transport Layer Security

mcTLS should be merged into Transport Layer Security as it is a version of the latter an could easily be made into a section in Transport Layer Security. -KAP03(^{Talk • Contributions • Email}) 01:28, 26 March 2017 (UTC)

I don't feel too strongly about this, but I'd rather not. The TLS article is already a beast, and mcTLS is a very discrete and self-contained extension. It's a stub now, but it could be a decent little article with some work.

@KAP03:, I'm interested to hear what you think. Thanks for your time Risc64 (talk) 01:40, 26 March 2017 (UTC)

When trying to answer such questions, I side with the reader (especially the nontechnical reader). For a reader to even look up an article on mcTLS, the reader probably already knows about as much as the mcTLS article currently presents. It would be make a good but short addition near the end (after Named Based Servers but before Standards and therefore place the mcTLS work in context. A link page could direct searches on the term mcTLS directly to this section. Ross Fraser (talk) 05:34, 26 March 2017 (UTC)

@KAP03: @Ross Fraser: I maintain that mcTLS is discrete and complex enough to have its own article. However, I've realized that I'm not sufficiently interested in it to write more than a stub or start-class article. I'm therefore fine with it being merged, but I'd support splitting it back out if someone writes a comprehensive and detailed section about it. Risc64 (talk) 23:59, 27 March 2017 (UTC)

Agreed. Merge it for now and if it ever becomes detailed and comprehensive, split it out and link to it. Ross Fraser (talk) 04:41, 29 March 2017 (UTC)

Intro too long?

The intro has been recently tagged as too long, but I don't agree. It exactly summarizes a fairly long and technical article (the purpose of the lead is to summarize the article) and provides a good explanation for non-technical readers. It's actually one of the best explanations of TLS for non-tech readers available on the web. And it's being accessed by a *lot* of non-technical readers who probably don't read any farther than the intro (or need to): right now, it gets between 5,000 an 10,000 hits *a day*. (See https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-access&agent=user&range=latest-20&pages=Transport_Layer_Security)

It also introduces every one of the sections that follow in the article, and even provides the reader with links to the various sections within the article. Finally, the three bullet points in the lead really are essential to the definition of TLS -- it's a complicated standard that covers a lot of important ground and most of the security of the web (such as it is) depends upon it.

On the other hand, there might be some historical info that could probably be moved into another article. I'm thinking especially of the very long "TLS/SSL support history of web browsers" table and its many footnotes. Perhaps keep the last few rows for each browser and move the entire historical table into its own article? Or is it too soon to do this? (I'm easily persuaded that the very existence of this table over the last seven years has helped push web developers along in strengthening their support for TLS). Ross Fraser (talk) 05:52, 26 March 2017 (UTC)

The following was moved from talk section of User:Sbmeirow to here...

I don't agree the the TLS intro is too long. It exactly summarizes a fairly long and technical article (the purpose of the lead is to summarize the article) and provides a good explanation for non-technical readers. It's actually one of the best explanations of TLS for non-tech readers available on the web. And it's being accessed by a *lot* of non-technical readers who probably don't read any farther than the intro (or need to): right now, it gets between 5,000 an 10,000 hits *a day*. (See https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-access&agent=user&range=latest-20&pages=Transport_Layer_Security) It also introduces every one of the sections that follow in the article, and even provides the reader with links to the various sections within the article. Finally, the three bullet points in the lead really are essential to the definition of TLS -- it's a complicated standard that covers a lot of important ground and most of the security of the web (such as it is) depends upon it. Ross Fraser (talk) 05:52, 26 March 2017 (UTC)

When I tagged this article, I left this edit comment "the intro is very long. can't a bunch be moved into a new section at the top of the article???". I didn't say to delete the text, but instead to move it into a new section at the top, maybe called "Overview". The text in the intro doesn't suck, it's just long! If you want to remove the "tag", then go ahead and delete it. • Sbmeirow • Talk • 01:14, 27 March 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Transport Layer Security. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140531105537/http://www.networkworld.com/news/2012/120412-elgamal-264739.html to http://www.networkworld.com/news/2012/120412-elgamal-264739.html
• Added archive https://web.archive.org/web/20140531105257/http://www.networkworld.com/news/2011/101111-elgamal-251806.html to http://www.networkworld.com/news/2011/101111-elgamal-251806.html
• Added archive https://web.archive.org/web/20150214105056/http://www.matrixssl.org/news.html to http://www.matrixssl.org/news.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:12, 20 November 2017 (UTC)

Android 8

Added missing reference for android 8 SSLv3 — Preceding unsigned comment added by Wikidushyant (talk • contribs) 06:02, 22 November 2017 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified 2 external links on Transport Layer Security. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Ftrunk%2Fsrc&range=72316%3A67679&mode=html
• Added {{dead link}} tag to http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Ftrunk%2Fsrc&range=232870%3A241107&mode=html
• Added archive https://web.archive.org/web/20150109154102/http://botan.randombit.net/relnotes/1_11_13.html to http://botan.randombit.net/relnotes/1_11_13.html
• Added archive https://web.archive.org/web/20170330011044/https://technet.microsoft.com/en-us/windows-server-docs/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server-2016 to https://technet.microsoft.com/en-us/windows-server-docs/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server-2016

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:13, 20 January 2018 (UTC)

Inaccurate reference?

In the introduction it claims that SSL is prohibited from use by IETF, referencing the RFC 5246. I would argue that this needs to be reviewed since I can't seem to find anything in this source that support this claim. The closest thing I can find is RFC 6176, where only SSL v2.0 is prohibited. There exist later versions today. — Preceding unsigned comment added by 2001:6B0:2:2801:70BD:E737:C2DC:21CB (talk) 08:05, 2 March 2018 (UTC)

Yes, the RFC jungle can be confusing, to say the least. You'll find the relevant reference to SSL 3 in RFC 7568. Ross Fraser (talk) 01:31, 31 January 2019 (UTC)

TLS 1.3 finalized, article not yet updated

According to several news sources such as https://www.techrepublic.com/article/tls-1-3-is-approved-heres-how-it-could-make-the-entire-internet-safer/ the TLS 1.3 standard has been finalized, however the Wikipedia article still says the standard is still draft. BFeely (talk) 11:59, 30 March 2018 (UTC)

On March 20, 2018 an IETF draft was published and is now undergoing review for a period of six months. It must either be approved or the draft withdrawn by the end of September ("This Internet-Draft will expire on September 21, 2018"). In other words, the drafting has been finalized, but it is still a draft awaiting approval. Five more months...

BTW, the draft itself is very clear about this. On page 1, it states: 'Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."'

Ross Fraser (talk) 06:26, 28 April 2018 (UTC)

TLS 1.3 has been published as RFC 8446 in August 2018. The intro of this arcile has been updated with this edit. 141.12.67.199 (talk) 15:55, 26 March 2019 (UTC)

Properties of TLS

I've noticed that in August of 2016, an editor changed the text of one of the security properties stated in the RFC (TLS 1.2) and explained in the intro. The RFP correctly states that a TLS connection is reliable because of the inclusion of a MAC. The text in the intro had been changed to read "The connection ensures integrity..." Apart from misquoting the RFP, this also isn't accurate: the connection itself doesn't ensure anything -- it is the TLS protocol that does the ensuring, not the connection. Moreover, the notion of ensuring integrity was left ambiguous. Integrity of what? The TLS record? The handshake? The identities of the communicating parties? Security claims need to be unambiguous. And in the actual text of the TLS RFP, they are.

I've reverted the text back to once again accurately reflect the RFP. Ross Fraser (talk) 06:13, 28 April 2018 (UTC)

TLS 1.3 was published today

TLS 1.3 was published as RFC 8446. Since TLS 1.3 is a major update to the protocol (addition of 0-RTT, different handshake messages, new cipher suite formats, etc.), this Wikipedia article needs to be updated. Sodu12 (talk) 01:09, 11 August 2018 (UTC)

The intro of this arcile has been updated with this edit. 141.12.67.199 (talk) 15:56, 26 March 2019 (UTC)

Page is way too long

I would suggest chopping out the version details into a separate page. Tuntable (talk) 02:18, 10 September 2018 (UTC)

TLS 1.3 website examples

FYI: As of October 2, 2018 using Chrome 69 browser on Windows 10 with parameter "--ssl-version-min=tls1.3" to force using TLS 1.3, examples of some major websites that support TLS 1.3 are: Google Search, Gmail, YouTube. • Sbmeirow • Talk • 17:17, 2 October 2018 (UTC)