TLSVersion enum

SSL_2_0

SSL version 2.0 see RFC 6176 — Prohibiting SSL Version 2.0. Conclusion: INSECURE.

SSL version 2.0 [SSL2] deficiencies include the following:

Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151].

Handshake messages are not protected. This permits a man-in-the-middle to trick the client into picking a weaker cipher suite than it would normally choose.

Message integrity and message encryption use the same key, which is a problem if the client and server negotiate a weak encryption algorithm.

Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session.

SSL_3_0

SSL version 3.0 see RFC 7568 — Deprecating SSL Version 3.0. Conclusion: INSECURE.

SSL version 3.0 Is Comprehensively Broken:

Record Layer The non-deterministic padding used in the Cipher Block Chaining (CBC) construction of SSLv3 trivially permits the recovery of plaintext [POODLE]. More generally, the CBC modes of SSLv3 use a flawed MAC- then-encrypt construction that has subsequently been replaced in TLS versions [RFC7366]. Unfortunately, the mechanism to correct this flaw relies on extensions: a feature added in TLS 1.0. SSLv3 cannot be updated to correct this flaw in the same way.

The flaws in the CBC modes in SSLv3 are mirrored by the weakness of the stream ciphers it defines. Of those defined, only RC4 is currently in widespread use. RC4, however, exhibits serious biases and is also no longer fit for use [RFC7465].

This leaves SSLv3 with no suitable record protection mechanism.

Key Exchange The SSLv3 key exchange is vulnerable to man-in-the-middle attacks when renegotiation [RFC5746] or session resumption [TRIPLE-HS] are used. Each flaw has been fixed in TLS by means of extensions. Again, SSLv3 cannot be updated to correct these flaws.

Custom Cryptographic Primitives SSLv3 defines custom constructions for Pseudorandom Function (PRF), Hashed Message Authentication Code (HMAC), and digital signature primitives. Such constructions lack the deep cryptographic scrutiny that standard constructions used by TLS have received. Furthermore, all SSLv3 primitives rely on SHA-1 [RFC3174] and MD5 [RFC1321]: these hash algorithms are considered weak and are being systematically replaced with stronger hash functions, such as SHA-256 [FIPS180-4].

Limited Capabilities

SSLv3 is unable to take advantage of the many features that have been added to recent TLS versions. This includes the features that are enabled by ClientHello extensions, which SSLv3 does not support.

Though SSLv3 can benefit from new cipher suites, it cannot benefit from new cryptographic modes and features. Of these, the following are particularly prominent:

• Authenticated Encryption with Additional Data (AEAD) modes are added in [RFC5246].
• Elliptic Curve Diffie-Hellman (ECDH) and Digital Signature Algorithm (ECDSA) are added in [RFC4492].
• Stateless session tickets [RFC5077].
• A datagram mode of operation, DTLS [RFC6347].
• Application-layer protocol negotiation [RFC7301].

TLS_1_0

TLS version 1.0 see RFC 8996 — Deprecating TLS 1.0 and TLS 1.1. Conclusion: INSECURE.

TLS 1.0 MUST NOT be used. Negotiation of TLS 1.0 from any version of TLS MUST NOT be permitted. Any other version of TLS is more secure than TLS 1.0. While TLS 1.0 can be configured to prevent some types of interception, using the highest version available is preferred.

The integrity of both TLS 1.0 and TLS 1.1 depends on a running SHA-1 hash of the exchanged messages. This makes it possible to perform a downgrade attack on the handshake by an attacker able to perform 277 operations, well below the acceptable modern security margin.

Similarly, the authentication of the handshake depends on signatures made using a SHA-1 hash or a concatenation of MD5 and SHA-1 hashes that is not appreciably stronger than a SHA-1 hash, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash.

Neither TLS 1.0 nor TLS 1.1 allows the peers to select a stronger hash for signatures in the ServerKeyExchange or CertificateVerify messages, making the only upgrade path the use of a newer protocol version.

TLS_1_1

