SSL and TLS Explained

Print Friendly, PDF & Email

Recently there have been several high-profile vulnerabilities involving SSL and TLS.   Many people do not know how to determine the version of SSL and TLS that is in use on a system.  This article will cover the basic constructs of TLS (Transport Layer Security) and SSL (Secure Sockets Layer).

SSL is the predecessor to TLS, and both use X.509 certificates. This is called asymmetric cryptography.  I will explain both asymmetric and symmetric cryptography in this blog post.

Symmetrical ciphers are the oldest known method of encryption. A symmetrical cipher can be encrypted and decrypted using the same key. A symmetrical key is as simple as taking the letters in the alphabet and shifting them a specific number of places. For example, if I want to send a message to someone of “hey the redcoats are coming” I could send the following “mjceyljewjihtfyxefwjehtrnsl” with the key of “5” the key is what is used to decipher the code. In this very simple symmetrical cipher the 5 means that the alphabetical characters are moved 5 places.

A becomes F, B becomes G, C becomes H, and so on. The space character is added to the end of the alphabet to further complicate the cipher. So instead of Y becoming D It becomes C and Space becomes E. If we change all instances of ‘e’ to spaces, this is what we get:

mjceyljewjihtfyxefwjehtrnsl

mjc ylj wjihtfyx fwj htrnsl

hey the redcoats are coming

Alphabet for our key (note: the underscore is the space character)

The problem with symmetrical encryption is that in order to decrypt the message, the sender needs to get the key to the recipient. If the key is intercepted, the message can be decrypted by someone other than the intended recipient.

To mitigate the issue of key exposure, asymmetrical encryption was invented.   Asymmetric encryption is also known as public key encryption. This type of encryption requires two keys to encrypt plain text. One key is known publicly while the other is only known to the owner. A public key can be used to encrypt the text. However it can only be decrypted with the matching private key.

In Asymmetrical encryption, the two entities exchange public keys.  Each party uses the other's public key to encrypt the message. The other party uses its own private key to decrypt the message.

With this type of encryption it is not necessary to transmit or send the recipient the key to decrypt because the recipient already has the decryption key. All the sender has to do is to use the public key provided by the recipient to encrypt the message and then nobody except the recipient can read the message. Also if the message is encrypted with the private key it can be decrypted with the public key.  This is the basis for the name, as asymmetrical means one way encryption.

Because computers are capable of very efficient brute force attacks, the keys have become much more complicated using very complex algorithms.
SSL and TLS are capable of using a multitude of ciphers (algorithms) to create the public and private key pairs. RC4 is an example of a weak cipher that is not effective in protecting data any more. This is why using SSL v3.0 is a bad idea. RC4-SHA is the highest encryption cipher available in the SSL v.3.0 suite.

A strong cipher would be AES, which is available in TLS v1.0, TLSv.1.1 and v.1.2.  To see all ciphers available from strongest to weakest, run this command from any Linux command line:

#openssl ciphers -v 'ALL:!ADH:@STRENGTH'

A brief history of SSl and TLS Versions are as follows in order:

• SSL v. 1.0
• SSL v. 2.0
• SSL v. 3.0
• TLS v. 1.0
• TLS v. 1.1
• TLS v. 1.2
• TLS v. 1.3 (currently in draft)

Each new version offers new ciphers and key sizes not previously available in the predecessor version. Many of the same ciphers are available in multiple versions of SSL and TLS.

SSL certs are used for many reasons, from encrypting messages to establishing trust.

As explained previously encrypting messages using SSL/TLS is as simple as using a public or private key to encrypt the message and using the opposite key to decrypt the message.

A certificate can also be used to establish whether a web site is trustworthy. In order to establish trust, we need to establish a chain of trust. Trust starts with a Certificate Authority (CA). This can be a server in a network or a 3rd party CA. A certificate created from your Domain CA is trusted only in your local domain. If you have an outward facing web interface that needs to be trusted you would use a certificate generated from a 3rd party Certificate Authority that is authorized to certify World Wide Web domains. Each CA has a root certificate which identifies them as a Certificate authority. The CA’s root certificate is the first certificate in the trust. The root certificate is used to create a number of Intermediate CA Root Certificates (ICA), which create the trust hierarchy. The final certificate in the chain is the signed certificate. This certificate identifies the device that is serving HTTPs on the web.

Below is an illustration of a full chain bundle in .pem format. Notice that the chain of trust runs from the bottom up in the chain bundle.

SSL and TLS are opportunistic with their cipher suites. What this means is that they will use the strongest encryption available in their suite that is also available on the other end of the connection. If you find an issue where a weak cipher is being used, you can check both ends of the connection to determine the strongest possible cipher:

To check a SSL connection (HTTPS):
#openssl s_client -connect :443 -showcerts

To check a mail server using TLS:
#openssl s_client -connect :25 -starttls smtp -showcerts

We have had some cases where customers have been using a weak cipher even though their configurations were set to use a high cipher. If you find yourself in this circumstance, the first thing to do is check both interfaces. That is, check your interface (or your customer's interface), and check the interface on the other side of the connection. SSL and TLS are opportunistic and will use the highest cipher available on both ends of the communication.

You may be using TLS v. 1.2 with AES256-SHA on your end as the highest cipher, but on the other end they may be using SSL v3.0 with RC4-SHA as their highest cipher. This is the cipher that will be used as this is the highest cipher that both ends can communicate using.

Here is an example of openssl query on a SSL interface:
openssl s_client -connect 24.97.125.194:443 -showcerts

CONNECTED(00000003)
depth=0 /C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
verify return:1
---
Certificate chain
0 s:/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
   i:/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
-----BEGIN CERTIFICATE-----
MIICjDCCAfWgAwIBAgIEU9cMJDANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJV
(certificate abbreviated for space constraints)
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
issuer=/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
---
No client certificate CA names sent
---
SSL handshake has read 828 bytes and written 355 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 4E36015736D7DF91A4459D4C8E8D31D05B6D5BD5318185024026AFC5A643709F
    Session-ID-ctx:
    Master-Key: A6579CBB82C2B62626FCF82B7A15781C17887BF74B4AB4796B87FD24C25F59009CEFCE574868BB8D67E2BFBD083F2146
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1415288412
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

This SSL Certificate is using TLS v. 1 with a max cipher of AES256-SHA. With this certificate, we can also negotiate with ciphers as low as the ones found in SSL v.3. This is a self-signed certificate, and the public key for this cert is 1024 bit.

If you have any questions about the SSL and TLS on your Barracuda solutions, you can give our support department a call or submit a ticket. We are happy to help.

Scroll to top
Tweet
Share
Share