Jump to content

Talk:Comparison of TLS implementations

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Why OpenSSL compatibility mode?

[edit]

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

[edit]

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

[edit]

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

I think that both Go TLS implementation and RustTLS (https://github.com/rustls/rustls) should be added, as both are the de facto default TLS libraries for the Go and Rust programming languages,. That fact alone should make them notable enough. (Argumentation that doesn't apply to Haskell, as it is quite a niche language, and tlslite, as most Python applications use the native Python module which is just a thin wrapper around OpenSSL). Tomato86 (talk) 12:57, 31 August 2023 (UTC)[reply]

I am presently adding entries for rustls.
Strong agree on the golang's crypto/tls; it is more commonly used that many options listed here. Ctz ctz (talk) 08:59, 29 August 2024 (UTC)[reply]

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

[edit]

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

[edit]

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?

[edit]

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?

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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]

[edit]

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]

[edit]

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]

[edit]

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?

[edit]

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?

[edit]

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 misleading omissions in the comment preceding my reply. - MrOllie (talk) 23:27, 26 July 2021 (UTC)[reply]
So you are willingly allowing some vendors to list multiple revisions of their library using multiple rows, but you don't allow one vendor to list different library implementations on multiple rows, is that my understanding? - Security in mind (talk) 00:18, 27 July 2021 (UTC)[reply]
As ever, the inclusion criteria is about notability, not about how many entries one vendor or another might have. This really will be my last reply here, though, it is not productive to conduct identical arguments on multiple pages. Please respect that and don't put words in my mouth claiming I've agreed to anything again, so I don't have to come back here and correct what my position actually is. - MrOllie (talk) 00:27, 27 July 2021 (UTC)[reply]
In this field of cryptography, according to you, who decides which library is notable or not? Who is the High Inquisitor? Why do you believe SSL-J is more notable than Micro Edition Suite? I would like to get your opinion on this topic so I understand why this is being rejected. There has to be some reasons I am just too blind to see. - Security in mind (talk) 00:35, 27 July 2021 (UTC)[reply]
@MrOllie: making sure you saw my last question above. Awaiting your response, as the world is waiting to know why BSAFE can't be treated like Microsoft SChannel and Apple Secure Transport. Regards - Security in mind (talk) 19:11, 28 July 2021 (UTC)[reply]
Because it's not notable enough. End of story. Quetstar (talk) 04:51, 31 July 2021 (UTC)[reply]
@Quetstar: I'm sorry but I can't consider this the end of the story. This is not a way to end a debate, as there has been no explanation given as to why one implementation was removed while the other remained. As I understand from previous comments, Quetstar and MrOllie are now considering BSAFE MES to be not notable, while they consider BSAFE SSL-J to be notable. Is that right? If this is the case, please provide reasons and evidence as to why one is more notable than the other. Also, one has to ask oneself why the BSAFE C TLS implementation (MES) and the BSAFE Java TLS implementation (SSL-J) have both been listed in this comparison of TLS implementation since January 12, 2015, in Old revision of Comparison of TLS implementation , for more than 6 years without any objection whatsoever until two weeks ago. - Security in mind (talk) 13:36, 1 August 2021 (UTC)[reply]
@Security in mind: Notability is not only decided by usage, but also by the degree of knowledge around it, and BSAFE is barely known. So it's appropriate to me that WP only lists the most used and known BSAFE implementation. Quetstar (talk) 14:00, 1 August 2021 (UTC)[reply]
@Quetstar: barely known to whom? BSAFE toolkits are widely used in the industry. A quick online search will reveal the extent of its usage... Are § Grandmaster Editor First-Class (or Grand High Togneme Laureate) (which MrOllie will reach in just a few months, congrats btw!!!) expected to know everything about all of their contributions? I don't think so. It goes against WP's purpose to remove the C implementation (MES) because one believes it to be less used, or less known, than the Java implementatiion. Also, in order to claim "less used", someone would need to provide evidence, which no one has done yet. I would appreciated it if contributors to this page were to dome some research before claiming SSL-J is better known and more used than MES. It is general interest to document that there is a C implementation and a Java implementation since both provides different features and capabilities. - Security in mind (talk) 13:04, 2 August 2021 (UTC)[reply]
Users are expected to edit articles in good faith. They are not expected to know everything about them. Furthermore, WP can't list everything in the universe, so only the most notable can be listed. Quetstar (talk) 02:42, 3 August 2021 (UTC)[reply]
That is exactly the point I am trying to make. With all due respect, in a very respectful manner, and I could be totally wrong, but I do not believe MrOllie or yourself has enough knowledge about cryptography and TLS libraries to make a claim that BSAFE is barely known. It is not true that SSL-J is more notable than MES, nor the other way around. Both implementations have their own notoriety. Good faith would be to treat SSL-J and MES as two distinct TLS implementation, used by major technology players, be treated as equally as SChannel and Secure Transport in this page, and allow one row per implementation. This is all I ask. One row per implementation, hence only two rows. Regards - Security in mind (talk) 18:23, 3 August 2021 (UTC)[reply]

Requesting an edit to Certifications

[edit]

The Certifications section is missing details about BSAFE Micro Edition Suite. At the moment, it only lists certifications for BSAFE SSL-J, which gets its FIPS certification from Crypto-J.

