This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
SSL-TLS Interception
SSL-TLS Interception

Version management

Difference between version and

At line 1 added 54 lines
!!! Overview
[{$pagename}] (AKA [TLS Proxy] or [HTTPS Interception]) is a [Proxy Server] that [decrypts|Decryption] the [TLS] and passing on the unencrypted request to [Observers] and is by definition a [Man-In-The-Middle] [attack].[{$pagename}] which we have seen described as [Legal SSL\TLS Interception|Legal 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|TLS Proxy] 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|TLS Proxy] often operated by their chosen provider.
Many [Internet] Providers utilize [TLS Proxies|TLS Proxy] 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|TLS Proxy] are of course subject to review by any number of Government authorities often without the end-user being notified.
Many of these [TLS Proxies|TLS Proxy] generate [certificates] on-the-fly and present them to the user as a "valid" certificate signed by one of the hundreds of [Certificate Authorities|Certificate Authority] 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]
!! [{$pagename}] [Security Considerations] and [Perverse result]
! [The Sorry State of TLS Security in Enterprise Interception Appliances|https://arxiv.org/abs/1809.08729|target='_blank']
In this [2018|Year 2018] paper they "''analyze thirteen representative network appliances over a period of more than a year (including versions before and after notifying affected vendors, a total of 17 versions), and uncover several security issues. For instance, we found that four appliances perform no [Certificate Validation] at all, three use pre-generated [certificates], and eleven accept [certificates] signed using [MD5], exposing their clients to [MiTM] attacks. Our goal is to highlight the risks introduced by widely-used TLS proxies in enterprise and government environments, potentially affecting many systems hosting security, privacy, and [financially sensitive|Financial Data] data.''"
! 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|Bad Actor] 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|Man-In-The-Middle] ([MiTM]) [attack] on the connection. In [MiTM] attacks, [sensitive|Sensitive Data] 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|Trusted Certificate] on client devices. [Browsers] and other client applications use this [certificate|Trusted 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|Certificate Validation] 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|Magnitude of the Potential loss] of HTTPS Interception [3], highlighted several [security concerns|Security Considerations] 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 [{$pagename}] products do not properly [verify|Certificate Validation] the [Certificate Chain] of the server before re-encrypting and forwarding client [data], allowing the possibility of a [MiTM|Man-In-The-Middle] attack. Furthermore, [certificate-chain|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|Cryptographically Weak] on the other side of the [HTTPS Inspection].!! [Privacy Considerations]
[{$pagename}] Violates Many Privacy [Laws] and degrades [Trust] and Certainly violates the [Law of Human Integration]
In this paper they "''"..analyze thirteen representative network appliances over a period of more than a year (including versions before and after notifying affected vendors, a total of 17 versions), and uncover several security issues. For instance, we found that four appliances perform no certificate validation at all, three use pre-generated certificates, and eleven accept certificates signed using MD5, exposing their clients to MITM attacks. Our goal is to highlight the risks introduced by widely-used TLS proxies in enterprise and government environments, potentially affecting many systems hosting security, privacy, and financially sensitive data"."''
Most of the [Laws] from [Privacy by Design] including:
* [Respect for User Privacy]
* [End-to-End Security]
* [Visibility and Transparency]
!! [FIGHTING BACK AGAINST SSL INSPECTION, OR HOW SSL SHOULD WORK|https://securityevaluators.com/knowledge/case_studies/mutual//|target='_blank'][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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [FIGHTING BACK AGAINST SSL INSPECTION, OR HOW SSL SHOULD WORK|https://securityevaluators.com/knowledge/case_studies/mutual//|target='_blank'] - based on information obtained 2016-06-03-
* [#2] - [HTTPS Interception Weakens TLS Security|https://www.us-cert.gov/ncas/alerts/TA17-075A|target='_blank'] - based on information obtained 2017-03-20
* [#3] - [The Risks of SSL Inspection|https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html|target='_blank']
* [#4] - [The Security Impact of HTTPS Interception|https://jhalderm.com/pub/papers/interception-ndss17.pdf|target='_blank']
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop