The Transport Layer Security (TLS) protocol provides the ability to secure communications across or inside networks. This comparison of TLS implementations compares several of the most notable libraries. There are several TLS implementations which are free software and open source.

All comparison categories use the stable version of each implementation listed in the overview section. The comparison is limited to features that directly relate to the TLS protocol.

Overview

TLS/SSL protocol version support 
Several versions of the TLS protocol exist. SSL 2.0 is a deprecated protocol version with significant weaknesses.  SSL 3.0 (1996) and TLS 1.0 (1999) are successors with two weaknesses in CBC-padding that were explained in 2001 by Serge Vaudenay.  TLS 1.1 (2006) fixed only one of the problems, by switching to random initialization vectors (IV) for CBC block ciphers, whereas the more problematic use of mac-pad-encrypt instead of the secure pad-mac-encrypt was addressed with RFC 7366.  A workaround for SSL 3.0 and TLS 1.0, roughly equivalent to random IVs from TLS 1.1, was widely adopted by many implementations in late 2011,. In 2014, the POODLE vulnerability of SSL 3.0 was discovered, which takes advantage of the known vulnerabilities in CBC, and an insecure fallback negotiation used in browsers. 

TLS 1.2 (2008) introduced a means to identify the hash used for digital signatures.  While permitting the use of stronger hash functions for digital signatures in the future (rsa,sha256/sha384/sha512) over the SSL 3.0 conservative choice (rsa,sha1+md5), the TLS 1.2 protocol change inadvertently and substantially weakened the default digital signatures and provides (rsa,sha1) and even (rsa,md5).

Datagram Transport Layer Security (DTLS or Datagram TLS) 1.0 is a modification of TLS 1.1 for a packet-oriented transport layer, where packet loss and packet reordering have to be tolerated.  The revision DTLS 1.2 based on TLS 1.2 was published in January 2012.

TLS 1.3 (2018) specified in RFC 8446 includes major optimizations and security improvements. QUIC (2021) specified in RFC 9000 and DTLS 1.3 (2022) specified in RFC 9147 builds on TLS 1.3. The publishing of TLS 1.3 and DTLS 1.3 obsoleted TLS 1.2 and DTLS 1.2.

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.

NSA Suite B Cryptography 
Required components for NSA Suite B Cryptography (RFC 6460) are:
 Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits. For traffic flow, AES should be used with either the Counter Mode (CTR) for low bandwidth traffic or the Galois/Counter Mode (GCM) mode of operation for high bandwidth traffic (see Block cipher modes of operation) — symmetric encryption
 Elliptic Curve Digital Signature Algorithm (ECDSA) — digital signatures
 Elliptic Curve Diffie–Hellman  (ECDH) — key agreement
 Secure Hash Algorithm 2 (SHA-256 and SHA-384) — message digest

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 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 Top Secret information.

Certifications 
Note that certain certifications have received serious negative criticism from people who are actually involved in them.

Key exchange algorithms (certificate-only) 
This section lists the certificate verification functionality available in the various implementations.

Key exchange algorithms (alternative key-exchanges)

Certificate verification methods

Encryption algorithms 

 Notes

Obsolete algorithms 

 Notes

Supported elliptic curves 
This section lists the supported elliptic curves by each implementation.

Defined curves in RFC 8446 (for TLS 1.3) and RFC 8422, 7027 (for TLS 1.2 and earlier)

Proposed curves

Deprecated curves in RFC 8422 

 Notes

Data integrity

Compression 
Note the 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 attack.

Extensions 
In this section the extensions each implementation supports are listed. Note that the Secure Renegotiation extension is critical for HTTPS client security . TLS clients not implementing it are vulnerable to attacks, irrespective of whether the client implements TLS renegotiation.

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.

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.

Cryptographic module/token support

Code dependencies

Development environment 

 API

Portability concerns

See also
 SCTP — with DTLS support
 DCCP — with DTLS support
 SRTP — with DTLS support (DTLS-SRTP) and Secure Real-Time Transport Control Protocol (SRTCP)

References 

Cryptographic software
TLS implementations
전송 계층 보안 프로토콜은 네트워크 간의 통신을 보호하는 기능을 제공한다. 이 TLS 구현의 비교에서는 가장 알려진 라이브러리를 비교한다.

모든 비교 범주에서 설명 섹션에 나열되어있는 각 구현의 안정 버전을 사용하며 이 비교는 TLS 프로토콜에 직접 관련된 기능에 한정한다.

개요

프로토콜 지원 
TLS 프로토콜에는 여러 버전이 존재한다. SSL 2.0은 심각한 약점을 가지고 폐지 예정이다. SSL 3.0 (1996)과 TLS 1.0 (1999)는 2001년에 Serge Vaudenay 의해 설명된 CBC 패딩 두 가지 약점을 그대로 뒤따르고 있다. TLS 1.1 (2006)는 CBC 블록 암호에 임의의 초기화 벡터 (IV)를 사용하도록 전환하여 여러 문제 중 하나만 해결했던 반면, 안전한 pad-mac-encrypt 대신해 mac-pad-encrypt 문제있는 사용은 RFC7366로 처리되었다. TLS 1.1 랜덤 IV에 상당하는 SSL 3.0 및 TLS 1.0의 해결 방법은 2011년 후반 많은 구현에서 널리 채용되고 있었다. 보안 관점에서는 TLS 1.0, 1.1, 1.2의 모든 기존 버전이 기본 프로토콜에서 동등한 강도를 가지고 NIST SP800-57에 따라서 적어도 2030년까지는 128 비트 보안에 적합하다. 2014년에는 SSL 3.0 POODLE의 취약점이 발견되었는데, 이것은 CBC의 알려진 취약점을 이용하여 브라우저에서 사용되는 안전하지 않은 TLS 버전의 폴백 협상을 할 것이다.