TLS version 1.1 see RFC 8996 — Deprecating TLS 1.0 and TLS 1.1. Conclusion: INSECURE.

TLS 1.1 MUST NOT be used. Negotiation of TLS 1.1 from any version of TLS MUST NOT be permitted.

The integrity of both TLS 1.0 and TLS 1.1 depends on a running SHA-1 hash of the exchanged messages. This makes it possible to perform a downgrade attack on the handshake by an attacker able to perform 277 operations, well below the acceptable modern security margin.

Similarly, the authentication of the handshake depends on signatures made using a SHA-1 hash or a concatenation of MD5 and SHA-1 hashes that is not appreciably stronger than a SHA-1 hash, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash.

Neither TLS 1.0 nor TLS 1.1 allows the peers to select a stronger hash for signatures in the ServerKeyExchange or CertificateVerify messages, making the only upgrade path the use of a newer protocol version.

TLS_1_2

TLS version 1.2 see RFC 5246 — TLS Protocol Version 1.2. Conclusion: WEAK.

TLS 1.2 supports both Diffie-Hellman and RSA algorithms for key exchange. However, the RSA algorithm uses a static key, that, when stolen, can allow the attacker to decrypt communications even after several years.

TLS 1.2 uses a complex cipher suite that includes support for encryption algorithms and ciphers with known cryptographic weaknesses. While the complexity results in the poor choice of the cipher suite, support for weak security mechanisms amplifies the risks of encryption attacks. To address these issues, TLS 1.3 uses a simple cipher suite that supports only those algorithms and ciphers that currently have no known vulnerabilities. It has dropped support for SHA-1, RSA key exchanges, the RC4 cipher, CBC-mode ciphers, MD5, and a few more that can potentially cause downgrade attacks.

TLS_1_3

PROTOCOL_DTLS_1_0_OPENSSL_PRE_0_9_8F

TLS_1_3_DRAFT_16

TLS_1_3_DRAFT_18

DTLS_1_0

Datagram Transport Layer Security (DTLS) see RFC 7525 — Recommendations for Secure Use of TLS and DTLS. Conclusion: INSECURE.

DTLS is based on TLS 1.0 and MUST NOT be used. Negotiation of TLS 1.0 from any version of TLS MUST NOT be permitted. Any other version of TLS is more secure than TLS 1.0. While TLS 1.0 can be configured to prevent some types of interception, using the highest version available is preferred.

The integrity of both TLS 1.0 and TLS 1.1 depends on a running SHA-1 hash of the exchanged messages. This makes it possible to perform a downgrade attack on the handshake by an attacker able to perform 277 operations, well below the acceptable modern security margin.

Similarly, the authentication of the handshake depends on signatures made using a SHA-1 hash or a concatenation of MD5 and SHA-1 hasches that is not appreciably stronger than a SHA-1 hash, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash.

Neither TLS 1.0 nor TLS 1.1 allows the peers to select a stronger hash for signatures in the ServerKeyExchange or CertificateVerify messages, making the only upgrade path the use of a newer protocol version.

DTLS_1_2

DTLS 1.2 see RFC 6347 — DTLS version 1.2 DTLS 1.2 is based on TLS version 1.2 see RFC 5246 — TLS Protocol Version 1.2. Conclusion: WEAK.

TLS 1.2 supports both Diffie-Hellman and RSA algorithms for key exchange. However, the RSA algorithm uses a static key, that, when stolen, can allow the attacker to decrypt communications even after several years.

TLS 1.2 uses a complex cipher suite that includes support for encryption algorithms and ciphers with known cryptographic weaknesses. While the complexity results in the poor choice of the cipher suite, support for weak security mechanisms amplifies the risks of encryption attacks. To address these issues, TLS 1.3 uses a simple cipher suite that supports only those algorithms and ciphers that currently have no known vulnerabilities. It has dropped support for SHA-1, RSA key exchanges, the RC4 cipher, CBC-mode ciphers, MD5, and a few more that can potentially cause downgrade attacks.

DTLS_1_3

UNKNOWN