Security Laboratory

Security Laboratory

Security Laboratory: Cryptography in Business Series

We are grouping papers in this series to focus on the many facets of data encryption.

Other Related Articles in Security Laboratory: Cryptography in Business Series


SSL/TLS


By Stephen Northcutt
Version 1.3

ssl_tls_june2011_typos

The Secure Sockets Layer (SSL) protocol was developed by Netscape Communications in 1994 to provide application-independent secure communications over the Internet. SSL procedures are most commonly employed on the Web with the Hypertext Transfer Protocol (HTTP) for e-commerce transactions, although SSL is not limited to HTTP. SSL uses cryptography to provide message privacy, message integrity, and client and server authentication, and operates on TCP port 443.

SSL and TLS provide for:
  • Key Establishment
  • Confidentiality with Triple DES-EDE-CBC (and other protocols considered less secure) and TLS supports AES
  • Signature (RSA, DSA) and TLS is considering Elliptic Curve with a draft internet standard
  • Hash MD5, SHA-1

What type of cryptography do SSL and TLS use?

There are many types of cryptographic functions that are used in security protocols. The three most widely known cryptographic features are confidentiality (secrecy of data that would otherwise be transmitted in the clear), integrity (the ability to detect even minute changes in the data), and signature (the ability to trace the origin of the data). The combination of these features creates an important aspect of the overall security of a communications stream. SSL uses four significant types of features: confidentiality, integrity, signature, and key establishment (the way that a key is agreed to by the two parties). SSL uses cipher suites to define the set of cryptographic functions that a client and server use when communicating. This is unlike protocols such as IPsec and S/MIME where the two parties agree to individual cryptographic functions. That is, SSL exchanges say in effect, "Here is a set of functions to be used together, and here is another set I am willing to use." IPsec and S/MIME (and many other protocols) instead say, "Here are the confidentiality functions I am willing to use, here are the integrity functions I am willing to use, and here are the signature algorithms I am willing to use.", and the other side creates a set from those choices.

Just as the SSL client and server need to be able to use the same version of SSL, they also need to be able to use the same cipher suite; otherwise, the two sides cannot communicate. The organization running the SSL VPN chooses which cipher suites meet its security goals and configures the SSL VPN gateway to use only those cipher suites."[A] Two famous workhorse encrypting protocols you might see in use are triple DES and AES.

3DES-EDE-CDC: The Data Encryption Standard (DES) is the most widely used symmetric block cipher. It uses 64 bit blocks and a 56-bit key. Triple DES (also known as 3DES) super-encrypts by running the data through the DES algorithm 3 times with different keys. The first time it Encrypts with key 1, the second time it Decrypts with key 2 and the third time it Encrypts again with key 3, cipher-block chaining (CBC) mode. Each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block is dependent on all plaintext blocks processed up to that point. Also, to make each message unique, an initialization vector must be used in the first block,[1] hence the acronym 3DES-EDE-CDC.

AES: The Advanced Encryption Standard is a FIPS-approved symmetric block cipher encryption algorithm that may be used by U.S. Government organizations (and others) to protect sensitive but unclassified information. AES uses 128, 192, or 256 bit keys, however cipher suites have only been defined for 128 and 256 bit keys to reduce the over proliferation of cipher suites. The block size in AES is 128 bits. The AES algorithm [FIPS197] is designed to replace DES and 3DES. AES is FIPS-approved.[2] For more information about FIPS approved algorithms visit: http://csrc.nist.gov/cryptval/140-1/140val-all.htm#733[3]

SSL: The oldest version of SSL in use today is version 2 (SSL v2), although SSL version 3 (SSL v3) is far more commonly employed. The Internet Engineering Task Force (IETF) updated SSL v3 when they created the non-proprietary Transaction Layer Security (TLS) protocol (RFC 2246). All operate in essentially the same manner. TLS is advertised as SSL v3.1. There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same and the main difference is TLS supports more options.[4]

SSL isn't just for HTTP. Any TCP-based application can be written to take advantage of the security SSL offers. It's quite popular as a method of encrypting traffic between e-mail clients and POP or IMAP servers, or in setting up secure tunnels between IDS sensors and their management consoles, for example. SSL is extremely popular for VPNs.

SSL connections start with a handshake phase to negotiate the type and strength of encryption to use (which, although uncommon in practice, could technically include no encryption if configured that way by the server administrator.) The SSL specification describes several acceptable encryption algorithms, though not every SSL client or server is required to support them all. The negotiation phase ensures that the best algorithm available to both sides is chosen. During the SSL initialization, the server presents a public key certificate to the client, allowing the user's software to verify the server's identity. Clients can present their own certificate as well, which allows the server to verify the user's identity, though this is rare in practice.[5]

SSL: Not a Panacea

