Phishing, spoofing, secured connection, data encryption… these notions seem to be nearly everywhere nowadays. Yet, the average internet user is surpassed by the magnitude of such a phenomenon and doesn’t necessarily understand why preventive up-to-date cybersecurity measures are crucial.
In a digital era where users’ rights on the Internet are no longer limited to basic operations, SSL/TLS public-key encryption plays a major role in the data protection industry, ensuring web-secured transactions and privileged data exploitation.
However, legal instruments like the GDPR institute obligations and responsibilities for enterprise IT leaders. This motivates them to adopt a preventive attitude towards imminent threats and attacks undertaken by malicious actors determined to take advantage of negligent companies and users. Hence, this article aims to explain why, given the circumstances, a TLS protocol might not be enough when it comes to GDPR compliance.
SSL/TLS – what does it actually means?
TLS – Transport Layer Security- with its predecessor Secure Sockets Layer is nothing else but a protocol used to secure communication between computer systems. When it comes to the internet, TLS allows a web browser to establish an encrypted network connection between the client and the destination server [ensuring therewith the practical realization of HTTPS connections (hypertext transfer protocol secure)]. Each protocol uses a different port, as in a virtual point that indicates where a connection starts and where it ends, being software-based and handled by a computer’s operating system. HTTPS connections will always use port 443, whereas HTTP connections (non-secured) will be using port 80. This is where another major element comes in : the asymmetric encryption (also known as public key-encryption). The latter implies that previously encrypted data with a public key (used by anyone who wants to verify private-key signed data) could only be decrypted with a unique private key (used for signing data).
However, what one would know as a “TLS Handshake” involves not only an asymmetrical encryption, but a symmetrical one too. Thus, asymmetric encryption is used to securely establish the so-called ‘symmetric keys’. This means that, with every single new communication session that starts between a client and a server, there will be an ‘agreement’ on the use of symmetric keys, also called ‘session keys’, generally used when it comes to bulk data protection.
TLS Certificate
A TLS certificate represents a digital certificate issued by a Certificate Authority (CA) in order to attest and guarantee the proprietorship of a public key.
Understanding its origin implies understanding three major actors. The Client (a software formulating a request, most precisely a Web Browser, not the user himself) initiates the ‘TLS Handshake’ and the Server receives it (a Web Server – NginX, Apache, an SSL Accelerator etc.). The CA provides the so-called ‘trust-anchor’ (even if a Client might not trust a Server, it does trust the CA which provides a certificate for the Server, so the Client can also ‘trust’ the Server).
TLS Protocol, surpassed by GDPR requirements
According to the EU’s website, GDPR is the ‘toughest privacy and security law in the world’, imposing ‘obligations onto organizations anywhere, so long as they target or collect data related to people in the EU’.
Article 32 GDPR provides that ‘the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: ‘(a) the pseudonymisation and encryption of personal data’. Even though ‘encryption’ is not specifically defined within the normative act, Article 34(3)(a) provides that it might be seen as an ‘appropriate technical and organisational protection measure’, rendering ‘the personal data unintelligible to any person who is not authorised to access it’.
However, an HTTPS (formally known as an HTTP using TLS-encrypted certificate) plays a major role under GDPR’s provisions when referring to data in transit. In fact, data in motion is especially vulnerable because of its open-network route outside the controller’s predefined boundaries. And so, in particular cases like sending an e-mail, TLS will only ensure that the transmission operating between SMTP (Simple Mail Transfer Protocol) servers is encrypted, but will not provide encryption for e-mails themselves, making them ‘susceptible to interception or manipulation without authorization’.
The latter represents a communication protocol used by most of mail servers to send mail messages, being a delivery-only application layer protocol. SMTP is also a connection-oriented, text-based protocol in which a mail sender communicates with a mail receiver by issuing command strings and supplying necessary data over a reliable ordered data stream channel, typically a Transmission Control Protocol (TCP) connection. The last-mentioned is ‘one of the main protocols of the Internet protocol suite, commonly known as TCP/IP’.
As the Swedish authority ‘IMY’ explains in Decision DI-2021-4355, enforced-TLS encryption would end before ‘the message had reached the final recipient and, thus, does not constitute an end-to-end encryption. Consequently, there was a risk that unauthorized persons could access the e-mail in plain text after the encrypted transmission had ended’.
It should be concluded that TLS may be an alternative for VPN (Virtual Private Network – mainly used when a protected network connection is needed while using a public network).
However, everyday-communication between two parties, such as B2C (‘business to consumer’) communications or a broader range of recipients, needs a closer look. TLS is no longer GDPR compliant, failing to provide an up-to-date level of security the way a password-based encryption method would be able to do it currently.
Roxana Vener
M2 Cyberjustice – Promotion 2023-2024
Sources:
Minimum standard for use of TLS
Decision of the Swedish Authority for Privacy Protection
