TLS: Much More Than a Compliance Requirement
You may have heard about SSL/TLS, especially in 2018 when more widespread Secure Sockets Layer (SSL) adoption pushed by web browsers and PCI council advisory about the future deprecations of early versions of TLS (Transport Layer Security).
Those concepts are often used without knowing their meaning or functionality. This is because behind those, there is a complex teamwork between networking, cryptography, algorithms and structures.
This is not a full detailed cryptography paper but a basic guide about what it is, how it works, and why we should implement it in our SAP systems and security processes.
First, we’ll use a short table to show SSL/TLS evolution:
| SSL 1.0 | Never publicly released | Never publicly released |
| SSL 2.0 | Released in 1995 | Prohibited in 2011 (RFC6176) |
| SSL 3.0 | Released in 1996 | Prohibited in 2015 (RFC7568) |
| TLS 1.0 | Released in 1999 (RFC2246) | Deprecation planned in 2020 |
| TLS 1.1 | Released in 2006 (RFC4346) | Deprecation planned in 2020 |
| TLS 1.2 | Released in 2008 (RFC5246) | |
| TLS 1.3 | Released in 2018 (RFC8446) |
Both SSL and TLS are protocols used to encrypt communications between two entities by exchanging public and private keys to create a secure session between them, providing privacy and data integrity. While TLS is the SSL successor, the latter is used daily as a reference to both.
Along their history, vulnerabilities and design problems had been found, such as DROWN and POODLE attacks (SSL 2.0 & SSL 3.0), forcing worldwide cryptographers to research and release stronger algorithms and structures every time.
As can be seen up ahead in the table, TLS 1.2 is the ‘must-have’ version pushed by most-common used web browsers and standards such as PCI.
Basic TLS Handshake (Initial Communication)
Typically, the client is the first one to send a message called ‘Client Hello’ to the server with the intention of exchanging information. This message contains:
- Version: TLS protocol version that the client wants to use for communication with the server. It is the highest supported by the client.
- Client Random: Pseudorandom number used to create the Master secret (Encryption key creation).
- Session Identifier: An optional session ID to resume.
- Cipher Suite: List of cipher suites supported by the client ordered by the client’s preference. A cipher suite consists of a key exchange, bulk encryption and MAC algorithms with a pseudorandom function, e.g.:
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM (available in TLS 1.2)
TLS = Protocol version.
After this message, it is the server’s turn to send the ‘ServerHello’, answering for each Client element, if the server can support and its agree on using that configuration (the highest available one). Once finished the ‘Hello’ step, the server will send its certificate containing server’s public key, that will be used by the client to check if the server is who he says he is and to establish a secure connection. These are the most important fields:
- Serial Number: Is unique for each certificate issued and assigned by the Certificate Authority (CA).
- Signature Algorithm: Identifies the cryptographic algorithm used by the CA to sign the certificate. Since 2016 all CA have to sign using the SHA2 algorithm.
- Issuer: CA that signed the certificate.
- Valid From and Valid To: These fields indicate the validity period of the certificate, which will be valid between those dates.
- Subject: Contains the Distinguished Name (DN) information for the certificate, depending on the type of the certificate, the information displayed. The most common type is Organization Validated (OV) and it shows: Common Name (CN), Organization (O), Organizational Unit (OU), Locality or City (L), State or Province (S) and Country Name (C).
- Public Key: Is used to identify the modules key bit length.
- Subject Alternative Name (SAN): Majority of all applications/web-browsers work with this field, it will list all the FQDNs that the certificate can validate when is applied to an application.
Once the Server’s certificate is verified, the Client will generate a ‘Pre-Master Secret’ depending on which cipher suite will be used. Before sending it to the server, it will encrypt it with the Server’s public key (getting it from the server’s certificate). Once received, the Server should be capable of decrypting it with the private key, and both parts are able to generate the ‘Master Secret’ applying a pseudorandom function to the ‘Pre-Master Secret’, and the random numbers exchanged previously. This Master Secret will be the key used by Client and Server to encrypt their communication in the future.
Once the key was generated, both parts validate all information with a message called ‘ChangeCipherSpec’. Then, with once set up and speaking the same ‘language’ between parts, they are ready to exchange information represented by the ‘ApplicationData’ package.
Why Should I Use It?
Let’s suppose we want to connect to one of our SAP systems using our credentials, as always.
We send this information, without taking into consideration that it travels through the network in plain text. Anyone listening or sniffing network traffic could see anything we send to the SAP server. In other words, our credentials or any sensitive transactional information.
After implementing TLS, we can appreciate that TLS 1.2 packages are exchanged between our device and the server but with no information travelling in plain-text (encrypted).
The most critical thing here, is that this sensitive data exposure affects the entire group of SAP systems without the proper TLS configuration, no matter if you are using stacks based on ABAP, JAVA, HANA or even if you are trying to connect to a database or using a mobile client.
For more detailed information about cryptographic algorithms and SSL/TLS cipher suites implemented in CommonCryptolib 8, you can go here.
You can find information about TLS implementations on the following links:
Transport Layer Security on SAP NetWeaver AS for JAVA
Transport Layer Security on the AS ABAP
TLS/SSL Configuration on the SAP HANA Server