Transport Layer Security is a networking protocol that uses multiple forms of cryptography to provide a secure channel. This allows clients and servers to communicate reliably and securely across an open network. In the realm of Internet security there are three main aspects to be concerned with; client-side security, server-side security, and transmission security. Client-side security deals with protecting a user's system. Anti-malware software, firewalls, and web browsers provide security to the user. Server-side security is concerned with preventing unauthorized access as well as denial of service attacks. This is accomplished through the use of hardware firewalls, anti-malware software, and physical security. Secure transmission is the last piece and what TLS was created to address.
Secure Sockets Layer (SSL)
TLS is based on Secure Sockets Layer (SSL), which was developed by Netscape in the early 1990's. Netscape determined that its users needed a way to communicate securely. SSLv1 was used internally but was deemed unsatisfactory for public release. After the shortfalls of SSLv1, Netscape released SSLv2 and included it in the early versions of its browser. At this same time Microsoft had begun work on a similar technology called Private Communications Technology (PCT), which corrected many of SSLv2's weaknesses. As a result, SSLv3 was release by Netscape. It fixed the problems of SSLv2 and added more features not found in Microsoft's PCT. The Internet Engineering Task Force (IETF) began work on an SSL-type protocol in May of 1996. They would combine both Netscape's and Microsoft's approaches to providing secure channels. TLS 1.0 was defined by the IETF in RFC 2246 released in January 1999. RFC pertaining to TLS 1.1 and TLS 1.2 were released in April 2006 and August 2008, respectively (Boncella 953).
Benefits for Users
TLS provides multiple benefits for users. It provides authentication, confidentiality, and data integrity. Authentication is determining if the parties involved are who they claim to be. Digital certificates are used to determine the authenticity of servers and clients. Certificates will be described in more detail later. However, it is important to note that a trusted third party backs these certificates. They are verified, distributed, and digitally signed by a trusted third party called a Certificate Authority (CA). Confidentiality is used to hide the information being transmitted. This is enabled through the use of encryption. Last, integrity ensures that the data is received unmodified. Message authentication codes (MAC) are used to achieve this. Encryption, and MAC's will be covered later in this discussion (Forouzan 1008-9).
Competitive Advantage for Businesses
Users like to feel secure if they are transmitting personal information across the Internet. Using a protocol such as TLS can give them this security. Businesses who make use of this technology can gain an advantage over those who don't. If a business is able to provide this service to their customers they are able to gain their trust. Not only is this a benefit for customers but also for the business itself.
In the world of e-commerce some form encrypted transmission protocol is required. The Payment Card Industry Data Security Standard governs this requirement. This security standard applies to all entities that store, process, or transmit cardholder data. There are 12 requirements that much be met in order to be PCI compliant. One of these states that any cardholder data that is transmitted across open, public networks, such as the Internet, must be encrypted. Recommended protocols include IPSec and SSL/TLS. Digital certificates allow a chain of trust to be established. This chain of trust extends from the server through all of the CA's in the chain. The domain being connected to is verified by an intermediate CA, which is in turn verified by a root CA. The top-level certificate is the only one that is not verified by a third party (PCI Security Standards).
TLS and TCP/IP
Within TCP/IP there are security measures that can be taken at multiple levels. As seen in Figure 1, IP Security (IPsec) can be used at the network layer, SSL/TLS right above the transport layer, and multiple software options at the application layer such as Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extensions (Stallings).
Figure - Security in TCP/IP Layers (Stallings)
TLS operates below upper level protocols, such as HTTP, but above the transport layer protocol TCP. Data from the application layer is handed down to the TLS protocol. TLS then uses cryptographic techniques to enable secure and reliable delivery. This data is then handed down to TCP at the transport layer. TCP provides host-to-host message delivery and error recovery. The location of TLS in the protocol stack provides many advantages. Most importantly, it is application independent. Nearly any application can take advantage of TLS. Some of the more common are HTTP, FTP, SMTP, and LDAP. Since most upper layer protocol can choose to use or not to use TLS we must have a way to distinguish between them. To distinguish between secure and unsecure protocols, typically a different port number is used. For example, unsecure HTTP uses port 80 and secure HTTP (HTTPS) uses port 443. In some cases the same port number can be used for secure and unsecure connection. If the application chooses to use the same port number then the connecting client can request to upgrade the connection to TLS (Stallings).
TLS uses multiple cryptographic concepts and standards to enable its goals of providing authentication of the parties involved, integrity of the data being sent, and confidentiality during transmission. TLS uses symmetric and asymmetric encryption, checksums, digital certificates, and digital signatures. Symmetric encryption is used in order to provide confidentiality of the data exchanged in a TLS connection. It does this by using a shared key between the client and the server. Asymmetric encryption uses a pair of keys in the encryption and decryption process. The keys consist of a public key and a private key. The private key is kept secret and is owned by the entity that generated the key pair. The private key can be used to encrypt information for authentication, or the public key can be used to provide confidentiality (Boncella 957).
Digital signatures and digital certificates provide non-repudiation and authentication to a TLS connection. The CA acts as a trusted third party and is used to verify the authenticity of the server and its public key. The CA verifies the entity and issues a digital certificate to them for use with TLS. Data integrity is insured by the use of message digest algorithms. TLS increases the security of message digests by appending a shared key in the message before calculating the digest value. The resulting value is called a hashed message authentication code (HMAC) (Boncella 957).
All of these concepts come together to form the cipher suite. The cipher suite is a set of cryptographic parameters that govern how a TLS connection is setup and provides secure delivery. It defines three main security parameters. The key exchange mechanism, symmetric encryption algorithm, and MAC algorithm are all defined. An example of a cipher suite is: TLS_RSA_WITH_RC4_128_MD5. This cipher suite defines RSA for the key exchange mechanism, RC4 with a 128-bit key for the symmetric encryption algorithm, and MD5 for the message digest algorithm (Stallings).
TLS Connection Overview
Figure - TLS Protocols (How TLS/SSL Works)
Pictured in Figure2, TLS is composed of four sub-protocols operating at two distinct layers. The Handshake Layer, which is responsible for setting up the connection, and the Record Layer, which is responsible for transmitting and encrypting upper layer data. Within the Handshake Layer reside three upper layer protocols: the Handshake Protocol, Change Cipher Spec Protocol, and the Alert Protocol. The Handshake Protocol is used for setting up the connection, authenticating the parties and enabling the client and server to agree on cryptographic parameters that will be used during the connection. The Changer Cipher Spec Protocol is used after the cryptographic parameters have been agreed upon. It signifies the beginning of encrypted communication using the agreed mechanisms. This protocol is very small, only using a single byte to indicate the switchover. Last, the Alert Protocol "provides exception handling for TLS-secured connections." The Record Layer consists of the Record Protocol. "The Record Layer Protocol encapsulates messages from higher layer protocols including messages from the Handshake, Change Cipher Spec, Alert and application protocols." Prior to encapsulation this data is fragmented into smaller pieces. Depending on the status of the connection these data fragments may or may not be encrypted. If the data is Handshake Protocol data then they will remain in clear text as the connection has not been established. Following the Change Cipher Spec protocol all data fragments are encrypted, including the Alert Protocol and all application data. Before the data is handed to the TCP layer a record header is prepended (Kamil and Gavin, 979).
The record header consists of four fields. These fields are Content Type, Major Version, Minor Version, and Length. The first three fields have a length of 1 byte and the last a length of 2 bytes for a total of 5 bytes. The content type field can have four values: change cipher spec, alert, handshake, and application data. The Major and Minor Version fields indicate the version of TLS being used. Length specifies the length of the data that will follow the record header. TLS also supports compression of application data if negotiated between the client and server. The last piece of a TLS record is the HMAC. Depending on the algorithm being used this field will vary in size. Early in the connection setup this field will be 0 due to the fact that the cipher parameters have not been agreed upon. Once the cipher spec has been agreed upon MD5 or SHA-1 is used. These have a footprint of 16 and 20 bytes, respectively (Stallings).
The Handshake Protocol is the most complicated and important part in TLS. Within this protocol the server and client agree on parameters that will be used to ensure a secure and reliable connection. The Handshake Protocol is encapsulated within the record layer. It consists of three fields: Type, Length, and Content. The type field is 1 byte in length and specifies the handshake protocol Table - Handshake Protocol Message Types (Boncella 960)
message. The handshake message can be 1 of 10 different messages available in the handshake protocol. These are listed in Table 1. The length is the length of the message in bytes and the content field contains the parameters associated with the give message type. These are also listed in Table 1 (Stallings).
Figure - Full TLS Handshake (How TLS/SSL Works)
The full TLS handshake is pictured in Figure 3. It begins when the client initiates the first step of the handshake protocol. The client sends a client hello message type to the server. This message contains the TLS version, a random number, a session id, list of support cipher suites in order of preference, and the supported compression method. The random number will be used in calculating the keys used for encryption. Once this message has been sent the client waits for a server hello message. The server now responds with either an alert specifying handshake failure if there is an error or with a server hello message to continue setting up the connection (Boncella 960).
The server hello contains the supported TLS version, a random number, the session id for the connection, and the selected cipher suite. TLS supports four key exchange mechanisms: RSA, Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, and Anonymous Deffie-Hellman. The supported encryption algorithms include RC2, RC4, DES, 3DES, DES40, and AES. MD5 or SHA-1 are used as the message digest algorithm in computing the HMAC (Stallings).
Immediately following the server hello the server sends its certificate or chain of certificates. The certificates must match the key exchange mechanism defined in the cipher suite. Most certificates follow the X.509.v3 standard.
Depending on the key exchange mechanism a server key exchange message may be sent at this time. If RSA or Fixed Diffie-Hellman is being used the server key exchange message is not necessary. This is because the digital certificate will contain the necessary parameters for either of those algorithms. If Ephemeral or Anonymous Diffie-Hellman are being used the server will send the additional server key exchange message with the parameters for those algorithms (Stallings).
At this point the server can optionally request a client certificate if necessary for the agreed upon cipher suite. Typically the server will send a server hello done signifying that it has sent all the necessary parameters and will await a client response. If the server requested a client certificate the client will send it after receiving the server hello done message. Next, as long as the client has verified the server's certificate, it will send the client key exchange message. The message content will vary depending the cipher suite selected. If RSA is the selected key exchange mechanism, the client will generate and encrypt a 48 byte premaster secret. This premaster secret will later be used in computing the set of keys used for encryption. This will be encrypted with the server's public key found in its certificate and sent to the server. If another algorithm is used the client will use the parameters in the server's key exchange message to either generate or exchange the premaster secret (Boncella 960-61).
It is important to note that the client and server never exchange the master secret key. Using the premaster secret, the phrase "master secret", and the concatenation of the client and server random numbers; the client and server can both generate the same set of keys. These variables are used to compute the master secret. This master secret is then used to generate the set of keys required for TLS. The size of these keys are dependent on the cipher suite negotiated between the client and server. TLS requires four keys to provide message encryption and data integrity. The four keys required are: Client Write MAC Secret, Server Write MAC Secret, Client Write Key, and Server Write Key (How TLS/SSL Works). In some cases two additional keys may be needed if the bulk encryption algorithm uses cipher block chaining mode (Boncella 961).
Each of the computed keys has its own purpose and is known by both the client and server. The client write MAC secret and server write MAC secret are both used to created HMAC values of application data. The client write key and server write key are used for encrypting and decryption. The client will use its write key to encrypt data and the server will use it to decrypt and vice versa with the server write key (How TLS/SSL Works).
Once the client has exchanged the premaster secret the client will send a change cipher spec message. Last, the client will send a finished handshake message. This message contains both MD5 and SHA-1 digest values. The digests are computed on the master secret, and the handshake messages that have been sent. The server completes the same procedure. The client compares the values in its finish message with that of the servers. If the values match then the secure channel has been setup; otherwise the connection may fail (Boncella 961).
Now that the handshake protocol is complete application data can now be sent. The record protocol first takes the application data and fragments it into smaller pieces. The application data is appended with the either the server or clients write MAC secret depending on who is transmitting. An HMAC value is then computed on the application data and write MAC secret. This HMAC value is appended to the application data. The application data and HMAC are encrypted using the write key. The record layer is then passed down to the TCP layer for port addressing and so on (Stallings).
The addition of the TLS handshake process and record protocol leads to additional latency and bandwidth overhead. With a typical HTTP connection, a TCP handshake is completed and then followed by the transfer of HTTP application data. Using TLS, the TCP handshake and TLS handshake must be completed before any data transfer can occur. Depending on the cipher suite selected this can take up to 9 additional steps to setup the connection. On a high bandwidth link the increased bandwidth usage is hardly noticed. However, on a mobile device or a slow link the additional setup time can be noticeable.
In order to calculate the additional bandwidth needed to setup a secure connection, I used Google Chrome and initiated a secure connection to https://www.google.com while simultaneously capturing the traffic using Wireshark. The TLS version used was 1.1 and the negotiated cipher suite was TLS_ECDHE_RSA_WITH_RC4_128_SHA. The bandwidth usage for this TLS handshake from the initial client hello to the final server finished message was 6217 bytes. This also includes all the necessary TCP acknowledgements sent during the handshake process. Again, the bandwidth may differ depending on the cipher suite selected. In addition to the handshake bandwidth, each record layer segment sent includes 5 bytes of header information as well as the appended HMAC. The HMAC can range from 16 - 20 bytes. Therefore, each TLS record sent has at most 25 bytes of header data. The record layer header decreases the amount of application layer data that can be sent in each segment (Boncella 959).
In order to take advantage of TLS the user must use an application that supports it. Typically this is built in to the software package. HTTPS is the most used form of TLS. When considering HTTP access, the user uses a web browser to access a remote web server. For the communication to be secure both the client and the remote server must be configured to support TLS. All of the major web browsers support TLS. The three most widely used are Chrome, Firefox, and Internet Explorer. These require little to no configuration by the user. They come configured for TLS access with preinstalled root certificates. These root certificates come from a number of commercial certificate authorities and prevent the user from having to manually trust most major certificates. On the other end, the server requires much more configuration to provide TLS to the client. The two most common web servers in use today are Apache and Microsoft's Internet Information Services (IIS). These web servers must be configured to allow secure connections as well as have a digital certificates installed. When a secure channel has been established between the browser and the server it will be marked in the browser.
Digital Certificates and Certificate Authorities
Digital certificates are available from a number of different companies. In addition, it is possible to generate your own self-signed certificate. This means that you have no third-party backing your certificate. If the certificate is for internal use only and will not be used by the public a self-signed certificate is efficient. However, if the server will be connected to via the Internet a certificate backed by a CA is crucial. In fact, some web browsers will not allow a connection to a TLS site with a self-signed certificate.
These certificates are available from companies such as Thawte and Symantec (formerly VeriSign.) The VeriSign authentication unit was bought by Symantec in 2010, this included the SSL division, as well as the public key infrastructure. Each of these companies offers a variety of certificates. The level of validation required for a company as well as the type of data being secured will determine
the needed certificate. All of the certificates listed in Table 2 have a 1-year validity period and only secure a single domain with the exception of the wildcard certificate. The basic certificates have the lowest level of verification. They are typically issued in 1 business day and are recommended for some web server applications or internal use. The next level, web server certificate, requires a more in depth verification process that is typically a full organization validation. These are recommended for public and employee websites that require a logon. The next level of certificates comes with extended validation. This is the most secure and highest level of validation. These types of certificates are typically identified in a web browser with a green bar beside the URL and can take up to 10 days to receive. The green bar assists in conveying a sense of established trust to the user. They are recommended for all websites transmitting credit card ata. A wildcard certificate is usually the most expensive and can be used to secure multiple domains with the same certificate. These have the same level of verification as a web server certificate (Symantec and Thawte).
Table - Certificate Pricing (Symantec and Thawte)
Web Server Certificate
Certificate with EV
According to research by Qualys conducted in their Internet SSL Survey 2010, there were 867,361 web servers with valid certificates. This data was derived from "All .com, .net, .org, .biz, .us, and .info domain names." As well as domains from Alexa.com's top 1 million sites, which is updated daily. Of the 119 million domain names only 22.65 million were active on port 443 and only the 867,361 were valid. The researcher attributed this large number of invalid certificates to the widespread use of virtual web hosting. When using virtual web hosting a single server or IP address may host multiple sites and point to the same SSL/TLS server. Many of the sites are not meant to be secure but appeared that way because the certificate on that IP address does not match each site. One IP address can only represent one SSL/TLS host. Out of the 867,361 certificates 30% failed validation. This is from a number of reasons including, but not limited to, expiration of the certificate, using a self-signed certificate, and using an unknown CA. The researcher also found that nearly all of the servers support SSL 3.0 and TLS 1.0. In addition, it was found that TLS 1.1 and TLS 1.2 are hardly in use at all with 838 and 11 servers respectively. Of the two CA's outlined in the previous paragraph they accounted for 115,495 certificates; 54,948 for Thawte and 60,547 for Symantec (VeriSign). The two most used CA's in the data set were Go Daddy and Equifax. Overall, 18 CA's accounted for 97% of the certificates (Ristic).
Management of TLS
The client side management aspect of TLS is minimal. The technology is built into all major web browsers which come loaded with trusted root certificates. Nearly all management tasks take place at the server. During the TLS handshake the server selects the cipher suites to be used for the connection. This can be configured on the server to only setup connections using certain cipher suites. It is important that the server is set enforce a certain level security by disabling cipher suites with known vulnerabilities or enforcing a certain key size. Key security and management is handled at the server as well. The server contains the private key of its public/private key pair. Security must be managed to ensure this key is not compromised. If this key is compromised it could be used to decrypt communications between a client and the server. A domain or company can require certificates for multiple secure domains. The expiration date must be tracked to ensure the certificate is valid and renewed to prevent expiration. In a Windows domain environment certificates can be managed at a domain level. The trust root certificate authorities can be managed as well intermediate certificate authorities forcing domain computers to have a specific set of certificates if desired.
Due to the location of TLS in the protocol stack lower layer IP addresses are not encrypted. Using these IP addresses it may be possible to determine the source and destination locations. TLS only provides secure transmission. For an example we will use a credit card number. TLS is capable of transmitting a credit card number to a destination server securely. However, once it arrives at the server TLS is not responsible for verifying these numbers, performing credit card authorization, or processing the transaction. Nor is TLS responsible for how the number is cached or stored on the server. TLS can be susceptible to man in the middle attacks (MITM). This can occur when a middleman intercepts the traffic between a client and server involved in a TLS handshake. The middleman appears as a server to the client and as a client to the server. The intermediary relays the data between the client and server and can in some cases decrypt the data between them. This is mitigated through the use of certificates from CA's (Boncella 963).
The Bureau of Industry and Security control exporting cryptographic systems from the US. Restrictions exist if the system will be exported to countries with known terrorist organizations. Custom cryptography software and cryptography consulting can also require licenses. In addition, the Bureau of Industry and Security must be notified before any open-source cryptography software is released on the Internet (Encryption FAQs).
Alternatives to TLS
IPsec is a clear alternative to TLS. It operates at the network layer and encrypts all transport and application layer data. More so than TLS, IPsec is application independent. Since it operates at the network layer no configuration is needed for application layer protocols. IPsec is typically used for VPN connections. It can be more difficult to setup than TLS and requires third-party software. Specifically in the area of e-commerce secure electronic transaction (SET) is sometimes used. This protocol was developed through collaboration between Microsoft, Netscape, Mastercard, and Visa. Unlike TLS and IPsec, SET is specifically used for credit card transactions and integrates authentication, confidentiality, as well as message integrity. Since the initial release of TLS 1.0 there have been two minor versions released, 1.1 and 1.2. As seen in the SSL Survey conducted by Qualys, these versions are not yet widely used. TLS 1.1 added protection against a known cipher block chaining vulnerability and 1.2 added SHA-256 support as well AES encryption (Boncella 963).