My request is to add links to the FIPS certificates of BSAFE Crypto-C Micro Edition[1] [2] [3] [4] [5] [6] [7] [8], as it the underlying FIPS-validated cryptographic provider of BSAFE Micro Edition Suite, a C library providing its own implementation of TLS.[9] while BSAFE Crypto-J is the cryptographic provider of BSAFE SSL-J, a Java library providing its own implementation of TLS[10]

Two different TLS implementation, one in C and one in Java, with their own distinct FIPS certificates. Hence the page should not only list the FIPS certificates of the Java-based provider, it should also list the FIPS certificates of the C cryptographic provider.

You can use the versions and links as provided in the older page revision as a reference.

Format the page as you please, only ensure to add the missing certification details to ensure page accuracy.

Thank you for your consideration. - Security in mind (talk) 00:17, 7 April 2022 (UTC)[reply]

 Not done per above talk page section. - MrOllie (talk) 22:14, 18 April 2022 (UTC)[reply]
May I know which part of the above section please? Is it where I said "As I understand from previous comments, Quetstar and MrOllie are now considering BSAFE MES to be not notable, while they consider BSAFE SSL-J to be notable. Is that right?". Because this looks like it. You are accepting to have the cryptographic provider of SSL-J documented (Java implementation of TLS), but you are refusing to have the cryptographic provider of Micro Edition Suite documented (C implementation of TLS). A confirmation would be most welcomed. - Security in mind (talk) 12:58, 19 April 2022 (UTC)[reply]

References

  1. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/1092
  2. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2047
  3. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2056
  4. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2097
  5. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2217
  6. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2294
  7. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2300
  8. ^ https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3743
  9. ^ "Dell BSAFE Micro Edition Suite 4.6.1 Release Advisory".
  10. ^ "Dell BSAFE SSL-J 6.4 Release Advisory".

Would support for QUIC be an interesting comparison?

[edit]

It sounds like QUIC is coming to TLS implementations like LibreSSL and OpenSSL.

"In a world that is now gradually adopting HTTP/3 (which, as you know, is implemented over QUIC), the problem with the missing API for QUIC is still a key problem.

There are a number of existing QUIC library implementation now since a few years back, and they are slowly maturing. The QUIC protocol became RFC 9000 and friends, but the most popular TLS libraries still don’t provide the necessary APIs to make QUIC libraries possible to use them." - from a blog post by Daniel Stenberg.

Louis Waweru  Talk  22:33, 11 July 2022 (UTC)[reply]

DTLS is not TLS, and still, this page documents if TLS libraries have implemented DTLS. From a realistic point of view, TLS library vendors may end up adding QUIC capabilities to their existing library implementations. Maybe a Yes/No column in the Protocol Support section would be enough, if the goal of this page is to highlight capabilities of TLS libraries.
Note that QUIC § Source code already list libraries that have implemented QUIC. This page here (Comparison of TLS implementations) should not start documenting QUIC capabilities that libraries offer.
I don't have enough knowledge yet about QUIC to decide whether a new page "Comparison of QUIC implementations" should be created based on the high numbers of libraries that have implemented QUIC today (18 so far).
"Should this page document QUIC support? Yes/No" I'm not opposed. Some other users watching this page, having no understanding of the definition of "implementation", may object, especially if you attempt to explain that a C implementation of MsQuic is a completely and 100% different implementation than the C# version. - Security in mind (talk) 12:28, 12 July 2022 (UTC)[reply]
Thank you for pointing these points out, I'm glad I asked. It's a new idea for me too, and wasn't sure if "implement" was a good word choice, because in my mind I am fuzzy on what that means in a comparable way, so I wouldn't be able to follow up as an editor either.
This was more of a check to see if it made sense for the page, and probably some letting my sense of anticipation/curiosity for a "new" idea spill over.
But I agree with you on the letting the QUIC article continue to be the main home for the topic. It does have a nice section already in place, I must have skipped over it before. Louis Waweru  Talk  10:46, 13 July 2022 (UTC)[reply]

Suggest update of Development environment table, wolfSSL row, Build tools column, to include Arduino IDE

[edit]

Hello, I'm an employee of wolfSSL, asked to review the information for the wolfSSL product for accuracy. I am also new to Wikipedia, so please bear with me...

The wolfSSL product includes support for building using the Arduino IDE / sketches, so I'd like to suggest adding "Arduino IDE" to the list of build tools for wolfSSL.

The following are links to content supporting the assertion that wolfSSL supports the Arduino IDE:

Please provide feedback on the suggestion and references. Thank-you! Tim-Weller-wolfSSL (talk) 18:52, 5 December 2022 (UTC)[reply]

I realized there's a proper format for edit requests, so will create an edit request entry related to this content. Tim-Weller-wolfSSL (talk) 14:15, 7 December 2022 (UTC)[reply]

Request addition of Arduino IDE to Development environment table entry for wolfSSL

[edit]

Tim-Weller-wolfSSL (talk) 14:25, 7 December 2022 (UTC)[reply]

Go ahead: I have reviewed these proposed changes and suggest that you go ahead and make the proposed changes to the page. Johannes (Talk) (Contribs) (Articles) 17:30, 27 April 2023 (UTC)[reply]

Consider removing "Proposed curves" table?

[edit]

These curves were indeed once proposed by CFRG, but were not bought forward and there seems to be no movement there for many years post-RFC7748. Given there is no information in this table, perhaps we can remove it? Ctz ctz (talk) 07:42, 29 August 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_TLS_implementations&oldid=1242890243"