There are many ways to be affected by security vulnerabilities in your own website. Potential targets range from the network infrastructure to the operating system and system software (such as the web server and database) to the web application in the back and front end.
For data protection officers, however, the means to examine a website for security vulnerabilities as part of an audit are limited – unless you are an expert in cyber security in your second job and know how to carry out a penetration test.
In this article, we describe an important aspect of website security, namely transport encryption, which is particularly relevant in connection with web forms. Surprisingly, this is often implemented only incompletely, although such vulnerabilities are easy to identify. Here you can find out how to check transport encryption.
What is transport encryption?
When we talk about transport encryption, we still very often use the colloquial term “SSL”, the acronym for Secure Socket Layer. This means that the data traffic between the browser and the web server is encrypted in such a way that no third party can intercept the data traffic.
These concerns are justified – the Internet’s decentralized architecture means that data packets often pass through a large number of servers before reaching their destination. Secret services take advantage of this and oblige the operators of the major Internet nodes to grant them full access.
The first protocol for encrypting data on the web was SSL, which was developed by Netscape in 1994. This version 1.0 was followed by SSL 2.0 and SSL 3.0, after which the acronym TLS (Transport Layer Security) was used for improved procedures, with the versions TLS 1.0 to TLS 1.3. Only the TLS 1.2 and 1.3 procedures should now be used, as all others are considered outdated and no longer secure enough.
However, the way it works has not fundamentally changed since 1994. It looks very simplified as follows:
- The web server provides the browser with a digital certificate. This was issued by an independent body and proves the identity of the server – this prevents an attacker from standing in front of the web server, so to speak, pretending to be it and intercepting the communication.
- The certificate also contains a so-called public key for an asymmetric encryption process. This means that the browser can encrypt a message with the publicly known key, but only the web server can decrypt it.
- The browser and server also agree on which procedures are used for encryption in detail.
Vulnerabilities around transport encryption
For secure transport encryption, a website operator must not only provide a trustworthy TLS certificate, the web server must also be configured correctly – typically the task of a provider or IT service provider in a business context. The following errors should be avoided, also because they are easily recognizable by third parties:
Unencrypted server
Almost too banal for this list, but still common in the private sphere or in clubs. As certificates are now available free of charge (e.g. from Let’s Encrypt) and most web providers make them available at the touch of a button via an admin interface, it should actually also be common practice for this target group to use them.
Invalid certificate
With basic technical knowledge, it is easy to create a web server certificate yourself. However, as this has not been issued by an independent body, it is not sufficient to prove your own identity. In this case, browsers display such a clear warning that the website appears unusable.
A certificate is also invalid if it is installed on the wrong web server than intended. The warning message in the browser then looks similar.
Missing certificate chain
In order to be able to prove your identity, additional certificates should be installed on the server in addition to your own web server certificate, namely the so-called “intermediate certificates”. These identify the company from which the certificate was purchased. Modern browsers can reload these certificates; older browsers display an error if they are not available.
Expired certificate
As certificates are always issued with an expiration date (they are typically valid for 1 to 3 years), they become invalid at a certain point and must be renewed. In this case, web browsers also display a very extreme warning message.
Outdated protocols
The encryption details used are negotiated between the browser and server as described above. An attacker could suggest a very old and easy-to-breach method to the server. For this reason, servers should be configured in such a way that they only support modern, secure procedures.
Vulnerability to attacks
The known attack possibilities against TLS are mostly related to outdated protocols (e.g. POODLE is a vulnerability of SSL 3.0). One exception is the Heartbleed vulnerability, which has received a lot of press coverage since 2014. It is based on a bug in the OpenSSL software library,
No forced encryption
Even the best encryption is useless if it is not used. Websites should therefore redirect all calls made via http:// to https:// in order to enforce encryption.
Check the server encryption
Some of the vulnerabilities mentioned above are very easy to check because every browser displays a clearly visible warning message for some of them. However, this does not apply to all of them – the acceptance of old protocols, for example, is not readily apparent. Fortunately, there is a very powerful and free online tool that tests all of the above vulnerabilities – the SSLLabs website from Qualys.
Simply enter the server name you want to check in the input field and wait a few minutes. The result is then a very detailed check of a large number of criteria. The technical interpretation of the messages can be difficult, so the most relevant part for you is the summary at the top of the report – here using the example of https://decareto.com:
It is advisable to pass on all results with a rating lower than A to the website operator with a corresponding warning. The technical contact will know how to interpret the information, at least potential risks have been addressed.
If you scroll down in the report, you will also see the results for the potential problems with encryption mentioned above, such as the accepted protocols:
All protocols below (i.e. older) than TLS 1.2 should be marked with “No”, at least one of the TLS 1.2 or TLS 1.3 protocols should be marked with “Yes”.
