By my admittedly limited understanding of how HTTPS/TLS works, the end user (me) initiates a connection with a remote server which signs every one of its messages with a public key. This public key can be verified (magically) by checking the certificate, which is signed by a CA that vouches for the integrity of that certificate.

The upshot of this is that if I trust a CA, that CA can sign any certificate and say it is valid and my machine will be just fine with it; if a rogue CA is added to the trusted registry of my computer, then anyone who knows that rogue CA will be able to get their cert signed and pose as - potentially - any website and perform a man in the middle attack.

My corporation has just added their own cert as a root CA to all computers in the network. Should I therefore assume that all traffic I send is compromised?

  • 4
    Just wanted to note that there are reasons other than eavesdropping that a company may use their own CA for. Protecting internal applications with SSL, for example. But yes, your thought process is essentially correct. Once they have a CA cert installed, they can sign anything and MITM if they want. If the application gives you the option of examining the server's certificate (like all major browsers do), you should be able to at least tell when it's happening.
    – glibdud
    Commented Dec 1, 2015 at 13:53
  • 9
    Side note: you generally shouldn't consider anything done on a corporate computer to be private, no matter what certificate they use. Normally when you start employment one of those papers they make you sign essentially states that by using company computer you are using company property that they have full rights to search/monitor. They don't even need their own cert to do this. Commented Dec 1, 2015 at 14:12
  • 1
    @DavidGrinberg of course they don't, I was asking purely out of academic curiosity rather than actually concerned about my data on my PC. The worst thing I do on my PC is log into my StackExchange account :-)
    – Dan
    Commented Dec 1, 2015 at 14:14
  • "which signs every one of its messages with a public key" - the public key is only used during the initial setup/handshake of the TLS connection. During that handshake, a symmetric key is generated and that's used to secure the communications thereafter. (If the public key were used throughout, there'd be no way for the data that you send to the server to be secure) Commented Dec 1, 2015 at 14:18
  • 2
    Yes, this is frequent with banks, brokerages, and high security companies. Bloomberg does this for issuing self-signed certs for internal sites and client certs for SSO. You should only use their internet for work-related purposes. If you need privacy, you should use your mobile phone's cell connection.
    – Chloe
    Commented Dec 1, 2015 at 20:15

4 Answers 4



Yes. (If you consider "My company's admins can change my HTTP(s) traffic" compromise.) Except for some programs that pin their certificate use and fail if another certificate is used.

That's pretty much the idea of SSL inspection: Open up SSL/TLS, do some anti-virus-scanning, close up SSL/TLS again.

And in place of that "do some anti-virus-scanning" you can substitute any manipulation of the traffic, you want.

But on the other hand: whoever can install a root CA on your system has superuser power already. So there's a million other ways that they can interfere/listen in.

  • 6
    "But on the other hand: whoever can install a root CA on your system has superuser power already. " while true, it takes a lot of bureaucracy to reach this point (and there is a notification sent out to all IT staff when a change request like this is made) Would it be frowned upon if I added a follow-up question as an edit, or should I post that in a new question?
    – Dan
    Commented Dec 1, 2015 at 9:39
  • 7
    Usually "one question per question. Commented Dec 1, 2015 at 9:40
  • 3
    Okay, I've asked the follow-up here.
    – Dan
    Commented Dec 1, 2015 at 9:42
  • To be perfectly honest unless you are checking the certificates you are getting by hand (i.e. look at who the certificate is signed by) I would consider all systems compromised pretty much ( at the same level as company root cert anyhow). Have you ever looked at how many root certs there currently are in your usual browser? And have you looked at what the requirements are to get on that list? The root ca of your company might actually be quite a bit less risky than what you already have there from the get go (see latest dell certificate scandal).
    – DRF
    Commented Dec 2, 2015 at 19:42
  • @DRF: Yes, but a regular CA makes you pay for each cert. And they can't (legally) supply a sub-CA for wholesale SSL-interception purposes. You get blocked by Chrome for pulling stunts like this. Also: Anything that forces an attacker from shotgun hit-everyone-approaches to sniper-rifle hit-just-one-guy approaches is worth it by me. Commented Dec 3, 2015 at 17:24

Technically, yes. However, you can still verify whether your connections are being compromised or not:

  1. Install a web browser which uses its own certificate bundles (your employer may forbid that too).

  2. Connect to a trusted site using a trusted computer (e.g. at home) and note the certificate fingerprint. When you connect to that site at work, check the certificate fingerprint manually. You'll have to repeat the check every time for every page to be sure, and note new fingerprints every time the site updates its certificate.

  • 3
    In a corporate environment, you typically don't need to do all that: certificates used for SSL interception and inspection are usually very easy to pick. For instance, if you use an AV software that performs HTTPS scanning, you can simply check the certificate authority for the site you visit: if it has a single level and the root is you AV vendor, the connection has been intercepted. if you know what root comes from your CA, you can check if it was used to sign the server's certificate directly.
    – Stephane
    Commented Dec 1, 2015 at 13:31
  • For #1, the easier option for a corporation that's doing https monitoring of some sort is just to block https traffic not using their CA from non-whitelisted domains. In my employer's case this is banking, healthcare, 'anonymous' employee surveys (but only if someone complains), and at least one major client that vocally objected to traffic to them being tampered with. Commented Dec 1, 2015 at 16:11
  • As @glibdud commented above, any common browser will allow you to inspect the certificate used while delivering the current page. Click the security information icon or whatever and check if your company's cert is in the chain for this page. You can do that at the office with the standard browser at any time, no need to write down fingerprints at home :)
    – JimmyB
    Commented Dec 1, 2015 at 18:19
  • It's not your computer, it's their computer.

  • It's not a compromise for them to take control of it.

So what should you do?

If you want to e.g. email your doctor about your cancer diagnosis without alerting your employer, you should do it from your smartphone, using the data connection.

Don't use work computers for personal use, people!


This is not really a stand-alone answer, but some more commentary on TLS/SSL decryption.

First of all, your company may not have published a new root CA cert to intercept this traffic. They may be signing software/plugins/etc. that they want to run as trusted code. They may also be publishing internal certificate for internal HTTPS sites. While this change does give them the ability to perform man-in-the-middle interception of TLS/SSL traffic, they may not be doing so.

They may be legally required to notify you if they are recording your decrypted HTTPS traffic. Even if they are not required to, I would hope a good HR department would issue some notification that this is occurring.

Having worked with this type of product, many TLS/SSL decryption tools intentionally avoid decrypting streams that may contain sensitive information (PII and PHI) because then the entity doing the decryption earns the responsibility for protecting that data and so any potential liability for loss of that data in the case of breach or even accidental leakage, which is a risk most companies (or at least their legal counsel) won't accept. So your connection to bank.com or doctor.com may remain confidential, but your connection to onlinestorage.com or webmail.com might not.

There are many legitimate reasons for intercepting this traffic (DLP, identifying unauthorized traffic, other content filtering, QA/troubleshooting, network optimization, load-balancing, etc.) and most folks do try to do it in a responsible manner.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .