Identifying SSL/TLS Ciphers

Increasingly communication across networks and the Internet are using SSL/TLS to protect the transactions, this has been driven by a raft of legislation that is mandating the use of strong encryption, examples of such regulations, law and standards from around the world are listed below.

• PAYMENT CARD INDUSTRY DATA SECURITY STANDARD (DSS)
• GRAMM-LEACH-BLILEY ACT (GLBA)
• SARBANES-OXLEY ACT (SOX)
• BASEL II ACCORD
• EURO-SOX
• Financial Instruments and Exchange Law of 2006
• HEALTH INSURANCE PORTABILITY & ACCOUNTABILITY ACT (HIPAA)
• FDA TITLE 21 CFR PART 11 (1997)
• 95/46/EC EUROPEAN UNION (EU) DIRECTIVE
• BUNDES-DATENSCHUTZ-GESETZ (BDSG)
• CALIFORNIA SENATE BILL 1386 (SB 1386)
• PERSONAL INFORMATION PROTECTION & ELECTRONIC DOCUMENTS ACT (PIPEDA)
• DATA PROTECTION ACT (DPA) OF 1984 (AMENDED 1998)
• PERSONAL INFORMATION PROTECTION LAW (PIPL) OF 2003

The SSL/TLS protocols are used by the HTTPS protocol to encrypt web pages and data entered into them. There are a number of versions of SSL/TLS which are in use; SSL was developed by Netscape for transmitting private documents via the Internet. TLS was developed by the Internet Engineering Task Force (IETF) to provide similar functionality to SSL..

SSLv1 - Never Published
SSLv2 - released in February 1995
SSLv3 - released in 1996 (RFC 6101, Historical document)
TLSv1.0 - released in January 1999 (RFC 2246)
TLSv1.1 - released in April 2006 (RFC 4346)
TLSv1.2 - released in August 2008  (RFC 5246)

Both SSL and TLS use cryptographic systems to encrypt data, the actual cryptographic system used is negotiated during the SSL/TLS handshake where the cipher suite is selected and encryption keys are generated and exchanged. Both use the asymmetric encryption using the website certificate to exchange the private keys for symmetric encryption.

In order for SSL/TLS to be acceptable for the encryption of cardholder data in order to comply with requirements for strong encryption such as section 4 of the PCI DSS, the negotiation phase should result in the use of a strong cipher. This requires the server to support versions of SSL and TLS that do not have well know vulnerabilities and use cipher suites based on strong cryptography. The capabilities of a server using HTTPS are advertised by the certificate and the initial phase of negotiating the key exchange.

TLS/SSL supports a large number of cipher suites, where the cipher suite is a combination of symmetric and asymmetric encryption algorithms used to establish secure communication.
Supported cipher suites can be classified based on encryption algorithm strength, key length, key exchange and authentication mechanisms. Some cipher suites offer a stronger level of security than others (e.g. weak cipher suites were developed for export to comply with US export law).

Understanding cipher suites

There are a number of different naming conventions

The Open SSL naming convention, which is probably the most common uses at least nodes in the naming of the ciper suite

• key exchange,
• server certificate authentication,
• stream/block cipher
• message authentication

For example

DHE-RSA-AES256-SHA

DHE for key exchange, RSA for server certificate authentication, 256-bit key AES for the stream cipher, and SHA for the message authentication.

Often the cipher name is prefixed with the protocol such as SSL or TLS and an additional node to indicate the mode used in the stream/block cipher such as

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Which indicates it is for TLS and uses cipher block chaining in the implementation of 256 bit key AES. Some additional terms that may be found are

• Anon - Anonymous cipher suites with no key authentication. Highly vulnerable to man in the middle attack.
• Export -  Intentionally crippled cipher suite to conform to US export laws. Symmetric cipher used in export cipher suites typically does not exceed 56bits.
• NULL - Null cipher suites do not provide any data encryption and/or data integrity

Auditing and compliance

One of the problems for those tasked with auditing or ensuring compliance with the regulations/standards is know what strength cryptography has been deployed on the servers.

Vulnerability assessment tools that assess the security profile of servers using SSL/TLS will integrator the server to assess its capabilities and will attempt to connect using all versions of SSL and TLS and a range of ciphers from the weak to the strongest. If the tool supports a PCI DSS test will report if the server is secure to the requirements of the standard. However even without a specific PCI DSS test for secure servers the tools will report the capabilities of the server which can be examined to see if the requirements of the standard are being met. The Nessus scanner has the capability of checking SSL services on arbitrary ports, and will report weak ciphers and includes a PCI DSS audit checks.

The nmap scanner, when used with the service/version scan “–sV” option will identify SSL services. Additionally tools such as openSSL can be used to manually audit

openssl s_client -no_tls1 -no_ssl3 -connect <server_Name>:443

Other tools are sslscan which is included in BackTrack and the ssl_tests script can be used.

References

http://www.thesprawl.org/research/tls-and-ssl-cipher-suites/
http://en.wikipedia.org/wiki/Transport_Layer_Security
http://en.wikipedia.org/wiki/Cipher_suite
http://www.openssl.org/docs/apps/ciphers.html
http://www.iana.org/assignments/tls-parameters/tls-parameters.txt
http://www.pentesterscripting.com/discovery/ssl_tests