Talk:Transport Layer Security

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing / Networking (Rated C-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as High-importance).
 
WikiProject Computer Security / Computing  (Rated C-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.
 
WikiProject Internet (Rated C-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
 
WikiProject Cryptography / Computer science  (Rated C-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the quality scale.
 Top  This article has been rated as Top-importance on the importance scale.
Taskforce icon
This article is supported by WikiProject Computer science (marked as Top-importance).
 
WikiProject Technology (Rated C-class)
WikiProject icon This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
Checklist icon
 

Firefox Update[edit]

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?[edit]

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[edit]

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[edit]

(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. -RushyoTalk 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?)[edit]

(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[edit]

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[edit]

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[edit]

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[edit]

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 (talkcontribs) 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[edit]

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)
Yes check.svg 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)
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[edit]

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[edit]

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.

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[1] No No
Opera 8–9 Linux, Mac OS X, Windows Yes Yes, disabled by default[2] 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[3] No[3]
Opera 16- (Next, Developer) Linux, Mac OS X, Windows[f] Yes Yes[4] Yes[4]

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

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

    Website cipher security table should be rotated[edit]

    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
    [note 1][note 2][note 3]
    TLS 1.0
    [note 1][note 3]
    TLS 1.1
    [note 1]
    TLS 1.2
    [note 1]
    3DES CBC
    [note 4][note 5]
    Insecure Depends Depends Depends Depends
    AES CBC
    [note 4]
    N/A N/A Depends Secure Secure
    AES GCM
    [2][note 6]
    N/A N/A N/A N/A Secure
    AES CCM
    [3][note 6]
    N/A N/A N/A N/A Secure
    Camellia CBC
    [4][note 4]
    N/A N/A Depends Secure Secure
    Camellia GCM
    [5][note 6]
    N/A N/A N/A N/A Secure
    SEED CBC
    [6][note 4]
    N/A N/A Depends Secure Secure
    IDEA CBC
    [note 4][note 7]
    N/A N/A Depends Secure N/A
    DES CBC
    [note 4][note 7]
    Insecure Insecure Insecure Insecure N/A
    RC2 CBC
    [note 4][note 7]
    Insecure Insecure Insecure Insecure N/A
    RC4
    [note 8]
    Insecure Insecure Insecure Insecure Insecure
    ChaCha20+Poly1305
    [7][note 6]
    N/A N/A N/A N/A Secure
    Notes
    1. ^ a b c d RFC 5746 must be implemented in order to fix a renegotiation flaw that would otherwise break this protocol.
    2. ^ If libraries implement fixes listed in RFC 5746, this will violate the SSL 3.0 specification, which the IETF cannot change unlike TLS. Fortunately, most current libraries implement the fix and disregard the violation that this causes.
    3. ^ a b the BEAST attack breaks all block ciphers (CBC ciphers) used in SSL 3.0 and TLS 1.0 unless mitigated by the client. As of November 2013, Apple has turned on this mitigation by default only for Safari 7 for Mac OS X 10.9, resulting in Safari for iOS, for Windows, and for Mac OS X 10.8 or earlier still being theoretically vulnerable to the BEAST attack on those platforms - see #Web browsers
    4. ^ a b c d e f g CBC ciphers can be attacked with the Lucky 13 attack if the library is not written carefully to eliminate timing side channels.
    5. ^ 3DES provides only 108 or 112 bits of security, which is below the recommended minimum of 128 bits.[1]
    6. ^ a b c d AEAD ciphers (such as GCM and CCM) can be used in only TLS 1.2.
    7. ^ a b c IDEA, DES, and RC2 CBC have been removed from TLS 1.2.
    8. ^ the RC4 attacks weaken or break RC4 used in SSL/TLS
    References
    1. ^ Qualys SSL Labs. "SSL/TLS Deployment Best Practices". Retrieved 19 November 2013. 
    2. ^ RFC 5288
    3. ^ RFC 6655
    4. ^ RFC 5932
    5. ^ RFC 6367
    6. ^ RFC 4162
    7. ^ draft-agl-tls-chacha20poly1305-01
    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[edit]

    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"[edit]

    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)

    Key agreement/exchange[edit]

    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[edit]

    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.[1] 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 (talkcontribs) 22:01, 24 September 2013 (UTC)

    Google ChaCha20 and Poly1305 for TLS[edit]

    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[edit]

    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[edit]

    According to MS support, IE 6 without service packs does not support SSL 3, but only SSL 2.[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)

    Triple handshake attack[edit]

    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"?[edit]

    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)

    1. ^ https://twitter.com/iamtheneal/status/374600003680878592
    2. ^ http://answers.microsoft.com/en-us/ie/forum/ie8-windows_other/ie6-sslv3/f942e818-ffe0-4624-88d6-58dfcdd1ddc9