This caused large numbers of TLS sessions to break during the TLS 1.1 rollout and allow attackers to attack older SSL versions. Many broken TLS implementations in widespread use were unable to cope with versions they did not understand. The server selects the highest version it supports, and sends the negotiated version number in the ServerHello message. Clients advertise the highest version of the protocol they support.
TLS agents should negotiate the highest version of the protocol supported by client and server. If the server supports SSLv3 is vulnerable to POODLE attack. This may allow decryption of communications and disclosure of session cookies.
Under certain conditions, it is possible to conduct a “padding oracle” attack against ciphers using cipher-block chaining (CBC) mode. Otherwise, the server will respond with uncompressed data, indicating that it is not vulnerable. If the response contains encoded data, it indicates that HTTP compression is supported therefore the remote host is vulnerable. This vulnerability can be check using Nmap: The following versions of OpenSSL are not vulnerable: * OpenSSL 1.0.1 through 1.0.1f (inclusive) The following versions of OpenSSL are vulnerable: The server will respond with random data from its memory. The problem is, in OpenSSL 1.0.1 to 1.0.1f, an attacker can trick OpenSSL by sending a single byte of information but telling the server that it sent up to 64K bytes of data that needs to be checked and echoed back. * The certificate is not expired Vulnerabilities Heartbleedĭuring communication, OpenSSL uses a “heartbeat” message that echoes back data to verify that it was received correctly. * Common Name, Subject Alt Name and Issuer are congruent The following attributes should be checked: Openssl s_client -connect :443 | openssl x509 -noout -text "Export" algorithms should also be disabled as their short key lengths make them susceptible to brute-force attacks and other attacks such as the FREAK attack. * For all three algorithms, the NULL / anon setting should be avoided as these provide no security at all. MD5 is known to be cryptographically weak and should be avoided, and SHA1 (just denoted SHA in the cipher suite specifications) has its own weaknesses which place attacks within the realm of possibility. * The message authentication algorithm should ideally be SHA256. An alternative is Galois Counter Mode (GCM) which is not affected by these problems and offers authenticated encryption. * Cipher-Block Chaining (CBC) mode is prone to padding oracle attacks and should ideally be avoided altogether, but specifically it should not be used in conjunction with SSLv3 or TLSv1.0 as this can lead to vulnerability to the BEAST attack. * The cipher should use at least a 128 bit key (which rules out DES and Triple-DES). This rules out RC4 which has been known to have flaws for many years and in the past few years has been shown to be significantly weaker than originally thought. * The cipher should not suffer from known cryptanalytic flaws. * The key exchange algorithm should be restricted to those which provide "perfect forward secrecy", such as Ephemeral Diffie-Hellman (DHE) or Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).
0 kommentar(er)
