S 5.66 Use of TSL/SSL

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: User, Administrator

The most commonly used security protocol for web usage is the Transport Layer Security/Secure Socket Layer (TLS/SSL). SSL was developed by Netscape. Newer versions are referred to as TLS and have been standardised in various RFCs. TLS/SSL is supported by all current browsers. TLS/SSL can be used to secure connections in the following manner:

TLS/SSL establishes a connection between the user's browser and the provider's server that is then used to initially exchange the certificates with the public keys. An asymmetric encryption method is then used to securely exchange a symmetric key. A symmetric method is then used to encrypt the actual data transmission, because these methods can encrypt large amounts of data quickly. A different symmetric key to be used as a session key is negotiated for every transaction, and this key is then used to encrypt the connection.

Users can recognise a website allowing for the data to be transmitted over a connection secured using TLS/SSL by the "s" that is inserted in its internet address (https://www...). In addition, such websites are also indicated by the most commonly used browsers, for example by displaying a certain symbol (a key, a padlock, etc.) or by highlighting the internet address in colour.

The use of TLS/SSL is not restricted to HTTP clients and servers. Protocols such as SMTP or LDAP may also use TLS/SSL for secure communications. However, this assumes that the corresponding clients and servers support this security function.

TLS/SSL consists of two layers. The TLS/SSL handshake protocol operates in the top layer. This protocol is used by the client and the server for mutual identification and authentication, as well as to negotiate a key and an encryption algorithm for the subsequent data traffic. The bottom layer, the TLS/SSL record protocol that forms the interface to the TCP layer, encrypts and decrypts the actual data traffic. Since TLS/SSL uses the socket interface to access TCP and replaces it with a version containing expanded security functionality, it can also be used for other services.

TLS and SSL have different version numbers. Only TLS 1.0 or higher or SSL 3.0 or higher should be used, because server authentication only became available for the first time in these versions. SSL 2.x, in contrast, should not be used since these versions do not offer any protection against man-in-the-middle attacks.

Algorithms and key lengths

Various cryptographic algorithms with various key lengths can be used with TLS/SSL (see also S 3.23 Introduction to basic cryptographic terms for more information). The client and server agree to the procedure to be used in the session when establishing the connection.

It must be ensured through the selection of suitable products (browsers, web servers, plug-ins, etc.) and a suitable configuration that the communication protected using TLS/SSL only uses algorithms and key lengths meeting the state-of-the-art and the security requirements of the organisation. Additional information on this topic can be found in safeguard S 2.164 Selection of a suitable cryptographic procedure.

Certificates

It is difficult to check the identity of the communication partner in data communications conducted over an open network because you cannot be sure that the name stated is the correct name. When TLS/SSL is used, the identity of the communication partner is checked using certificates. Certificates contain their public keys as well as confirmation from an additional authority of the correct assignment of the public key to its "owner", which in this case is a server or a client. The value of a certificate therefore not only depends on how trustworthy this verification authority is (also referred to as a trust centre or certificate authority). In turn, the authenticity of the certificate can be checked using the public key of the verification authority.

There are three different types of certificates available in TLS/SSL:

All commonly used browsers contain TLS/SSL certificates from several certificate authorities automatically after installation. These certificate authorities have very different security policies and conditions for issuing certificates. For these reasons, the security policy of the particular certificate authorities should be checked before security-critical information is transmitted using a TLS/SSL-protected connection.

When accepting a new certificate, care should be taken to ensure the certificate is only activated after checking its fingerprint. The fingerprint is a hexadecimal number that is transmitted together with the certificate. Furthermore, the fingerprint should be transmitted over a different route and then compared to ensure the correctness of the certificate.

Operators of web servers wanting to exchange security-relevant data with the visitors of their websites should offer a cryptographic method such as TLS/SSL for securing the transmission route.

Note: When using TLS/SSL, it must be noted that encrypted data cannot be checked for active content or malware at a central location, for example on the security gateway. This must be taken into consideration in the security design so that no security gaps are created. Additional recommendations on this subject can be found in module S 1.6 Protection against malware, amongst other things.

Review questions:

© Federal Office for Information Security. All rights reserved.