Jump to content

Talk:Comparison of TLS implementations

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by MrOllie (talk | contribs) at 23:28, 26 July 2021 (→Edit warring: vendor or implementation details?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Why OpenSSL compatibility mode?

Is there any reason why "OpenSSL compatibility" is listed? Why not CryptoAPI compatibility? NSS compatibility? If you want OpenSSL compatibility you can just use OpenSSL. Also, why is "OpenPGP library" listed? This doesn't have anything to do with TLS. 806f0F (talk) 10:51, 10 February 2011 (UTC)[reply]

"Is there any reason why "OpenSSL compatibility" is listed?" Because these projects has OpenSSL compatibility. "Why not CryptoAPI compatibility? NSS compatibility?" Because there are no project that has CryptoAPI or NSS compatibility. If there is, then feel free to add it. There are projects that USE CryptoAPI, which is listed in a another section. "If you want OpenSSL compatibility you can just use OpenSSL. Why don't you tell this to the projects that do implement ossl compatibility. I am sure they want your input. It is our task to compare, it is NOT our task to discuss why many TLS implementations decide to implement OpenSSL compatibility.
However the answer for that is simple. Many projects did as you suggest, implement on top of OpenSSL. Other TLS implementations want projects to migrate from OpenSSL and provide a compatible API to make that easy.
"Also, why is "OpenPGP library" listed? This doesn't have anything to do with TLS." Obviously you are wrong, as one TLS library provider implements it. It is Wikipedia to document what TLS library providers do, not to argue why they do it. If someone else discuss why they do something, it may be our task to document that. — Preceding unsigned comment added by 213.112.33.60 (talk) 12:07, 26 September 2011 (UTC)[reply]

Features to list

Different key exchange protocol deserve different column since not all implementations support them

But the SRP protocols aren't implemented by anything except GnuTLS (which implements all sorts of oddball stuff), all this is giving you is a huge block of red. GnuTLS implements all the SRP sub-options and everything else implements none of them, there's no need to break things down, it's a straight boolean yes/no for all of SRP. In addition you need to be careful about copy-and-pasting the ECDHE to ECDH, I'm not aware of any CA that issues ECDH certs so it's likely that support for ECDH is close to zero, i.e. ECDHE support doesn't imply ECDH support. 806f0F (talk) 16:00, 10 February 2011 (UTC)

Well, the other extreme is to compare the basic TLS functionality that everybody implements. Then why even compare? There is merit in comparing the "oddball" to you stuff as well. Nmav (talk) 20:51, 10 February 2011 (UTC)[reply]

Additional TLS Implementations

I've put together a list of TLS implementations that aren't currently listed on this page. If the goal of this page is to be comprehensive, they should probably be added. (Though perhaps the page will need to be split to keep it from becoming unwieldy... maybe along the lines of C/C++ versus other languages, or open source versus proprietary.)

I'm just listing the basic info for these, including a URL. I haven't yet compiled all the information necessary to populate all the tables on the page. (Perhaps some of that work could be crowdsourced.) But I thought it would at least be good to get them written down somewhere...

Ppelleti (talk) 08:50, 29 January 2012 (UTC) updated: November 5, 2012[reply]

updated: 2014/04/15 by (anon) : added miTLS to list

Updates: Added axTLS because I found it embedded in some code I was given the other day and it isn't on this list. Bob dvd (talk) 17:05, 9 November 2015 (UTC)[reply]

Hmmm... given that hs-tls (among others) has been deleted as "non-notable", I guess there's no point in adding the rest of these, since they would probably be considered "non-notable", too. Ppelleti (talk) 20:08, 20 August 2013 (UTC)[reply]

updated: 2019/07/05 by (anon) : added BearSSL used by ArduinoIDE/platformIO

Needs binary code size, and memory footprint, and speed/throughput comparisons

Great work on what has been presented so far, but it's a tad suspicious that some important metrics are missing. Makes me wonder if this table didn't originate with someone who stands to benefit from the exclusion of those metrics...

Peeps needing this stuff for embedded purposes absolutely need to know the binary code size overheads - bloat doesn't fit into ROMs...

Peeps wanting to handle massive simultaneous traffic need to know how memory intensive these implimentations are. I'm sure a few will do 100,000+ on a boring PC, but others will probably fall over at 100 - so some comparisons need inclusion here.

And of course - the big one - which are slow dogs that need to be put down, and which are the screaming cheetahs? — Preceding unsigned comment added by 120.151.160.158 (talk) 02:49, 26 February 2012 (UTC)[reply]


-- this article is not good, it didn't have any info on the most important aspect of comparison, the strength of encryption. — Preceding unsigned comment added by 203.189.167.126 (talk) 09:26, 24 August 2012 (UTC)[reply]

  • You are probably checking the wrong page. This is about comparison about TLS implementations. They implement the same protocols, thus have the same strength of encryption the protocol allows94.224.100.5 (talk) —Preceding undated comment added 00:37, 3 November 2012 (UTC)[reply]

Overview

I think the nation of orgin shouldn't be included in the implementation overview, one may be intrigued to care about it for the comparison of software.

And isn't "latest stable version" tedious to keep up to date, considering its usefulness? Maybe remove it to make it easier to keep the article up to date. Tantalum53 (talk) 10:13, 5 April 2013 (UTC)[reply]

Versions?

Hi,

I was wondering if this results come from real tests or just from documentation on the project website?

If the results are real tests, it will be fine if the version tested was mentionned (maybe is not the latest). Moreover, maybe the tested versions don't allow all option or possibilites if they are older.

For exemple, i read that ECDH-RSA and ECDH-ECDHA are not available for OpenSSL. THis is not true! I tested the current version on Debian (1.0.1e-2) and its is possible to use those cipher suites. They need respectively to provide an ECDSA server certificate signed with an RSA CA and an ECDSA server certificate signed with a ECDSA CA!

I wait for an answer before modifying the table.

Thanks

Kelly — Preceding unsigned comment added by 80.14.178.219 (talk) 17:04, 7 August 2013 (UTC)[reply]

Arbitrary curves?

The most recent change (23:22, 24 October 2013) states that OpenSSL supports arbitrary elliptic curves. While this is true in a way (you can actually use OpenSSL to do arithmetic on arbitrary curves), to the best of my knowledge it will not negotiate arbitrary curves during a TLS handshake. So I think the meaning of these columns in the "supported curves" table should be clarified: until the last change I was interpreting it as "supports arbitrary curves in the TLS handshake as per RFC 4492 section 5.1.1 (arbitrary_explicit_prime_curves(0xFF01), arbitrary_explicit_char2_curves(0xFF02)), but apparently we're not all on the same line here. Manuel (mpg) (talk) 09:29, 25 October 2013 (UTC)[reply]

Tables

I noticed that two of the tables have yes or no entries with the wrong colors. Is that deliberate?Michael9422 (talk) 00:18, 9 April 2014 (UTC)[reply]

Which tables? Support of insecure protocols/ciphers (ex. SSL 2.0, RC4, DEFLATE) is colored as red. This is intentional. --Claw of Slime (talk) 00:33, 12 April 2014 (UTC)[reply]
Most of the tables show 'yes' in green and 'no' in red. There are entries in the table for Protocol Support and in the table for Key Exchange which have the 'yes' and 'no' colors reversed. Why? Michael9422 (talk) 12:44, 24 April 2014 (UTC)[reply]
{{Yes}} and {{No}} are used in tables. If we markup like {{Yes|No}} or {{No|Yes}}, color will be reversed.
Markup Result
{{Yes}} Yes
{{No}} No
{{Yes|No}} No
{{No|Yes}} Yes
Support of insecure protocols/algorithms should be removed or disabled. This is the reason why some of "Yes" is red and "No" is green.--Claw of Slime (talk) 01:41, 25 April 2014 (UTC)[reply]
That makes the tables confusing, I think. I suspected vandalism. Is there a better alternative? Maybe different shades of red and green?Michael9422 (talk) 13:26, 25 April 2014 (UTC)[reply]

Languages

I think it would be a good idea to add in the first table a column about languages so that we know in which programming language each of the TLS implementation is written. This can be important, as the recent bugs in TLS (Apple goto fail, GnuTLS' similar and hearbleed) were all related to C. -- hugord

I added languages.[1] --Claw of Slime (talk) 17:18, 16 January 2015 (UTC)[reply]

FIPS140-2

The NSS implementation lists itself as FIPS140-2 level 2 certified. This is accurate, but irrelevant to this page as this certification is valid only for hardware. The level 2 FIPS140-2 certification takes into account tamper evidence and other hardware properties, which have no applicability when comparing software implementations. Thus, that certification table entry seems irrelevant to this page. Nmav (talk)

I don't agree your opinion. There is no reason to avoid to provide information about security level to Wikipedia readers. --Claw of Slime (talk) 17:18, 16 January 2015 (UTC)[reply]
I don't believe you even understand what I am writing. It is not an opinion but a fact. FIPS140-2 level 2 certification, certifies hardware, _NOT_ software which is what this page compares. The maximum certification a software implementation can receive is FIPS140-2 level1. Nmav (talk)
--
I have to agree with Claw of Slime. The NSS implementation of TLS, used within the hardware defined on the FIPS certificate, meets an "Overall Level 2". But as of today the actual FIPS certificate #248, and maybe others, is now on the NIST Historical list... --Security in mind —Preceding undated comment added 14:24, 26 March 2020 (UTC)[reply]

Key lengths

Please make a table for min/max key lengths (RSA/DH) for each implementation. Like this: https://msdn.microsoft.com/en-us/library/windows/desktop/bb931357%28v=vs.85%29.aspx (but please ACTUAL)

NSS: max 16384 bit RSA/DHE
Openssl: max 10000 bit DHE :(
Apple: max 4096 RSA/DHE — Preceding unsigned comment added by 2003:7A:8D11:3D00:60EE:71CD:2C8D:FDE2 (talk) 18:38, 7 February 2015 (UTC)[reply]

The "Table 1: NIST Recommended Key Sizes" from https://www.nsa.gov/business/programs/elliptic_curve.shtml would also be good for the article. — Preceding unsigned comment added by 2003:7A:8D11:3D00:60EE:71CD:2C8D:FDE2 (talk) 18:36, 7 February 2015 (UTC)[reply]

Mbed TLS and general info

Mbed TLS is missing from a lot of tables. It is e.g. listed for "Supported elliptic curves", but there it has a lot of "no"s. I wonder if this stuff is outdated anyway. Just as SSL is, and they took that out of the name as they changed it to "Mbed TLS".

Should this page be cleaned up a lot, as all of the browsers are dropping SSL. Having "no"s looks bad, but isn't if the stuff is known to be broken anyway (possibly, or not) anyway. I will not bother confirming if this might be outdated info and should be yes.. At least first, it would be good to get page cleaned up, in case you want to look up relevant info. comp.arch (talk) 08:32, 8 September 2015 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Comparison of TLS implementations. 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:

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 IITalk to my owner:Online 23:07, 31 January 2016 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 2 external links on Comparison of TLS implementations. 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:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

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) 02:41, 29 November 2016 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 2 external links on Comparison of TLS implementations. 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:

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) 16:40, 11 August 2017 (UTC)[reply]

Why include the countries of origin?

The countries of origin are not sourced and seemingly arbitrarily picked given that most of the implementations are developed by international organisations. I see no reason why I would want to know what country it originates from, so why are they included in the table? LetterC (talk) 11:56, 7 March 2021 (UTC)[reply]

Edit warring: vendor or implementation details?

There is an edit war going on where MrOllie beleives this page should not provide details about implementations, but rather details about vendors. The same war is going on in talk page of Comparison of cryptography libraries and a WP:AN3 has been posted on MrOllie's talk page on that matter. - Security in mind (talk) 21:39, 23 July 2021 (UTC)[reply]

The above is not an accurate summation of my argument - I believe that only notable implementations should be listed. Here we have multiple implementations from a vendor, only one of which is really notable. I won't be replying any further here, see Talk:Comparison_of_cryptography_libraries for the parallel discussion. - MrOllie (talk) 21:45, 23 July 2021 (UTC)[reply]
BSAFE MES has its own implementation, BSAFE Crypto-J has also its own unique implementation. MES and Crypto-J were the de-facto libraries used between 2000-2010. Both MES and Crypto-J are still used today, just look it up. And a TLS library is different from crypto library. A crypto library does not provide TLS. A TLS implementation uses a crypto library. Apples and Oranges. - Security in mind (talk) 21:54, 23 July 2021 (UTC)[reply]

Furthermore, looking at the page History page, especially around and previous to older page ID 955576189, WP users and Editors can see good faith between MrOllie and I. A good discussion with opposing views ending in a joint consensus where identical rows of different implementations of a single vendor were then merged into one row. If Microsoft SChannel and Apple Secure Transport can have different rows when the features of each implementation differs, why can't two different BSAFE products, hence implementations, ever be treated with equality and fairness? — Preceding unsigned comment added by Security in mind (talk • contribs) - Update.. correct, I wrote this... Security in mind (talk) 15:17, 25 July 2021 (UTC)[reply]

Alright, you got me, I'll respond again to correct some stuff that's being left out here. I was unaware at that time that you had a conflict of interest. You also split rows subsequent to that, which never enjoyed any sort of consensus.- MrOllie (talk) 14:56, 25 July 2021 (UTC)[reply]
I was unaware at that time that you had a conflict of interest., as a matter of fact, me too. I was unaware of this COI rule on WP until a week ago. If rows were split, that must have been because of different features provided by both implementations. If that was not the case, that was a honest mistake. SSL-J and MES, as described in the page prior to when the edit warring started, are in fact so much different apart in nature, while the different Microsoft and Apple implementations are actually one-row-per-version. And please, this is not a request to remove the Microsoft and Apple different rows. They must remain on separate rows. What I have been requesting from the get-go is that SSL-J and MES be treated as two different implementations, hence deserves their own rows when features / values are different. - Security in mind (talk) 15:17, 25 July 2021 (UTC)[reply]
MrOllie, gentle reminder regarding your Alright, you got me, I'll respond again to correct some stuff. I am still waiting for some kind of correction from you as you have left this page in a state where it looks like there is now only one TLS implementation, Crypto-J (in Java), while the one in C is still missing: Micro Edition Suite. - Security in mind (talk) 23:17, 26 July 2021 (UTC)[reply]
I was correcting the misrepresentations in your comment preceding my reply. - MrOllie (talk) 23:27, 26 July 2021 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_TLS_implementations&oldid=1035656598"