Transport Layer Security

Transport Layer Security (TLS; German transport layer security ), wide known under the previous name of Secure Sockets Layer ( SSL), is a hybrid encryption protocol for secure data transmission over the internet. Since version 3.0, the SSL protocol is being developed and standardized under the new name TLS, with version 1.0 of TLS version 3.1 of SSL correspond. In this article, the acronym TLS is used for both of these terms, unless it is explicitly made ​​to the old versions reference. Known implementations of the protocol are OpenSSL and GnuTLS.

TLS in practice

TLS encryption is now used mainly with HTTPS. Most web servers support TLS 1.0, SSLv3 and SSLv2 many also with a variety of encryption methods, almost all browsers and servers, however, put preferred TLS using RSA and AES or Camellia encryption. In current browsers SSLv2 is disabled or leads to a security warning because this protocol version has a number of security vulnerabilities. The development TLS 1.1 is supported by Google Chrome, TLS 1.2 is used in the default configuration of Internet Explorer, Firefox, Google Chrome, Opera and Apple iOS Safari uses (as of 02/ 2014).

Recently, more and more website owners extended validation certificates to use TLS (EV -TLS certificate). In the address line of the browser in addition, a box appears, certificate and domain owner will alternate with the certificate authority ( eg VeriSign or TC TrustCenter ) appear in the. In addition, depending on the browser and / or add-on used the address bar ( in part) is colored green. Internet users should see even faster if the site I'm visiting is genuine, and be better protected against phishing attempts.

TLS is vulnerable without a certificate-based authentication for Man-In - The-Middle Attacks: Is the man-in -the-middle before the handover of the key active, it can both sides pretend his keys and then record all traffic in plain text. Given the lack of trustworthiness of some CAs security of TLS is generally doubted since early 2010.

In conjunction with a virtual server, for example, HTTP (such as the Apache HTTP Server via the VHost mechanism), it is generally to be regarded as a disadvantage that for each combination of IP address and port only one certificate can be used, since the actual user of the overlying protocol were (and hence the name of the vhosts ) at the time of the TLS handshake not yet been transferred. This problem was corrected with the Server Name Indication TLS extension in June 2003 by the RFC 3546. It is already being sent with the connection setup, the desired server name. The original extension was described for TLS 1.0, due to the compatibility of the individual TLS versions each SNI is also implemented in TLS 1.1 and TLS 1.2 according to the recommendation.

Other known uses for TLS are POP3, SMTP, NNTP, SIP, IMAP, XMPP, IRC, LDAP, MBS / IP, FTP, EAP -TLS, TN3270 and OpenVPN.

History

Operation

The client establishes a connection to the server. Usually the server to the client first authenticates with a certificate. Then either the client sends the server a message encrypted with the public key of the server secret random number, or the two parties compute the Diffie -Hellman key exchange a shared secret. A cryptographic key is then derived from the secret. This key is used in the sequence to encrypt all messages of the connection with a symmetric encryption method and protecting message integrity and authenticity through a secure Message Authentication Code.

TLS protocols in the protocol stack

In the OSI model TLS is located in layer 5 ( the session layer ). In the TCP / IP model TLS is located above the transport layer (for example, TCP) and beneath application protocols such as HTTP or SMTP. In the specifications it is then referred to as a " HTTP over TLS". However, should be considered together both protocols, the application layer protocol is commonly an "S" for Secure appended (for example, HTTPS). TLS uses transparent so that it can be easily used to make protocols without its own security mechanisms secure connections. Moreover, it is extensible, in order to ensure flexibility and future-proofing for the encryption techniques used.

The TLS protocol is made of two layers:

TLS Record Protocol

The TLS Record Protocol is the lower of the two layers and used to secure the connection. It is based directly on the transport layer and provides two different services that can be used separately or together:

• End-to -end encryption using symmetric algorithms. The key used is in this case ( for example, the TLS Handshake Protocol) negotiated in advance of another protocol and can be used only once for each connection. TLS support for symmetric encryption, among others, DES, Triple DES and AES
• Securing the message integrity and authenticity of a message authentication code, usually HMAC.