TLS 1.2 (2008)는 기본 프로토콜의 최신 버전이며, 디지털 서명에 사용되는 해시를 식별하는 수단을 도입했다. SSL 3.0 의 보수적인 선택 (rsa, sha1 + md5)에서 미래의 디지털 서명 (rsa, sha256 / sha384 / sha512)에 대해 강력한 해쉬 함수를 사용할 수 있도록 하는 한편, TLS 1.2 프로토콜 변경은 기본 디지털 서명을 고의적으로 상당히 많이 약화시키면서 (rsa, sha1)는 물론 심지어 (rsa, md5)까지 제공한다.

데이터 그램 전송 계층 보안 (DTLS 혹은 Datagram TLS) 1.0은  패킷 손실과 패킷의 정렬을 허용해야 하는 패킷 기반 전송 계층의 TLS 1.1을 변경 한 것이다. TLS 1.2를 기반으로 한  DTLS 1.2 개정판은 2012년 1월에 공개되었다.

SSL 2.0과 SSL 3.0에는 알려진 취약점이 존재한다. 예측 가능한 IV (간단한 해결 방법이 존재함)을 제외하고 현재 알려진 모든 취약점은 TLS 1.0 / 1.1 / 1.2 와 같은 모든 버전에 영향을 미친다.

미국 국가 안보국 (NSA) Suite B 암호화 
NSA Suite B 암호화 ( RFC 6460 )에 필요한 구성 요소 :

·        키 크기가 128 및 256 비트 Advanced Encryption Standard (AES). 트래픽 범위에 대해서는, AES는 대역폭이 낮은 경우엔 카운터 모드 (CTR)에서 사용하고 높은 대역폭의 경우 Galois / Counter Mode (GCM)에서 사용 할 필요가있다 (블록 암호화 / 암호 사용 모드 참조) - 대칭 키 암호화

·        타원 곡선 전자 서명 알고리즘 (ECDSA)- 전자 서명

·        디피 헬만 곡선 (ECDH) - 키 합의

·        SHA-2 (SHA-256 및 SHA-384) - 메시지 다이제스트

각각의 CNSSP-15에 대하여 256 비트의 타원 곡선(FIPS 186-2로 지정), SHA-256 및 128 비트 AES는 '기밀 (Secret)'수준으로 분류되는 정보를 보호하기 위한 것임에 반해 '최고 기밀 (Top Secret)' 의 정보를 보호하기 위해서는 384 비트의 타원 곡선 (FIPS 186-2로 지정), SHA-384 및 256 비트 잠금 장치 AES가 필요하다.

인증

키 교환 알고리즘 (인증서 만) 
이 섹션에서는 다양한 구현에서 사용 가능한 인증서 검증 기능을 나타낸다.

키 교환 알고리즘 (대체 키 교환)

인증서 검증 방법

암호화 알고리즘 

Notes

1.    ^ a b 이 알고리즘은 초안에서 제안된 단계에서 RFC의 TLS 암호 수트로 아직 정의되어 있지 않다.

2.    ^ a b 인증만 암호화 없음

폐지된 알고리즘 

Notes

1.    ^ a b c d IDEA와 DES는 TLS 1.2에서 제거

2.    ^ a b c d e f 특정 강력한 암호화 알고리즘 지닌 암호화 소프트웨어의 수출에 대한 미국의 규제를 준수하기 위해 40 비트 강도 암호화 제품군이 단축 된 키 길이에서 작동하도록 설계되었다. 이러한 약한 스위트는 TLS 1.1 및 그 이후에서는 금지됨.

3.    ^ a b RC4 공격은 SSL / TLS에서 사용되는 RC4를 안전하지 않게 함.  (RC4의 사용은 RFC 7465에서 금지됨)

4.    ^ a b RC4 공격은 SSL / TLS에서 사용되는 RC4는 안전하지 않게 함.

지원되는 타원 곡선 
이 섹션에서는 각 구현에서 지원되는 타원 곡선을 목록으로 만든다.

데이터 무결성

압축 
CRIME 공격은 TLS 압축을 이용하기 때문에, 신중한 구현에서는 TLS 레벨에서의 압축은 사용하지 않는다. 또한 HTTP 압축 무관이 공격의 영향을 받지 않지만, 관련 BREACH 공격에 의해 악용되는 점에 주의가 필요하다.

확장 기능 
이 섹션에서는 각 구현이 지원하는 확장 기능을 나열한다. 안전한 재협상 확장 (Secure Renegotiation extension)은 HTTPS 클라이언트 보안에 중요한 의미를 갖는다. 클라이언트가 TLS 재협상 (TLS renegotiation)을 구현하고 있는지 여부에 관계없이 이 확장을 구현하지 않은 TLS 클라이언트는 공격에 취약하다.

어시스트 암호화 
이 섹션에서는 암호화를 최적화하는 CPU 명령어 세트의 장점을 살린 구현의 알려진 기능이나 하드웨어 암호화 및 데이터 분리의 접근을 허용하는 디바이스의 사용 시스템에 대해 나열한다.

시스템 고유의 백엔드 
이 섹션에서는 사용 가능한 운영 체제 고유의 백엔드 또는 다른 구현에서 제공하는 백엔드를 사용하는 구현의 기능을 나타낸다.

암호화 모듈 / 토큰 지원

코드의 종속성

개발 환경

이식성에 대한 우려

같이 보기 
 SCTP - DTLS 지원
 DCCP - DTLS 지원
 SRTP - DTLS 지원 및 SRTCP (DTLS-SRTP)

참조 

암호 소프트웨어
TLS 구현