Any UC solution must use state-of-the-art cryptographic tools to make sure that information exchanged remains secret.
For TCP connections, the de facto standard is Transport Layer Security (TLS) and, its predecessor, Secure Sockets Layer (SSL). Both of these are frequently referred to collectively as “SSL” and are cryptographic protocols that provide communications security over a computer network.
The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating computer applications. When secured by TLS, connections between an SIP, XMPP, or HTTP client (for example, a web browser) and a server (for example, wikipedia.org) have one or more of the following properties:
- The connection is private because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session (see TLS handshake protocol). The server and client negotiate the details about the encryption algorithm and cryptographic keys to use before the first byte of data is transmitted (see Algorithm). The negotiation of a shared secret is both secure (the negotiated secret is unavailable to eavesdroppers and cannot be obtained, even by an attacker who places himself in the middle of the connection) and reliable (no attacker can modify the communications during the negotiation without being detected).
- The identity of the communicating parties can be authenticated using public-key cryptography. This authentication can be made optional, but it is generally required for at least one of the parties (typically the server).
- The connection is reliable because each message transmitted includes a message integrity check using a message authentication code, which prevents undetected loss or alteration of the data during transmission.
TLS 1.2 and 1.3
TLS 1.2 defined in RFC 5246 (https://tools.ietf.org/html/rfc5246) in August 2008 and TLS 1.3 defined in RFC 8446 (https://tools.ietf.org/html/rfc8446) in August 2018 are the updates to the series of crypto protocols started with SSL 1. They are based on the earlier TLS 1.1 specification. Major differences include:
- The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, including an option to use cipher suite-specified PRFs.
- The MD5-SHA-1 combination in the finished message hash was replaced with SHA-256, including an option to use cipher suite-specific hash algorithms. However, the size of the hash in the finished message must still be at least 96 bits.
- The MD5-SHA-1 combination in the digitally signed element was replaced with a single hash negotiated during handshake (by default, SHA-1).
- Enhancements to the client’s and server’s ability to specify which hash and signature algorithms they accept.
- Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard encryption.
- TLS Extensions definition and Advanced Encryption Standard cipher suites were added.
- All TLS versions were further refined in RFC 6176 (https://tools.ietf.org/html/rfc6176) in March 2011, removing their backward compatibility with SSL, so that TLS sessions never negotiate the use of Secure Sockets Layer (SSL) version 2.0.
- The most recent version, TLS 1.3, introduces significant improvements in terms of latency and security.
To enforce security, it is particularly important to use a key exchange system that includes forward secrecy and a modern cipher suite.
Forward Secrecy
Forward secrecy is a property of cryptographic systems. It ensures that a session key derived from a set of public and private keys will not be compromised if one of the private keys is compromised in the future. Without forward secrecy, if the server’s private key is compromised, not only will all future TLS-encrypted sessions using that server certificate be compromised, but also any past sessions that used it as well (provided, of course, that these past sessions were intercepted and stored at the time of transmission).
An implementation of TLS can provide forward secrecy by requiring the use of ephemeral Diffie-Hellman key exchange to establish session keys, and some notable TLS implementations do so exclusively (such as Gmail and other Google HTTPS services that use OpenSSL). However, many clients and servers supporting TLS (including browsers and web servers) are not configured to implement such restrictions. In practice, unless a web service uses the Diffie-Hellman key exchange to implement forward secrecy, all of the encrypted web traffic to and from that service can be decrypted by a third party, if it obtains the server’s master (private) key (for example, by means of a court order).
Certificate Authority (CA)
When a client communicates with a server, there must be a way to confirm the identity of the server, and only communication with trusted servers should be allowed. If the identity of the server is not confirmed, an error message of some kind typically appears (the example below shows this type of error message in a browser):
Why is it so important?
A server’s public certificate must be verifiable via a third party identity that is trusted by the client. Otherwise, the client might be connecting:
- To a server posing as the real server.
- To an entity in the middle of the connection that is eavesdropping on the communication between the client and the real server.
A certificate authority is a trusted third party. It is trusted by both the subject (owner) of the certificate and by the party relying upon the certificate.
A CA (Certification Authority) is an entity that signs public certificates, provided by private and public organizations, thereby confirming their identity. The confirmation is achieved by preloading the client-trusted CA certificates.
Before proceeding with the connection, the client will check if the public CA key can successfully open the signature (signed using the private CA key).
Conclusions
Today, TLS is no longer an option for any deployment. When it is implemented, we must make sure that:
- A CA is used to confirm the authenticity of the server certificate.
- Version 1.2 / 1.3 is used and all of the latest security enhancements are implemented including:
- A forward secrecy is used to grant confidentiality if one the client or server keys is compromised.
- The crypto key is updated during a session.
TLS makes sure that:
- The authentication process is confidential.
- All information exchanged between client and server is confidential, including:
- SIP calls (including SRTP audio encryption / decryption keys)
- Chat messages
- Presence details
- Provisioning files and other information exchanged over HTTPS