In addition to securing data in blocks of 16,384 (214 ) bytes are fragmented and reassembled at the receiver. Here, the standard requires that the block size does not exceed this value unless the block is compressed or encrypted - then the block size to 1024 bytes ( with compression) or 2048 bytes should be higher (with encryption). The data may be compressed before encryption and before computing the cryptographic checksum. The compression method is just like the cryptographic key negotiated handshake protocol with the TLS.

The establishment of a TLS Record message is as follows: Content Type (1 byte: Change Cipher Spec = 20, Alert = 21, handshake = 22, Application Data = 23 ) | Protocol Version Major (1 byte ) | Protocol Version Minor (1 byte ) | length ( Short 1 or two bytes)

TLS Handshake Protocol

The TLS Handshake Protocol is based on the TLS Record Protocol and meets the following functions even before the first bit of the application data stream were exchanged:

• Identification and authentication of the communication partners based on asymmetric encryption and public-key cryptography. This step is optional, a two - way authentication, but usually only need to authenticate the server to the client.
• Negotiate to-use cryptographic algorithms and key. TLS also supports an unencrypted transmission.

The handshake itself can be divided into four phases:

• The version ( the highest supported by the client TLS protocol version)
• A 32 byte random information (4 bytes timestamp 28 -byte random number ), which is used later to the pre - master secret to form ( they thus protects against replay attacks)
• A session ID
• The cipher suite to be used (algorithms for key exchange, encryption and authentication)
• Optionally the desired FQDN for the support of Server Name Indication

TLS Change Cipher Spec Protocol

The Change Cipher Spec Protocol consists of only a single message. This message is one byte long and has the content first result of this message, the sender tells the recipient that he or the negotiated handshake protocol Cipher Suite changes in the active session. A major reason for the definition of a separate protocol for this message is that TLS implementations can combine several messages of a protocol in a record ( ie a TLS data unit ). For the message "Change Cipher Spec" which is undesirable. Because Records of different protocols may not be aggregated, the problem is solved by defining your own protocol.

TLS Alert Protocol

The Alert Protocol distinguishes different messages about two dozen. One of them tells the end of the session ( close_notify ). Others refer for example to the protocol syntax or the validity of the certificates used. A distinction is made between warnings and errors, the latter terminate the connection immediately.

The structure of an error message is as follows: alert level (1 byte: Warning = 1, Fatal = 2 ) | Alert Description ( 1 byte: close_notify = 0, [ ... ], no_renegotiation = 100).

In the specification of TLS the following serious error types are defined:

In the specification of TLS, the following warnings are defined:

In the specification of TLS 1.0, the following warnings have been added:

TLS Application Data Protocol

The application data is transported over the Record Protocol, disassembled into parts, compressed and encrypted in dependence on the current state of the session. They are not interpreted in detail by TLS content.

Calculation of the Master Secrets

From the pre - master secret is in previous protocol versions with the help of the hash functions SHA -1 and MD5, TLS 1.2 calculated using a cipher suite specified by a pseudo-random function, the Master Secret. In this calculation, in addition, the random numbers of Phase 1 of the handshake with a flow. The use of both hash functions should ensure that the master secret is still protected when one of the functions is considered compromised. In TLS 1.2, this approach is now being replaced by the flexible interchangeability of function.

Pros and Cons

The advantage of the TLS protocol is the ability to implement every higher protocol based on the TLS protocol. This independence of applications and systems is guaranteed.

The disadvantage of the TLS - encrypted transmission is that the connection structure on the server side is computationally intensive and therefore slow. The encryption itself takes depending on the algorithm used only little computing time. The encrypted data can be of transparent compression method compresses (such as PPTP - level) any more. As an alternative, the TLS protocol version 1.0, the option to compress the transferred data with zlib.

TLS encrypts only the communication between two stations. However, there are also scenarios (especially in service-oriented architectures) are conceivable in which a message is sent through several stages. If each of these stations but allowed to read only part of the message, TLS is no longer sufficient, since each station can decrypt all the data of the message. Thus unique security challenges at each station, which can not decrypt some data for them.