Content deleted Content added
→Certifications: BSAFE SSL-J using Crypto-J 7.0 for FIPS 140-3. |
m {{sort-under}} |
||
Line 8:
== Overview ==
{{sort-under}}
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 208 ⟶ 209:
Note that there are known vulnerabilities in SSL 2.0 and SSL 3.0. In 2021, IETF published RFC 8996 also forbidding negotiation of TLS 1.0, TLS 1.1, and DTLS 1.0 due to known vulnerabilities. NIST SP 800-52 requires support of TLS 1.3 by January 2024. Support of TLS 1.3 means that two compliant nodes will never negotiate TLS 1.2.
{| class="wikitable sortable sort-under mw-collapsible" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 533 ⟶ 534:
Per CNSSP-15, the 256-bit elliptic curve (specified in FIPS 186-2), SHA-256, and AES with 128-bit keys are sufficient for protecting classified information up to the [[United States security clearance#Secret|Secret]] level, while the 384-bit elliptic curve (specified in FIPS 186-2), SHA-384, and AES with 256-bit keys are necessary for the protection of [[United States security clearance#Top Secret|Top Secret]] information.
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 594 ⟶ 595:
Note that certain certifications have received serious negative criticism from people who are actually involved in them.<ref>{{Cite web|url=http://index.html/|archiveurl=https://web.archive.org/web/20131227190128/http://veridicalsystems.com/blog/secure-or-compliant-pick-one/|url-status=dead|title=Speeds and Feeds › Secure or Compliant, Pick One|archivedate=December 27, 2013}}</ref>
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! rowspan="2"|Implementation
Line 692 ⟶ 693:
== Key exchange algorithms (certificate-only) ==
This section lists the certificate verification functionality available in the various implementations.
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 951 ⟶ 952:
== Key exchange algorithms (alternative key-exchanges) ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 1,161 ⟶ 1,162:
== Certificate verification methods ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 1,319 ⟶ 1,320:
== Encryption algorithms ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! rowspan="2"|Implementation !! colspan="10"|[[Block cipher]] with [[Block cipher mode of operation|mode of operation]] !! [[Stream cipher]] !! None
Line 1,639 ⟶ 1,640:
=== Obsolete algorithms ===
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! rowspan="2"|Implementation !! colspan="4"|[[Block cipher]] with [[Block cipher mode of operation|mode of operation]] !! colspan="2"|[[Stream cipher]]
Line 1,871 ⟶ 1,872:
=== Defined curves in RFC 8446 (for TLS 1.3) and RFC 8422, 7027 (for TLS 1.2 and earlier) ===
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! applicable TLS version
Line 2,078 ⟶ 2,079:
=== Deprecated curves in RFC 8422 ===
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 2,356 ⟶ 2,357:
|}
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 2,570 ⟶ 2,571:
== Data integrity ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 2,728 ⟶ 2,729:
== Compression ==
Note the [[CRIME (security exploit)|CRIME security exploit]] takes advantage of TLS compression, so conservative implementations do not enable compression at the TLS level. [[HTTP compression]] is unrelated and unaffected by this exploit, but is exploited by the related [[BREACH (security exploit)|BREACH attack]].
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 2,786 ⟶ 2,787:
In this section the extensions each implementation supports are listed. Note that the Secure Renegotiation extension is critical for HTTPS client security {{citation needed|date=August 2014}}. TLS clients not implementing it are vulnerable to attacks, irrespective of whether the client implements TLS renegotiation.
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 3,128 ⟶ 3,129:
== Assisted cryptography ==
This section lists the known ability of an implementation to take advantage of CPU instruction sets that optimize encryption, or utilize system specific devices that allow access to underlying cryptographic hardware for acceleration or for data separation.
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 3,358 ⟶ 3,359:
== System-specific backends ==
This section lists the ability of an implementation to take advantage of the available operating system specific backends, or even the backends provided by another implementation.
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 3,482 ⟶ 3,483:
== Cryptographic module/token support ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 3,567 ⟶ 3,568:
== Code dependencies ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 3,624 ⟶ 3,625:
== Development environment ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
Line 3,759 ⟶ 3,760:
== Portability concerns ==
{| class="wikitable sortable sort-under" style="text-align: left; font-size: smaller"
|-
! Implementation
| |||