Transport Layer Security (
TLS) and its predecessor,
Secure Sockets Layer (
SSL), both frequently referred to as "SSL", are
cryptographic protocols that provide
communications security over a
computer network.
[1] Several versions of the protocols find widespread use in applications such as
web browsing,
email,
Internet faxing,
instant messaging, and
voice-over-IP (VoIP).
Websites are able to use TLS to secure all communications between their
servers and
web browsers.
Vulnerabilities
DROWN
CVE-2016-0800,
or Decrypting RSA with Obsolete and Weakened eNcryption (DROWN), is a
vulnerability that affects servers still supporting SSLv2 or servers
that share a private key with any other server that allows SSLv2 (even
for other protocols such as email). It allows an attacker who has an
effective man-in-the-middle to break the encryption of a TLS connection
in under eight hours with a variant being achievable in one minute. The
attack takes many hundreds of requests which can be achieved by the user
visiting a load intensive application or alternatively being coerced in
to visiting a site which can make a large number of cross-site
requests. The target application can use any protocol suite including
TLSv1.2 as long as the requirement for SSLv2 is also met, additionally
RSA key exchange must be used. This issue can be combined with
CVE-2015-3197 which is an OpenSSL vulnerability that allows SSLv2 connections to be made even in no SSLv2 ciphers are enabled.
References
https://drownattack.com/
https://drownattack.com/drown-attack-paper.pdf
CRIME
Compression Ratio Info-leak Made Easy (CRIME) is an attack against
TLS/SSL, but it has a much smaller probability of exploitation. The
authors of CRIME also wrote the BEAST attack. The attacker requires a
man-in-the-middle connection and the ability to repeatedly inject
predictable data whilst monitoring the resulting encrypted traffic. This
could be achievable through Cross-site scripting attacks; JavaScript is
not required and an attack could be possible with HTML Injection alone
however it would be less efficient.
For CRIME to be possible the client and server must support
compression of the request before encryption. TLS supports DEFLATE which
is vulnerable, as is SPDY.
BEAST
Browser Exploit Against SSL/TLS (BEAST) is a practical attack was
found to be possible against TLS v1.0 and SSLv3.0 (and below) when a
block cipher is in use. Effectively an attacker is able to determine the
Initialisation Vector utilised as part of the encryption process
meaning that if a repeating pattern is evident in the plaintext then it
will be evident in the ciphertext. However, it is of limited use an it
is only possible to retrieve small pieces of data, such as session
tokens. The attacker must be able to man-in-the-middle a connection and
there must be a way of generating additional traffic such as an SOP
bypass or a Cross-site Scripting vulnerability. The user must be using
an older web browser, as modern browsers protect against this issue. If
all of these conditions are met and session tokens are protected against
XSS through a mechanisms such as HttpOnly cookies then an attacker may
exploit BEAST to gain access to these protected tokens.
Remediation
Enforce TLS v1.1 and above
Alternatively you could accept the risk and rely on the protections
offered by modern browsers, or alternatively prefer RC4 ciphers to
mitigate beast but introduce their own issues.
References
https://www.gracefulsecurity.com/what-is-beast/
BREACH
CVE-2013-3587,
or Browser Reconnaissance and Exfiltration via Adaptive Compression of
Hypertext (BREACH) is an instance of CRIME against HTTP Compression.
That is to say that CRIME attacked TLS SPDY whereas BREACH targets HTTP
gzip/DEFLATE. Therefore turning off the TLS compression has no affect on
BREACH as it exploits the underlying HTTP compression. The attack
follows the basic steps of the CRIME attack and there are several
methods to remediate the issue, such as disabling HTTP compression,
protecting the application from CSRF attacks, randomising CSRF tokens
per request to prevent them being captured, obfuscating the length of
page responses by adding random amounts of arbitrary bytes to the
response.
References
https://bugzilla.redhat.com/show_bug.cgi?id=995168
FREAK
CVE-2015-0204, CVE-2015-1637, CVE-2015-1067, or Factoring RSA Keys
(FREAK), is a vulnerability that allows an positioned attacker with a
man-in-the-middle attack to reduce the security offered by SSL/TLS by
forcing a connection to use “Export-grade” grade encryption – which
reduces the RSA strength to 512 bits, which is breakable by attackers
with a modest budget (In 2015 researchers showed this to be about $104
on Amazon EC2 instances). However breaking keys is still computationally
expensive and slow, however an attacker may not require to break a key
for every session due to implementation details – for example with
Apache mod_ssl a single key was generated at boot time and used for all
connections. Export-grade refers to US law which restricted the use of
strong cryptography.
References
https://blog.cryptographyengineering.com/2015/03/03/attack-of-week-freak-or-factoring-nsa/
Logjam
CVE-2015-4000,
or “Logjam”, is a vulnerability which affects TLSv1.2 and below which
allows a man-in-the-middle attacker to downgrade the encryption to
512-bit export grade cryptography, which is breakable by attackers with a
modest budget (In 2015 researchers showed this to be about $104 on
Amazon EC2 instances).
References
https://weakdh.org/
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
NOMORE
Numerous Occurrence MOnitoring & Recovery Exploit, or “RC4
NOMORE”, is a practical attack against RC4 which allows a HTTP Cookie to
be retreived within 52 hours, given an effective man-in-the-middle
attack. The developers of the NOMORE attack also noted there were
several optimisations that could be made to their work to further reduce
this time.
References
https://www.rc4nomore.com/
Bar Mitzvah
CVE-2015-2808,
or “Bar Mitzvah”, relates to a vulnerability known as the Invariance
Weakness which allows for small amounts of plaintext data to be
recovered from an SSL/TLS session protected using the RC4 cipher.The
attack was described at Blackhat Asia 2015. It requires a positioned
attacker with a man-in-the-middle attack capable of capturing
“many millions” of requests. This vulnerability allows a positioned
attacker to recover the least significant bit of as many as 100 bytes
from the encrypted stream.
References
https://www.blackhat.com/docs/asia-15/materials/asia-15-Mantin-Bar-Mitzvah-Attack-Breaking-SSL-With-13-Year-Old-RC4-Weakness-wp.pdf
SWEET32
CVE-2016-2183,
or “SWEET32”, relates to a birthday attack against 64-bit block ciphers
such as DES and 3DES. It requires a positioned attacker with a
man-in-the-middle attack capable of capturing a long-lived HTTPS
connection. The original proof of concept showed that it was possible to
recover secure HTTP cookies by capturing around 785 GB of traffic, by
generating traffic through malicious JavaScript. Effectively therefore,
this vulnerability allows a positioned attacker to bypass the
protections offered by the “secure” flag on cookies when used in
conjunction with a vulnerability such as a SOP bypass or Cross-site
Scripting.
DES-CBC3-SHA
References
https://sweet32.info/
https://www.openssl.org/blog/blog/2016/08/24/sweet32/
SSL POODLE
CVE-2014-3566,
SSL Padding Oracle On Downgraded Legacy Encryption Vulnerability
(POODLE) is a vulnerability affecting SSLv3 where a block cipher is
enabled utilizing the CBC cipher mode. It requires a man-in-the-middle
attack and the ability for the attacker to cause the application to send
the same data over newly created SSL3.0 connections but allows an
attacker to decipher a chosen byte of cipher text in as few as 256
attempts. This vulnerability is an issue in the specification not a
specific implementation issue. Additionally if a service prefers TLS
over SSLv3 it may be possible to ‘roll back’ the connect if the TLS
Fallback SCSV mechanism is not enabled.
References
https://www.imperialviolet.org/2014/10/14/poodle.html
Any SSLv3 block cipher with CBC
TLS POODLE
CVE-2014-8730,
TLS Padding Oracle On Downgraded Legacy Encryption Vulnerability
(POODLE) is a vulnerability affecting certain implementations of TLS.
Originally the attack was described against SSLv3 although later
expanded with certain limitations. This vulnerability is implementation
specific, but known to affect F5 products.
References
https://www.imperialviolet.org/2014/12/08/poodleagain.html
https://support.f5.com/csp/#/article/K15882
Heartbleed
CVE-2014-0160, or “Heartbleed”, is not an issue in SSL/TLs
specifically, but instead was an implementation issue in OpenSSL
affecting versions 1.0.1 through 1.0.1f. It can be fixed either through
upgrading to a more recent version of OpenSSL or alternatively compiling
with the option -DOPENSSL_NO_HEARTBEATS. It does not require a
Man-in-the-Middle to exploit and can be exploited against both the
server and the client. The issue allows an attacker to extract up to
64kb of memory from the vulnerable system, which can lead to the theft
of credentials, session tokens and server private keys.
References
http://heartbleed.com/
Cipher Suites
RC2
RC2 ciphers are considered to offer only a low amount of security as
their key length. Low strength ciphers are considered to be those with a
key length <= 64-bits.
EXP-RC2-CBC-MD5
RC4
RC4 ciphers are known to be vulnerable to a number of issues such as
the “Invariance Weakness” first described in 2001. Several attacks have
been discussed, such as the “Bar Mitzvah attack” demonstrated at
Blackhat Asia 2015. This algorithm is also referred to as ARC4 or
ARCFOUR (for Alleged RC4) in some contexts due to the term RC4 being
trademarked. The most notable attack is likely the RC4 NOMORE attack
which can recover a TLS protected HTTP cookie in as little as 52 hours.
ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, ECDHE-RSA-RC4-SHA, ECDHE-ECDSA-RC4-SHA, AECDH-RC4-SHA, ADH-RC4-MD5, ECDH-RSA-RC4-SHA, ECDH-ECDSA-RC4-SHA, PSK-RC4-SHA, KRB5-RC4-SHA, KRB5-RC4-MD5, EXP-RC4-MD5, RC4-64-MD5, RC4-MD5, RC4-SHA
DES
DES is a 64-bit block cipher and is therefore affected by the “SWEET32” vulnerability described in CVE-2016-2183.
Additionally it is marked as a “Medium” strength cipher which is
below the recommended level. Medium strength ciphers are those with a
key length at least 56 bits and less than 112 bits.
ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5, ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5, ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5, ECDHE-RSA-DES-CBC3-SHA, ECDHE-ECDSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, DH-RSA-DES-CBC3-SHA, DH-DSS-DES-CBC3-SHA, AECDH-DES-CBC3-SHA, ADH-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, ECDH-ECDSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, KRB5-DES-CBC3-MD5
3DES
3DES uses a 64-bit block cipher and is therefore affected by the “SWEET32” vulnerability described in CVE-2016-2183.
PSK-3DES-EDE-CBC-SHA, PSK-3DES-EDE-CBC-SHA, PSK-3DES-EDE-CBC-SHA, PSK-3DES-EDE-CBC-SHA
NULL
The NULL cipher suites simply inform the browser not to encrypt data,
therefore effectively nullifying any protection given through the use
of SSL/TLS.
ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, ECDHE-RSA-NULL-SHA, ECDHE-ECDSA-NULL-SHA, AECDH-NULL-SHA, ECDH-RSA-NULL-SHA, ECDH-ECDSA-NULL-SHA, NULL-SHA256, NULL-SHA, NULL-MD5, RSA-NULL-SHA256
Hashing
SHA-1
Both Microsoft and Google have announced that it is inappropriate to
use. Microsoft, when speaking about SSL/TLS for HTTPS noted back in 2013
that they will no longer be supporting SHA1 as a security algorithm
past 2016. Google had a similar announcement stating they will be
penalising companies for using SHA1 during 2016 and no longer supporting
it post-2016 – that announcement and a little further information is
available here:
https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html. Microsoft also published the following article which shows movement towards deprecation in Internet Explorer and Edge:
https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#Jeb54DCIEtIIcY4r.97
References
https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#Jeb54DCIEtIIcY4r.97
https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html
Certificate Issues
Self-Signed Certificates are those which have not been signed by a
recognized certificate authority. These effectively nullify the
protections offered by SSL/TLS as an attacker can simply create their
own “forged” certificate and the end user would have no way of knowing
that the certificate was no the one that should be expected – therefore
allowing a positioned attacker to establish a man-in-the-middle attack
to capture all encrypted data and to modify both client requests and
server responses. This is different to a certificate which is signed by
an unrecognized Certificate Authority (CA) as the attacker would not be
able to forge these certificates specifically although the client may
have the Certificate Authority as trusted within their local store; this
situation is often found on internal corporate networks where the
company have implemented their own CA.
Certificate with Wrong Hostname
If the Common Name does not match the hostname of the server then a
user may not be able to determine if the certificate is for that service
or not, this generally results in a security error within web browsers
and requires the user to “click through” the message to view the
application. This would also prevent a user from visiting the
application
if HSTS is enabled.
This would likely require some degree of social engineering to be
useful to an attacker attempting to man-in-the-middle a connection,
however users may be used to clicking through the error message when
visiting this service and therefore not notice the illegitimate
certificate.
https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
