jspωiki
SSL-TLS Interception

Overview#

SSL-TLS Interception (AKA TLS Proxy or HTTPS Interception) is a Proxy Server that decrypts the TLS and passing on the unencrypted request to Observers and is by definition a Man-In-The-Middle attack.

SSL-TLS Interception which we have seen described as Legal SSL\TLS Interception are still a Man-In-The-Middle exploit.

"The Transport Layer Security (TLS) Protocol Version 1.2" (RFC 5246) clearly states "The TLS protocol provides communications security over the Internet"

Yet everyday millions of people work behind TLS Proxies that provide no security and no indication to the end-user that the connection is NOT secure. Some of these conditions are "legal" TLS Proxies operated by organizations that the End-User has provided their consent to their employers to perform surveillance on them. There are of course MANY others that the typical Internet user has no idea that they are using a TLS Proxy.

Many "free" WI-FI systems and most Hotel and Motel systems utilize TLS Proxies often operated by their chosen provider.

Many Internet Providers utilize TLS Proxies for all of their connections.

A TLS Proxy typically Decrypts the "supposedly" secure TLS communication and perform inspection and logging of data all unknown to the end-user. TLS Proxies are of course subject to review by any number of Government authorities often without the end-user being notified.

Many of these TLS Proxies generate certificates on-the-fly and present them to the user as a "valid" certificate signed by one of the hundreds of Certificate Authorities builtin to the browser or added by the employer.

Regardless of the technology used, the TLS Proxy is by definition a Man-In-The-Middle attack and TLS does not detect the attack. Which clearly does not "The TLS protocol provides communications security over the Internet"

Even the United States Department of Homeland Security has noted this HTTPS Interception Weakens TLS Security[2]

Violates Many Privacy Laws and degrades Trust#

Certainly the Law of Human Integration

Most of the Laws from Privacy by Design including:

TA17-075A HTTPS Inspection [2]#

United States Department of Homeland Security Alert(TA17-075A) says:

Many organizations use HTTPS interception products for several purposes, including detecting malware that uses HTTPS connections to malicious servers. The CERT Coordination Center (CERT/CC) explored the tradeoffs of using HTTPS interception in a blog post called The Risks of SSL Inspection [4].

HTTPS inspection works by intercepting the HTTPS network traffic and performing a man-in-the-middle (MiTM) attack on the connection. In MiTM attacks, sensitive client data can be transmitted to a malicious party spoofing the intended server. In order to perform HTTPS inspection without presenting client warnings, administrators must install trusted certificates on client devices. Browsers and other client applications use this certificate to validate encrypted connections created by the HTTPS inspection product. In addition to the problem of not being able to verify a web server’s certificate, the protocols and ciphers that an HTTPS inspection product negotiates with web servers may also be invisible to a client. The problem with this architecture is that the client systems have no way of independently validating the HTTPS connection. The client can only verify the connection between itself and the HTTPS interception product. Clients must rely on the HTTPS validation performed by the HTTPS interception product.

A recent report, The Security Impact of HTTPS Interception [3], highlighted several security concerns with HTTPS Inspection products and outlined survey results of these issues. Many HTTPS inspection products do not properly verify the Certificate Chain of the server before re-encrypting and forwarding client data, allowing the possibility of a MiTM attack. Furthermore, certificate-chain verification errors are infrequently forwarded to the client, leading a client to believe that operations were performed as intended with the correct server. This report provided a method to allow servers to detect clients that are having their traffic manipulated by HTTPS inspection products. The website badssl.com is a resource where clients can verify whether their HTTPS inspection products are properly verifying certificate chains. Clients can also use this site to verify whether their HTTPS inspection products are enabling connections to websites that a browser or other client would otherwise reject. For example, an HTTPS inspection product may allow deprecated protocol versions or weak ciphers to be used between itself and a web server. Because client systems may connect to the HTTPS inspection product using strong cryptography, the user will be unaware of any weakness on the other side of the HTTPS inspection.]

The Security Impact of HTTPS Interception, highlighted several security concerns with HTTPS Interception products and outlined survey results of these issues. Many SSL-TLS Interception products do not properly verify the Certificate Chain of the server before re-encrypting and forwarding client data, allowing the possibility of a MiTM attack. Furthermore, certificate-chain verification errors are infrequently forwarded to the client, leading a client to believe that operations were performed as intended with the correct server. This report provided a method to allow servers to detect clients that are having their traffic manipulated by HTTPS inspection products. The website badssl.com is a resource where clients can verify whether their HTTPS inspection products are properly verifying certificate chains. Clients can also use this site to verify whether their HTTPS inspection products are enabling connections to websites that a browser or other client would otherwise reject. For example, an HTTPS inspection product may allow deprecated protocol versions or weak ciphers to be used between itself and a web server. Because client systems may connect to the HTTPS inspection product using strong cryptography, the user will be unaware of any weakness on the other side of the HTTPS Inspection.

FIGHTING BACK AGAINST SSL INSPECTION, OR HOW SSL SHOULD WORK[1]#

Internet users, including many security professionals, often blindly rely on SSL/TLS to provide the confidentiality and integrity of our personal data, at least when using our web browsers. We expect SSL/TLS to do so even in the face of attackers with the ability to hijack and redirect our network connections and DNS traffic (i.e., a Man-In-The-Middle attack).

More Information#

There might be more information for this subject on one of the following: