When a person connects to a web server and sees that the communication uses the HTTPS protocol (for example, they see a lock icon in the connection), they have the impression that the data is being securely transmitted to the server. But this may not be true if the server is not properly configured or if we are using an outdated client. The extreme case is that a cipher suite that does not actually perform encryption can be used (although this sentence sounds nonsensical, such cipher suites do exist). Therefore, every web server administrator should pay attention to this area, and the information can also be useful for users (there are various clients that support newer protocols, but have them disabled by default).
The second question concerns various vulnerabilities, several of which have been discovered this year that are very serious. These can cause old encrypted data to be insecure, current encryption to be breakable, or even future data to be at risk.
Note: When I had already prepared this article, a new vulnerability in the SSL 3 protocol, known as POODLE, was disclosed on 14.10.2014. I have added it to the article, but I have not rewritten the whole thing. It is now recommended to disable the SSL 3 protocol as it is considered unsafe (this should only affect the IE 6 client). Otherwise, 3DES, AES (or others) with CBC (vulnerable to BEAST, POODLE) vs RC4 (vulnerable) must be considered. The issue is mentioned, for example, in the document This POODLE Bites: Exploiting The SSL3.0 Fallback. In connection with the POODLE attack, for example, Firefox announced that it will not support SSL 3 in future versions.
SSL/TLS Principle and Cipher Suites
SSL/TLS creates an encrypted stateful connection (session), at the beginning a handshake is performed, where both parties negotiate the connection parameters (including the cipher). A server certificate is always used (so there is also identity verification) and a client certificate may also be used. The client generates a pre-master secret (secret), which it encrypts with the server's public key from the certificate and sends. Here, asymmetric cryptography (public-key encryption) is used, and only the server, which owns the private key, can decrypt the data.
The client and server perform a defined series of steps on the pre-master secret to create the master secret. They then apply the agreed hash function to it and create the session key, which is a symmetric key used for encrypting and decrypting the connection (session). The actual communication is therefore encrypted using symmetric cryptography with the session key.
Protocols
The RFC currently defines the SSL 2, SSL 3, TLS 1.0, TLS 1.1, TLS 1.2 protocols. SSLv2 contains several security flaws, so it has been considered unsafe for a long time. At least SSLv3 or its successor TLS should be used. The recommendation is to use only TLSv1.1 and TLSv1.2, where the BEAST attack and others are not a threat. However, most browsers and applications support at most TLSv1.0 by default. Support for TLSv1.2 is often available, but not enabled by default (e.g. IE 9, 10, Java 7), default support is only in the latest versions (IE11, Firefox 32, Android 4.4.2, Java 8, etc.). Newer protocol versions add support for newer ciphers and remove the unsafe ones.
Forward Secrecy
From the perspective of today's security, it is important to mention a property of Key Exchange protocols called Forward Secrecy (FS) or Perfect Forward Secrecy (PFS). Simply put, it ensures that the server's private key cannot be used to derive old session keys. New keys (created in a non-deterministic way) are used for each session, and they are discarded after the session ends. A more detailed description can be found, for example, in the article Perfect forward secrecy.
Of the protocols used for SSL/TLS, only Diffie-Hellman Ephemeral (DHE) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) support Forward Secrecy. The use of elliptic curves is more advantageous because it is less computationally intensive.
Cipher Suite
When using SSL/TLS, a specific cipher (cipher suite) is used, more precisely a cipher suite (named combination of authentication and encryption algorithms and a (hash) authentication code (MAC - Message Authentication Code, something like a hash function)).
Each Cipher Suite specifies several algorithms for different operations:
- Key Exchange - exchange (agreement) of encryption keys for further communication, initial public-key cryptography, examples RSA, Diffie-Hellman (DH, DHE, ECDH, ECDHE), PSK. Greater security is achieved by using an algorithm that supports Forward Secrecy, i.e. DHE and ECDHE. For overall security, the public key in the X.509 certificate also matters, a key size of 1024 bits (for RSA, DSA) is no longer recommended, and a secure hash algorithm (not MD5) should be used for signing.
- Authentication - verifying the identity of the server (if client authentication is used, then also the identity of the client), examples RSA, DSS, ECDSA, in the notation a combination of authentication and key exchange is used, if both are RSA, it is written only once, for example RSA, DH-RSA, ECDHE-RSA, ECDHE-ECDSA, DHE-DSS. It depends not only on the allowed algorithm, but also on the server certificate (its keys), which is most often RSA, so only RSA can be used for authentication.
- Encryption - symmetric encryption of the session, also includes key size and initialization vector length, examples RC4, DES, 3DES, AES, Camellia, IDEA, RC2
- Message Authentication Code (MAC) - creating a hash for packet integrity checking and authentication, examples SHA, MD5, MD4, MD2 for SSL, HMAC-MD5, HMAC-SHA1, HMAC-SHA256 for TLS
Examples of Cipher Suites:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_RSA_WITH_RC4_128_MD5 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 SSL2_RC4_128_WITH_MD5
A list of all possible ciphers can be found in many places, for example Transport Layer Security (TLS) Parameters - TLS Cipher Suite Registry or TLS and SSL Cipher Suites. We can also use OpenSSL Ciphers.
Weak Ciphers
Ciphers are divided into three categories based on cryptographic strength, they are weak, medium, and strong. Ciphers that can be broken within a usable time frame are considered weak. There is probably no precise definition of which ciphers are weak, and their list changes due to new hardware and the discovery of flaws. Currently, the following rules are often used.
Note: In some materials (such as Qualys SSL Labs) I have also encountered a fourth category of untrusted (insecure), which is even below the weak cipher.
One of the main parameters for the division is the cipher key size in bits, anything with 64 bits or less is considered weak (because it can be broken by brute force methods). DES uses a 56-bit key, so it is overall weak. SSL version 2 is considered weak due to flaws. RC2 and RC4 have exploitable weaknesses, so they are weak. RSA authentication with a 1024-bit key size is considered unsafe and therefore weak (a larger key size can be used). Cipher Suites that contain NULL (no encryption) or EXPORT (small keys due to US export rules) are weak.
MD5 has been gradually phased out due to its poor reputation, but is not yet considered weak. It is now also stated that the minimum cipher key size will be 128 bits in the future, so even 3DES (using 112 or 108 bits) will be weak. Due to the current POODLE vulnerability, the entire SSL version 3 protocol is now being labeled as weak/untrusted. The recommendation for the future is to use only TLS 1.1 and TLS 1.2 (but be aware of client support).
In the area of security and certificates, there has been a lot of talk since September 2014 about the transition from SHA-1 to SHA256. Public certification authorities are starting to default to issuing certificates with SHA-2, and a SHA-1 certificate can only be issued with a limited validity. A brief description is provided in the article SHA1 Deprecation: What You Need to Know.
Weak ciphers are commonly used on web servers, partly due to compatibility, even though these are very legacy applications that require it. So it is recommended to adjust the settings and block weak ciphers.
Vulnerabilities
In addition to weak ciphers, another danger lies in known vulnerabilities in libraries or attacks on the protocol. Some weaknesses of algorithms have been known for a long time, but it is only recently that it has been discovered how to practically exploit them. We do not go into this area too much here, but here is a list of the most well-known vulnerabilities along with how to work around them:
- Heartbleed bug (CVE-2014-0160) - a flaw in the OpenSSL library, update to an OpenSSL version without this flaw
- OpenSSL CCS vulnerability (CVE-2014-0224) - a flaw in the OpenSSL library, update to an OpenSSL version without this vulnerability
- BEAST (Browser Exploit Against SSL/TLS) - a vulnerability in the CBC (Cipher Block Chaining) of the SSL and TLSv1.0 protocols, removed in the TLSv1.1 version, affects all protocols that contain CBC in the name, so only RC4 remains, the solution is to use only TLSv1.1 and TLSv1.2 or for SSL and TLSv1.0 use RC4 (which is not considered secure), the protection against the BEAST attack is now found in all modern browsers (so it is not so necessary to solve it on the server)
- CRIME (Compression Ratio Info-leak Made Easy) - a general attack, do not use SSL compression
- BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) - similar to CRIME, possible only under special conditions, the solution is not to use HTTP compression
- RC4 - weaknesses in the algorithm were discovered in 2013, it is recommended not to use it
- POODLE (Padding Oracle On Downgraded Legacy Encryption - CVE-2014-3566) - similar to BEAST, a vulnerability in CBC only in SSL 3.0, the recommendation is not to use SSL 3, otherwise use only RC4
Security Standards
For the weak ciphers, we have presented various recommendations on how to securely configure the SSL/TLS protocol. Of course, we always need to balance security and usability, so that clients can connect. There are also general standards, and if we want to comply with them, we need to follow certain settings. These are the PCI (Payment Card Industry) standards, which focus on working with credit cards, and FIPS 140-2 (Federal Information Processing Standard), which are relatively strict US government standards.
Testing SSL/TLS for Used Ciphers
We can find out that weak ciphers are used (offered) on a web server (the most common case, but it can also be various other services) from penetration tests that we have performed ourselves (e.g. the Open Source tool OpenVAS) or obtained from a specialized company. But we can also use specialized tools, which are either applications or online services (the first two in the following list), and they will perform the testing for us. These tools are referred to in various ways as SSL Audit, SSL Scan, SSL Test, etc.
Let's briefly mention some of the used applications. In this article, we focus on the use of weak ciphers in the SSL/TLS protocol (primarily for the web, but also for other services). Many testing applications perform more SSL protocol checks and also verify known vulnerabilities such as the Heartbleed bug, OpenSSL CCS vulnerability, BEAST attack, CRIME attack, RC4 attack.
Note: For various SSL tests and establishing a connection, we can also use OpenSSL (there are many possibilities), e.g. openssl s_client -connect www.google.com:443 -ssl3
Qualys SSL Labs - SSL Server Test
The very nice and useful online service SSL Server Test will test the SSL/TLS on the web server and rate its security with a grade. It displays information about the certificate (including whether the server also provides the authority certificate), allowed protocols and ciphers (with a lot of information and weak cipher labeling), tests various vulnerabilities and security properties of the protocol, and emulates different browsers and devices (we will learn whether they can connect and which protocol/cipher they will use).
XMPP IM Observatory
Another online service that focuses on the security of Jabber communication servers (XMPP protocol) and, among other things, displays the offered SSL/TLS ciphers. It runs at the address IM Observatory.
Network Mapper
Security scanner NMAP, is a native Linux tool that has also been ported to Windows. It quickly finds basic information about the certificate and prints out the offered ciphers along with the classification. It's a great tool for quick testing. It can test not only HTTPS, but also SMTP and XMPP, for example.
Note: The advantage is also that we can use a single command to test a series of servers and ports. Both can be written using a list of values or ranges (with a hyphen) separated by commas.
nmap --script ssl-cert,sslv2,ssl-enum-ciphers -p 443 www.google.com Starting Nmap 6.47 ( https://nmap.org ) at 2014-10-02 16:26 Central Europe Daylight Time Nmap scan report for www.google.com (74.125.24.104) Host is up (0.028s latency). Other addresses for www.google.com (not scanned): 74.125.24.105 74.125.24.103 74.125.24.147 74.125.24.99 74.125.24.106 rDNS record for 74.125.24.104: de-in-f104.1e100.net PORT STATE SERVICE 443/tcp open https | ssl-cert: Subject: commonName=www.google.com/organizationName=Google Inc/stateOrProvinceName=California/countryName=US | Issuer: commonName=Google Internet Authority G2/organizationName=Google Inc/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Not valid before: 2014-09-24T09:48:54+00:00 | Not valid after: 2014-12-23T00:00:00+00:00 | MD5: 9aa9 d2b3 a059 fca1 a99d 64df 242d ba51 |_SHA-1: 510d 8d10 ab63 d42b e652 291e fc7f 4b19 7027 38ba | ssl-enum-ciphers: | SSLv3: | ciphers: | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong ... Nmap done: 1 IP address (1 host up) scanned in 4.09 seconds
TestSSLServer
The tool TestSSLServer is tiny, written in Java and used from the command line. It works quickly, displays a list of supported ciphers, rates the weakest cipher, and tests the BEAST and CRIME vulnerabilities. If the protocol is written as idem, it means that the values are the same as for the previous one. It's a good choice for quick cipher list output, unfortunately it only works with HTTPS.
d:\>java -jar TestSSLServer.jar www.google.com 443
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
SSLv3
RSA_WITH_RC4_128_MD5
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
(TLSv1.0: idem)
(TLSv1.1: idem)
TLSv1.2
RSA_WITH_RC4_128_MD5
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA256
RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
----------------------
Server certificate(s):
510d8d10ab63d42be652291efc7f4b19702738ba: CN=www.google.com, O=Google Inc, L=M
ountain View, ST=California, C=US
----------------------
Minimal encryption strength: strong encryption (96-bit or more)
Achievable encryption strength: strong encryption (96-bit or more)
BEAST status: protected
CRIME status: protected
SSL Vulnerabilities Analyzer
An interesting Windows graphical application is the SSL Vulnerabilities Analyzer. It performs various SSL, vulnerability, and cipher tests and displays summary results with the ability to view details.
SSLScan - Fast SSL Scanner
A small command-line tool SSLScan is designed for Linux, but there is also a Windows port of SSLScan. On Windows, it is a functional tool that can scan various ports (supports not only HTTPS, but also SMTP). By default, it prints all ciphers, but we can limit it to only the accepted ones. Its function is limited to just displaying ciphers and does not perform classification. Additionally, it only supports SSL and TLS 1.0 (even after changing the OpenSSL libraries, it does not work with TLS 1.1 or TLS 1.2).
d:\>SSLScan.exe --no-failed www.google.com
_
___ ___| |___ ___ __ _ _ __
/ __/ __| / __|/ __/ _` | '_ \
\__ \__ \ \__ \ (_| (_| | | | |
|___/___/_|___/\___\__,_|_| |_|
Version 1.8.2-win
https://www.titania.co.uk
Copyright Ian Ventura-Whiting 2009
Compiled against OpenSSL 0.9.8m 25 Feb 2010
Testing SSL server www.google.com on port 443
Supported Server Cipher(s):
Accepted SSLv3 256 bits AES256-SHA
Accepted SSLv3 128 bits AES128-SHA
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5
Prefered Server Cipher(s):
SSLv3 128 bits RC4-SHA
TLSv1 128 bits RC4-SHA
SSL Certificate:
Version: 2
Serial Number: -4294967295
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=US/O=Google Inc/CN=Google Internet Authority G2
Not valid before: Sep 24 10:48:54 2014 GMT
Not valid after: Dec 23 00:00:00 2014 GMT
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
Public Key Algorithm: rsaEncryption
SSLAudit
SSLAudit is a Perl tool that should test ciphers and rate them by grade. The downloaded zip contains a compiled exe for Windows and a standalone Perl script, but I couldn't get this tool to work, even after installing StrawberryPerl and adding the Encode module (cpan / install Encode).
SSL Audit (alpha)
Another graphical tool for Windows, which is quite slow, scans ciphers and rates their strength, is also called SSL Audit.
SSLmap
Another small testing tool sslmap is written in Python, so it requires its interpreter. It only displays a list of ciphers.
$ python sslmap-0.2.0.py --host thesprawl.org
_
| | version 0.2.0
___ ___| |_ **_** ** ***** ***
/ **/ **| | '_ ` \ / ` | '_ \
\__ \__ \ | | | | | | (_| | |_) |
|___/___/_|_| |_| |_|\__,_| .__/
| |
iphelix@thesprawl.org |_|
[*] Scanning thesprawl.org:443 for 229 known cipher suites.
[+] TLS_RSA_WITH_AES_128_CBC_SHA (0x00002F)
[+] TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015)
...
CipherScan
A simple Linux script CipherScan also provides a quick overview of ciphers.
linux $ ./cipherscan www.google.com:443 ................... prio ciphersuite protocols pfs_keysize 1 ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 ECDH,P-256,256bits 2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits 3 ECDHE-RSA-AES128-SHA TLSv1.1,TLSv1.2 ECDH,P-256,256bits 4 ECDHE-RSA-RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits 5 AES128-GCM-SHA256 TLSv1.2 6 AES128-SHA256 TLSv1.2 7 AES128-SHA TLSv1.1,TLSv1.2 8 RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 9 RC4-MD5 SSLv3,TLSv1,TLSv1.1,TLSv1.2 10 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits 11 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits 12 ECDHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits 13 AES256-GCM-SHA384 TLSv1.2 14 AES256-SHA256 TLSv1.2 15 AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 16 ECDHE-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits 17 DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 18 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits Certificate: trusted, 2048 bit, sha1WithRSAEncryption signature
Skvela stranka, bolo by mozne informacie na nej aktualizovat? Napr. podpora prehliadacov na TSL vyssich verzii atd.
respond to [1]Mikulas Pauco: Bohužel, absolutně není čas :-(