Encryption on the World Wide Web has a long history, which explains the abbreviations used today. It started back in 1993 with Secure Sockets Programming as a prototype. Netscape subsequently completed Secure Sockets Layer (SSL). SSL version 1 was never published. Version 2 dates back to 1995. Version 3 was published in 1996 as a complete re-design. So anyone who says SSL actually means a historical protocol that is no longer in use. The Internet Engineering Task Force (IETF) took over the maintenance of the standard in 1999. This was accompanied by a new name: Transport Layer Security (TLS). The versions of the specification are 1.0 (1999), 1.1 (2006), 1.2 (2008), and 1.3 (2018). So people still call encrypted connections SSL/TLS, even though SSL may/should not actually be used anymore.
Why should one bother with it?
Typically, one deals with web applications and messages in everyday work and also in private life. Both types of applications use encryption to ensure that content on its way to the consumer (smartphone, browser, email program, messenger, etc.) is not modified or read. At the latest since the revelations of Edward Snowden you want encryption from one end to the other. This is also called end-to-end encryption. The idea is that no third party is in the middle and can read data. This means that videos come directly from the streaming provider. The same applies to all applications. So the content can only be viewed at the ends and thus verified. What does this mean for information security?
SSL and TLS are important components for security.
This means that encrypted data transmissions cannot be broken. This is a fundamental requirement. If there were backdoors or vulnerabilities, attackers would exploit this, and the entire protocol would be ineffective. Security systems therefore implement inspection of the content via so-called proxy systems. The client connects to the proxy and the proxy fetches the content from the server. The proxy thus sits in the middle, and one TLS connection becomes two. In this way, inspection of the transmitted data is possible. There is a logistical challenge with this. The design of SSL/TLS provides for central certificate authorities that certify keys and names. All web browsers have a list of trusted authorities. Encryption alone without a trust base is worthless. Content verification requires that the proxy have a list of certificate authorities it trusts, and that the client trust the proxy.
There are two other methods of verifying content or metadata. One can also try to open the encryption without a proxy. To do this, one uses the attackers’ methods by forging certificates and having them issued by a separate certificate authority that the clients all know and trust blindly. Such systems are called middle boxes, analogous to middle men who sit in the middle between server and client. These systems ultimately exploit open points or vulnerabilities in the standard. These methods will no longer be possible with TLS version 1.3. This is a conscious decision in favor of security. The fact that it is possible to forge or break encrypted connections is always undesirable. In addition, it was previously possible to see which certificates the connection was working with, because the establishment of a TLS connection is not completely encrypted until version 1.2. At the moment, there are still (pseudo)security systems that build on these weaknesses.
Is content verification still possible?
What happens now when TLS version 1.3 becomes widespread? Of course, content verification will not die with it. You just have to find the right architecture or adapt the existing one. Proxy systems offer higher security than pure packet filters (no matter how “deeply” they analyze packets) because they understand the protocol. All that’s left is for clients to compare certificate authorities with hard-coded checksums. Mozilla Firefox, Google Chrome, and some apps for smartphones implement this method. This is not a security issue, but a trust issue. After all, anyone who has this software on their network trusts it anyway. This is especially true for the app stores of some providers. After all, the security model of the app stores completely collapses if someone can pretend to be an app store. In these cases, any content verification must take place on the client after the data has been decrypted anyway. This so-called end point protection, i.e., protection at the end of the line, is also the basis for a secure IT architecture.
End-to-end encryption is a security concept!
The fact that some have not yet implemented this concept is an indication of a need to catch up, not of errors in encryption standards. The implementation of TLS version 1.3 must be carefully planned if non-standard solutions are to be used. A bonus is HTTP2, the new generation of the Hypertext Transfer Protocol, which only transfers encrypted data. It is more performant than the versions before it. Faster applications therefore do not stand in the way of security and can act as a reward.
SEC4YOU advises you in questions of end-to-end encryption and the correct use of TLS 1.3. We are also happy to check existing systems and whether their use of SSL/TLS corresponds to the current state of the art.
Please use our contact form to contact us in case of any questions..
