22

I found there are some companies claim that they offer service that can eliminate SSL/TLS blind spot, such as Blue Coat and Gigamon. Are they talking about some way of decipher the https content (breaking the encrypting algorithms) or just man-in-the-middle attack ? If it is a MITM proxy, can I simply detect it by checking the CA of the certificate installed on my browser?

My question is about whether there is way to monitor https traffic without MITM attack and whether it is possible for MITM proxy to dupe users by showing certificates with real CAs (DigiCert, Comodo) so I cannot just tell the difference by looking at the CA.

Improve this question
4
  • 6
    Dupe (or near) of security.stackexchange.com/questions/2914/… security.stackexchange.com/questions/7323/… security.stackexchange.com/questions/8145/… security.stackexchange.com/questions/14676/… Commented Oct 3, 2015 at 1:01
  • 2
    I do not think it is a dupe of any of those. This is asking how it is possible for products to remove the TLS blind spot. If you really understand TLS, perhaps there's enough information in the other questions to answer this question, but if you really understood TLS, you wouldn't be asking the question in the first place. Commented Oct 4, 2015 at 3:00
  • 1
    Them that owns the computer, owns the connection. Yes, for information infiltration/exfiltration and malware prevention, it is common to install a certificate and scan https traffic for content in company networks. Commented Oct 4, 2015 at 4:49
  • The phone company owns the phone lines and exchange, but wiretapping is still an offence. Commented Oct 11, 2017 at 18:16

6 Answers 6

Reset to default
35

Installing a root certificate on users browsers, and conducting a MiTM attack on employees is unfortunately a standard practice at many companies.

There's a few ways you can detect this.

  1. One way is looking for a root CA cert installed on your computer and see if you don't recognize one of the CAs. This of course requires an in-depth knowledge of what real root CAs are, and what fake MitM proxy providers are.

  2. Another is simply looking at the certificate an https websites generates and examine who it's signed by. The cert of all https sites will be signed by the company providing the MiTM attack proxy.

  3. A third way is to install Firefox, preferably a version that doesn't install and runs as a standalone. Firefox doesn't use the system provided certs, but uses its own certs. You can get this from http://portableapps.com/ If you then get a security warning about a self signed certificate, you're being MiTMed by your company.

Improve this answer
19
  • 15
    Just to clarify: Using Firefox will not enable you to browse securely if your company is intercepting all SSL connections. It will give you a warning letting you know that this is going on but your only choices then are not to surf or to accept the company signed certificate anyway. Commented Oct 2, 2015 at 19:04
  • 3
    The number of root certificates installed by default is so large that there are many I wouldn't recognize. So seeing one that I don't recognize doesn't tell me a lot. Commented Oct 3, 2015 at 8:31
  • 2
    And what if you work at one of the large companies that issue certificates? Commented Oct 4, 2015 at 5:02
  • 2
    I don't have a particular problem that they are doing this, I'm having a problem that they didn't tell me. Commented Oct 4, 2015 at 6:02
  • 3
    @JamesSnell I doubt there are laws requiring an employer to break the security of SSL protected sites. And I am guessing a lot of those SSL protected sites do not approve of such attacks against the security they put in place. Commented Oct 4, 2015 at 12:18
7

It's pretty clear that they aren't able to decrypt any encrypted traffic for which they're not in possession of encryption key. They are more likely doing it like mitmproxy does; They might deploy their root certificate to all clients of a company by group policies for example, and are then able to replace all certificates of web servers,... on their own because they are now considered a trusted CA (Certificate Authority) in all web clients.

This would allow them to decrypt all connections which are encrypted based on any certificate in the certificate chain issued by their own root CA. This technique is also used by some anti virus software.

This won't work with symmetric encryption with a PSK (Phase-Shift Keying), of course.

Improve this answer
5
  • How can I tell whether the certificate is the original one sent by the target server or generated by the MITM proxy ? If I find the issuer of the certificate is a common CA, does it mean I am using the original certificate not the fake one ? My concern is that if those vendors can somehow generate certificates dynamically to match the CA used by original certificate then I wont be able to tell any difference. Commented Oct 2, 2015 at 16:58
  • You shold compare the list of trusted CAs with the list of CAs trusted by default. If you didn't install the additional CAs (if there is one/some) then it's likely somebody is trying to decrypt your encrypted traffic. Commented Oct 2, 2015 at 17:04
  • Don't you mean some virus software, not anti virus software? Commented Oct 3, 2015 at 2:26
  • No I dont there are some anti virus softwares that add their own certificates to monitor incoming network traffic that is encrypted. Commented Oct 3, 2015 at 9:19
  • In some contexts PSK is Phase Shift Keying, but in TLS it is Pre-Shared Key. Although TLS has long had it as an option, as of 2015 it wasn't ever used by browsers, or most other HTTPS; it might have been for some other things like LDAPS or SNMPS, and definitely was and is for IPsec and WiFi (which of course aren't SSL/TLS). TLS 1.3 in 2018 modified the former PSK to replace the former session resumption capapbility, so now it is becoming common -- but that PSK comes from a cert-based handshake, subject to snooper-root MITM. Commented Sep 9, 2019 at 1:40