SSL is a great way to ensure that the conversation between two parties cannot be understood by anyone else. However, what if one of the two parties is an attacker? By itself, SSL doesn't protect an application from malicious users. The fact is, virtually all Web browsers (and many specialty hacking tools) support SSL, so if an attacker wants to try to break your application, SSL won't stop him. He can generate an encrypted, secure session himself, just like a legitimate user, and still use it to do naughty things to your application. In fact, he may actually prefer this method because the session encryption makes his actions essentially invisible to intrusion detection systems that rely on being able to read the contents of network sessions.

The lesson of this section is "Don't let SSL give you a false sense of security." Know what it protects you from, and more importantly, know what it doesn't protect you from.

It is recommended that you set a directive to disallow SSLv2. Version 2 of SSL hails back to 1994, and uses weaker cryptography and does not protect the key exchange properly. The Apache Slapper worm exploited the key exchange protocol. The Apache Slapper did a "GET" to see if the web server reply included the "Apache" string. It then exploited the MOD_SSL vulnerability, with the backdoor on UDP port 2002, and attempted to create and maintain a communication network between infected machines, each node having the ability to receive and forward commands. This allows a malevolent "master" to mount a distributed DoS attack, in which the single "order" of attack is executed and passed along by all the network participants.[6][7]

SSL is more commonly used, but considered less secure than TLS

The US government mandates the use of TLS, because it supports AES encryption. From the NIST standard: While SSL 3.0 is the most secure of the SSL protocol versions, it is not approved for use in the protection of Federal information because it relies in part on the use of cryptographic algorithms that are not FIPS-Approved. TLS, when properly configured, is approved for the protection of Federal information.[2] However, there are Triple DES SSL implementations that have been evaluated and approved by NIST.[8] But the majority of encrypted web sites and many VPNs still use SSL.

Management Application

If you are running Apache, you may want to check for SSL directives such as SSLRequireSSL (requires SSL before establishing a connection) and SSLProtocol all - SSLv2 (disallows the untrustworthy SSL version 2.) In addition, you can test whether your web site supports TLS, by unclicking SSL; in Firefox 2.0 use Options - Advanced -Encryption.

Firefox Options - Advanced - Encryption

OpenSSL, Politics, and Open Source Validation Feb 2007

The Open Source Software Institute (OSSI) has announced that OpenSSL has regained its FIPS 140-2 validation and is now available for download. The validation process, which normally lasts a few months, took an astounding five years to complete. Those involved with the projects say they are already devising ways to avoid such long delays in future validations. In order for governmental agencies like the Department of Defense to use open source software to manage sensitive data, federal regulations state its security must be validated by the Computer Module Validation Program (CMVP). The CMVP is a joint venture between the US National Institute of Standards and Technology (NIST) and the Canadian agency Communications Security Establishment (CSE). OpenSSL's validation process was managed by the OSSI, whose goal is to encourage the use and development of open source software within educational and governmental agencies.[9][3]

According to Chris Brych, FIPS-140 program manager at DOMUS, the OpenSSL validation posed new challenges in checking it for conformance to requirements because the testing process was not as simple as running the software. Since the source code is freely available, the validation was a proof-of-concept in the event that users decide to compile the toolkit themselves rather than opting for a precompiled version. Having defined a process for the review of a module that is distributed as source code, Brych said the methodology of review for open source software developed during the OpenSSL review process answered questions the CMVP had about delivery of the module and its performance in integrity tests.[10] "What this does is put OpenSSL on a level playing field with all other cryptographic modules and knocks down enormous boundaries," said John Weathersby, executive director of the Open Source Software Institute (OSSI), which helped the project in its validation effort.[11] This is important; because this should mean that this open source software can be used by organizations such as government, financial institutions and others that sometimes cannot use open source software. For more information about OpenSSL, visit: http://www.openssl.org/[12]

A Management Conundrum

What do you do if you find out the version of SSL you are running is vulnerable, but it is FIPS approved. If you are US Government you are only supposed to run FIPS approved SSL. And keep in mind that OpenSSL is not just for freeware users, that codebase is found in a number of commercially supported products. Government managers are strongly advised to take this matter up with their certification and accreditation officials before the next vulnerability is found. And keep in mind that because vulnerabilities have been found in OpenSSL does not mean it is a bad product. On the contrary, because it is open it has been strongly evaluated by many security researchers.


URLs visited July 11, 2007
1. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
2. http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf
3. http://csrc.nist.gov/cryptval/140-1/140val-all.htm#733
4. http://en.wikipedia.org/wiki/Secure_Sockets_Layer
5. http://wp.netscape.com/eng/ssl3/ssl-toc.html
6. http://www.viruslist.com/en/viruslist.html?id=52071
7. http://xforce.iss.net/xforce/alerts/id/advise131
8. http://csrc.nist.gov/cryptval/des/tripledesval.html
9. http://www.linux.com/article.pl?sid=07/02/08/1935232
10. http://trends.newsforge.com/trends/06/01/23/0429219.shtml?tid=136&tid=138
11. http://www.efytimes.com/efytimes/fullnews.asp?edid=9733&magid=
12. http://www.openssl.org/

URLS Visited January 03, 2008
A. http://csrc.nist.gov/publications/drafts/SP800-113/Draft-SP800-113.pdf