TLS Interception
Why we use TLS
TLS secures our online life. But do we put too much trust?
When Sir Tim Berners-Lee, working at the Conseil Européen pour la Recherche Nucléaire (CERN), created the first Web site, the information he wanted to share was public and did not require any protection. However, after a few years it became apparent that the Web would be carrying data that do need protection. Netscape went along and created the SSL protocol 26 years ago to secure the Internet. But, what does TLS, the successor to SSL, mean with protecting information? In the context of a Web transaction, data protection means:
- Data can not be seen by others (privacy)
- Data is received from, or sent to the intended Web server (authentication)
- Data is not modified en route (integrity)
If properly implemented and used, privacy, authentication and integrity assure the user that his/her information sent or received from a Website is secure. With this assurance you can, for example, access your sensitive bank information. Or you can order something on-line using your credit card without fear that someone is eavesdropping on the transaction and stealing your credit card information.
But, is it really secure?
Is security bad?
Before looking at how TLS may not be secure we may ask if security is bad in the first place. You may think that security can not be bad. Right? And you are correct if you are 100% sure that the security not broken. Not only that, you must also be sure that the device you use, your laptop, phone or tablet, is not compromised with some hacker code running on it. If it is, then some rogue code may be accessing a Web site to transmit information it gathers on your device without anyone taking notice, particularly you.... Also, when working with data that belongs to your employer, you are not the only stakeholder; someone else, your employer's security team for example, may have another say in the matter.
What does this mean? This means that, in certain circumstances, too much security is not good. For example, at a workplace, it may be desirable to make sure that a connection is not leaking sensitive data to a hacker data warehouse. For this, some information must be visible to some intermediary responsible to allow, or disallow, that transaction to take place. This is a legitimate situation where lessening just a little bit the security of the Web transactions is desirable.
How can TLS be not secure?
As seen above a connection is secure if 3 characteristics are met; the data must be private, it must not be tempered with and the recipient (or provider) must be the one we expect (or desire). If any of these 3 characteristics, even a single one, are not met then the connection is not secure. Someone may be interfering.
The amount of work, scientific research and scrutiny pertaining to raw data encryption make information privacy standards excellent at protecting the privacy of the data. Brute force attacks on decrypting the data is hard, expensive and very long to successfully extract unencrypted information. As long as the keys are kept secret, for TLS to successfully provide privacy is not an issue. Keeping the keys secret is not a small feat though; gaining access to the keys is one possible way to break TLS. But, as seen below, there are easier ways.
Data integrity is also not much of a concern. Detecting that data was tempered with is fairly easy when coupled with good privacy. So, as long as privacy is well established and maintained, integrity is not a problem. In the past, WiFI did suffer from some data integrity issues but this is mostly resolved now.
Authentication is where the majority of the problems lie. Exchanging sensitive information, such as passwords, with the wrong Web site due to forged site identity is the worst that can happen. Deceiving the user, or his/her device are both possible. This is being done everyday using various techniques. It's not that TLS is fundamentally bad at providing excellent authentication. It's what is needed to TLS to perform this authentication which is the problem. Weak DNS infrastructure, rogue WiFI access points and other bad actors, such as proxies, are ways used by hackers to break the authentication mechanisms put in place by TLS and thereby gain access to user information. When this happens, it is said that the TLS session was intercepted. This is not necessarily bad, as in the filtering scenario above, but it is certainly bad for illegitimate interception.
Improving TLS security
The two areas that need to be looked at to improve the TLS security are the key secrecy and the mutual authentication of the connection peers. This is difficult for most typical browser based Web activities. On the other hand, it is relatively easy for machine to machine type communication and Web application in browsers when using multiple factor authentication.
Fundamentally, authentication weakness of TLS is resolved by having something (security experts call this a knowledge) known to each party by using means that do not involve the communication channel that we want to protect. Said differently, this knowledge needs to be put in place without the use of TLS. This can be done by having some prior pre-shared keys. Or can be done using a two factor mechanism, where the 2nd factor is an email, an SMS or even a simple voice call.
Equipped with prior knowledge, a client application (machine or Webapp in browser) can make sure it is communicating with the intended server since only this server is presumed to have the corresponding knowledge. The knowledge can, and should be used to create new keys and encrypt the information carried by TLS; the data is then double encrypted and made much more secure.