5

Blue Coat: How to Gain Visibility and Control of Encrypted SSL Web Sessions :

Because a proxy is an active device (i.e., it terminates traffic), it acts as both the server to the client, and the client to the server. Thus, it has a native understanding of both the user and the application. For many organizations, users will only connect to the Internet via a proxy – because of the control it affords an enterprise. Because a proxy terminates connections, it offers a critically important control point for policy, performance, and protection of all Web-enabled user and application interactions.

Blue Coat SG is the leading secure proxy appliance, offering enterprises “the power of the proxy” in a broad range of sizes. Blue Coat extends that leadership by offering SSL proxy functionality on its market-leading proxy appliance.

Whereas takes an other approach -decryption: ( Giamon: SSL Decryption: Uncovering The New Infrastructure Blind Spot)

The offloading of SSL decryption also eliminates the need to have multiple decryption licenses for multiple tools. After all, a security appliance with integrated SSL decryption, for example, does not benefit other tools, such as application performance monitoring. Gigamon can supply decrypted traffic to multiple tools simultaneously, maximizing the overall efficiency, security, and performance of the infrastructure. An associated benefit of this approach is that the private keys can now be securely uploaded to just the visibility infrastructure instead of sharing it with multiple tools.

It also delivers to IT and security administrators the right level of visibility into traffic, including SSL-encrypted segments that are at the heart of today’s cloud infrastructures.

GigaSMART decrypts the packets and sends the traffic to multiple out-of-band tools, including intrusion detection (IDS), data loss prevention, and application performance monitoring for analysis.

Improve this answer
1
  • So BLUE Coat is using a MITM proxy. However, for GigaSMART, how can they decrpyt the traffic ? They are talking about uploaded private keys. This is a little too hard to believe. Commented Oct 3, 2015 at 7:21
3

So there are 4 common vulnerabilities in SSL that immediately come to mind:

  1. Install a root certificate on your computer that allows the interceptor to be an SSL authority and create forged SSL certificates. This requires them to have administrative access to your computer, even still the SSL fingerprints will be different.
  2. Do a MITM attack on non-SSL sites then use SSL Stripping when connecting to SSL sites. HSTS (Strict Transport Security) can help mitigate this by caching for a period of time that the site uses a secure connection (and not allowing insecure connections for this period of time).
  3. Where the SSL configuration is improperly set-up, this can be seen by running the site through an SSL Labs test and noting the vulnerabilities. This can include using weak ciphers, weak key exchange or using outdated SSL protocols instead of going through TLS.
  4. The hashing algorithm on the certificate also plays a major part in keep SSLs secure, hence why Chrome is phasing out SHA1.
Improve this answer
2
  • 1
    I'm not sure 4 key vulnerabilities are the right words. None of them are really vulnerabilities in SSL. Perhaps 4 weak spots to SSL encrypted web traffic would be better? Not really sure. Commented Oct 2, 2015 at 18:17
  • Edited it a little bit now. :) Commented Oct 2, 2015 at 18:24
2

No, noone can break 2048-RSA certificates yet that are commonly used - not enough computing power.

However your browser can be tricked via another (fake) certificate. It's very similar to how Fiddle works to view encrypted traffic (Fiddle is a network activity analyzer)

  1. First Fiddler creates & installs a trusted root certificate.

  2. You browse https://www.googole.com

  3. Fiddler creates a (fake) certificate for Google and signs it with the certificate from step 1.

  4. Fiddler intercepts all traffic from you to google and back (and the portion of the traffic between you and Fiddler is signed with the fake certificate). Your browser is duped into thinking the fake certificate is OK and you suspect nothing.

A neat trick.

However you can easily smell a rat if you look at the signing authority of the site's certificate and seeing that it's not one of the recognized brands (Thawte, VeriSign, etc)

Improve this answer
3
  • 2
    For the Fiddler case, it is not designed to perform a MITM attack. Is it difficult to generate certificate dynamically with the matching CA as the real certificate (Thawte, VeriSign, etc)? If so ,it wont be so easy to smell a rat. Commented Oct 3, 2015 at 10:45
  • 1
    @PeterLi Indeed, if you sign your CA certificates yourself, you can just as easily claim to be Thawte, VeriSign, et. al. So it may be necessary to check the fingerprints of these root certs against the original fingerprints obtained e.g. from here, but not via the compromised system (as it might modify such pages to reflect the fake fingerprint)! Commented Oct 4, 2015 at 10:16
  • 1
    What happens if they replace those Thawte, VeriSign, etc certificates? can they? Commented Oct 18, 2017 at 16:48
2

Also bear in mind that nextgen Security Appliances like those from Palo Alto and Huawei USG firewalls, have this functionality baked-in. This is ostensibly to deal with the "blind spot" in which because outbound SSL is typically allowed, can be used by employees to circumvent security (shocking I know). By decrypting the SSL, appliance can perform application-based filtering,

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.