SSL & it’s vulnerable components
Hello Readers! Here we go…
A suite is defined roughly by the following attributes:
• Authentication method
• Key exchange method
• Encryption algorithm
• Encryption key size
• Cipher mode (when applicable)
• MAC algorithm (when applicable)
• PRF (TLS 1.2 only — depends on the protocol otherwise)
• Hash function used for the Finished message (TLS 1.2)
• Length of the verify_data structure (TLS 1.2)
Example:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE: Key Exchange
RSA: Authentication
AES: Algorithm
128: bits strength
GCM: Mode
SHA256: MAC
The general practices and required minimum key length depending on the scenario listed below.
• Key exchange: Diffie–Hellman key exchange with minimum 2048 bits
• Message Integrity: HMAC-SHA2
• Message Hash: SHA2 256 bits
• Asymmetric encryption: RSA 2048 bits
• Symmetric-key algorithm: AES 128 bits
• Password Hashing: Argon2, PBKDF2, Scrypt, Bcrypt.
Overall usage of the Cryptographic Primitives
• Starts with a handshake phase that includes authentication (Public-key cryptography)
and key exchange (Diffie-Hellman (DH)) ,
• Follows with the data exchange phase with confidentiality and integrity, and
• Ends with a shutdown sequence.
Symmetric Encryption Algorithm Guidelines
• Current recommendations overall is to use AES-GCM method for block cipher mode.
• Camellia block cipher can be used., preferably with GCM.
• Avoid using RC4 unless does not support AES algorithm, in which case, keep RC4 as the last resort.
• It is not recommended to use 3DES together with perfect forward secrecy ciphers (DHE, ECDHE). Disable 3DES completely, if possible.
• Disable 3DES, DES and IDEA ciphers.
Block Cipher Modes
Recommendations
● Recommended modes include CCM, and GCM as these are specified in NIST approved modes.
● For GCM:
○ Nonce should be generated sequentially or with high enough entropy to avoid repetition
○ Initialisation Vector (IV) can be public, must be random and only used one time
○ 96-bit IV is the recommended way to use GCM according to NIST
● For CCM
○ MAC length should be fixed for each CCM key
○ Follow NIST 800–38C to choose the appropriate MAC length
● If these recommended AE modes are not available
○ combine encryption in cipher-block chaining (CBC) mode with post-encryption message authentication code, such as HMAC or CMAC i.e. Encrypt-then-MAC. Make sure MAC(Authenticate)-then-Encrypt is NOT implemented, it is vulnerable to various kinds of Oracle Padding attacks
○ Most major browsers support the TLS 1.2 standard in which AES-CBC is secure
○ Use 2 independent keys for these 2 independent operations
○ Do not use ECB mode
○ Do not use CBC MAC for variable length data
● Note that Integrity and Authenticity are preferable to Integrity alone i.e. a MAC such as HMAC-SHA256 or HMAC-SHA512 is a better choice than SHA-256 or SHA-512.
Asymmetric Encryption
The recommended strength for RSA today is 2,048 bits, which is equivalent to about 112 symmetric bits.
PKI: Private Key Infrastructure Authentication
You want a cipher suite which is supported by most clients; in practice, this rules out elliptic curve cryptography
● The RSA public key algorithm is widely supported, which makes keys of this type a safe default choice. At 2,048 bits, such keys provide about 112 bits of security. If you want more security than this, note that RSA keys don’t scale very well. To get 128 bits of security, you need 3,072-bit RSA keys, which are noticeably slower.
● ECDSA: Alternate future
The primary benefit of utilizing elliptic curve cryptography (ECC) is a smaller key size which reduces compute, memory, and transmission requirements. This is done while also increasing the overall cryptographic strength
● DSA-least preferred
Key Exchange
• RSA
• Diffie-Hellmann
• ECDH
Message Authentication
The FIPS 180–3 standard defines five hash functions, named SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512, with output lengths of 160, 224, 256, 384 and 512 bits respectively. The SHA-224, SHA-256, SHA-384 and SHA-512 functions are colloquially known as “SHA-2
• Disable the use of MD5 as a hashing mechanism for payload traffic
• Enforce minimum key length : 256-bit for hash functions (e.g., SHA-256, and others)
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 RFC7366
For browsers connecting with TLS 1.2 AES-GCM is preferred, for older TLS versions AES-CBC is preferred. Here is our new recommended cipher suite list:
EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
If you do need to support the 0.0009% of visitors who require RC4, try the following:
EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4!MD5;
Audit Guidelines
For the sake of this document, two scans will be considered to clearly list out the vulnerable components related to SSL.
1. ssl-enum-ciphers.nse
Protocols:
First segment lists the cipher suite for each protocol version in order of preference that are supported by the Client.
1. SSL version 2 and 3 detection is considered a vulnerability due to various exploits (eg. POODLE) available against them.
2. The remote service accepting connections encrypted using TLS 1.0 is considered a vulnerability as well due to a number of cryptographic design flaws.
Cipher Suite
1. Use of medium strength ciphers is also considered a vulnerability. Medium strength cipher refers to any encryption that uses key lengths at least 64 bits and less than 112 bits, or else that uses the 3DES encryption suite.
2. Supporting the use of RC4 in one or more cipher suites is considered a vulnerability because RC4 cipher is flawed in its generation of a pseudo-random stream of bytes so that a wide variety of small biases are introduced into the stream, decreasing its randomness.
Key Exchange
1. SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits is considered a vulnerability. Through cryptanalysis, a third party may be able to find the shared secret in a short amount of time. This may allow an attacker to recover the plaintext or potentially violate the integrity of connections.
2. ssl-cert.nse
1. If the X.509 certificate chain for a service is not signed by a recognized certificate authority, it is considered a vulnerability.
2. The X.509 certificate chain used by a service containing certificates with RSA keys shorter than 2048 bits is considered a vulnerability.
3. SSL certificate chain that has been signed using a cryptographically weak hashing algorithm (e.g. MD2, MD4, MD5, or SHA1) is considered as a vulnerability.
4. Check the expiry date of the certificate and ensure that it is not expired.
General Recommendations:
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
As 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.
Important Resources
https://www.mycugc.org/blog/openssl-pki-for-lab-environments-rsa-and-ecdsa-signature-algorithms
