26

At my work all browsers have a custom root CA installed, which then allows them to snoop on all https traffic while the users get the false impression that they are browsing a secure https page.

Why are browsers allowing such easy defeat of https, and not warning the user about it?

EDIT: Based on the answers/comments I realize that I was perhaps incorrectly emphasizing the wrong part of my confusion. I understand that there are some legitimate needs to want to change the CA list, what I don't understand is why you wouldn't want to warn the user if such a change has been made. Doesn't not warning the user defeat the point of the green box next to the address? Do I really need to go through multiple clicks, and then perhaps do a (compromised) search to figure out if the root CA is a real one or not for any computer that I don't own and/or if I let someone else touch my computer?

Improve this question
1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop ♦
    Jul 28, 2018 at 13:48

7 Answers 7

Reset to default
2

There's really no good reason for browsers to allow this, and they should disallow it. Let me address the flawed justifications one by one:

  1. Web development. You don't need a root CA to sign certificates just for a single domain or small finite set of domains you're doing development for. Instead the browser could allow addition of CA certificates valid only for the particular domains, and warn you in the URL bar when such a certificate is being used, rather than allowing addition of CA certificates that can sign for arbitrary domains.

  2. Enterprise and AV MITM. These are just bad ideas for reasons you can find discussed elsewhere. Implement AV on endpoints, not via MITM. Asset control via MITM simply does not work except against really naive users. If you have data so sensitive that you think you need asset control via MITM, you probably need airgapped systems with no internet access.

  3. "If the browser didn't allow it, admins who want to add root CAs would just modify the browser." Yes, that's always technically possible, but browser vendors have the opportunity to make it legally difficult or impossible by simply conditioning use of the browser trademark on not tampering with the CA trust UX. I have been advocating for this for a long time. If browsers did this, users would know as soon as they saw "Firefox" or "Chrome" on a system they sit down at that it's not going to be accepting fraudulent certificates to let someone MITM them as long as they trust that the party who set up the system is law-abiding. This is a fairly reasonable assumption in contexts like workplaces, schools, libraries, etc., and it's testable, so if someone is breaking the rules, it's easy to out them and let the browser vendor initiate legal action.

Improve this answer
5
  • And what about certificates for internal sites that aren't externally accessible? Shouldn't you be able to add a root CA for those?
    – AndrolGenhald
    Jul 27, 2018 at 17:18
  • 2
    @AndrolGenhald: You should not be creating internal sites whose names clash with the global DNS system, regardless of anything to do with CAs. Put them all under a domain you own or a permanently-reserved name that will never be allocated as a TLD and then you only need a domain-specific CA for that domain.
    – R.. GitHub STOP HELPING ICE
    Jul 27, 2018 at 19:00
  • I must not have read carefully enough, you do indeed mention allowing CAs for specific domains. It sounds like it might not be a bad idea, but as it would require Firefox to become less free, I worry it would lead back to Iceweasel again :(
    – AndrolGenhald
    Jul 27, 2018 at 19:20
  • 1
    Aside from satisfying my biases, I'm hoping that accepting this answer (and thus promoting it to the top) would add a little more to the discussion. If someone thinks this answer is wrong - please comment.
    – eddi
    Jul 30, 2018 at 17:43
  • 1
    Wow, I didn't expect this to become the accepted answer. If anyone has suggestions for other attempts at justification I should address in the answer or details I should add to improve it, please comment and I'll try to do so.
    – R.. GitHub STOP HELPING ICE
    Jul 30, 2018 at 18:21
51

As pointed out in comments and answers, there are plenty of legitimate reasons why you would want to add a CA to your browser's trust store, and the mechanisms for doing this require admin access to the machine / browser.

You're implying a trust model where you don't consider your administrator (or past you) to be trustworthy and would like the browser to visually distinguish between a certificate that is publicly-trusted (ie issued by a CA in Mozilla's publicly-trusted list) and one that is privately-trusted because it was explicitly added to the browser's trust store. Maybe the usual green with a warning symbol for privately-trusted?

Good idea! It would also solve my problem of needing two copies of firefox installed: one for testing products that need me to install certs, and one for browsing the internet. You should see if Firefox already has an enhancement for this, and if not, suggest it :)

Improve this answer
17
  • 13
    While I agree that it could be a nice feature, if you truly don't trust your administrator it wouldn't necessarily solve the problem. The admin could still make the browser think it's in the public list depending on how much work browsers put into preventing this and how much work the admin is willing to do. It may be seen as unethical for an admin to circumvent such a feature though, so if you don't think they're downright malicious but merely don't fully trust them, it may be "good enough" in practice.
    – AndrolGenhald
    Jul 26, 2018 at 19:39
  • 10
    @AndrolGenhald I absolutely don't trust the university's IT folks, but I need to install their root cert in order to get internet. Would be nice if my browser told me which connections were being inspected and which were not. (of course I often manually check the cert for ex. banking sites, but not always; a visual warning would be better). I believe browsers trust the public key of the CAs, not the DN, so making the browser think their cert is in the public list should require having access to the publicly-trusted CA's private key.
    – Mike Ounsworth
    Jul 26, 2018 at 19:54
  • 2
    In that case I agree, it would be a useful feature for me as well, but the difference between that and the question is that you are installing it. You're not handing your computer over to the untrusted IT to do whatever they want with it. Also, when I said they could make the browser think it's trusted, I just meant they could likely install it in a way that the browser wouldn't be able to tell that it's not in the public list without checking against an online reference (which would then use a compromised connection anyway), probably by modifying the browser's stored "public" list.
    – AndrolGenhald
    Jul 26, 2018 at 20:02
  • 3
    True, it wouldn't be signed, but if you're a malicious admin would you care? You could either allow it to run unsigned or sign it with your own self-signed certificate that you import to the OS's trusted list, we've effectively moved the problem up one level :)
    – AndrolGenhald
    Jul 26, 2018 at 20:36
  • 5
    @AndrolGenhald: While it's technically possible, browser vendors could make this a legal minefield by conditioning use of the browser trademark on not tampering with the UX for trust of certificates. This is an approach I've been advocating for a long time, since it would bypass present law's unwillingness to treat forged certificates as the acts of fraud that they actually are, and would instead utilize IP law & enforcement by browser vendors to shield users from vulnerability to this kind of fraud by parties who want to do silent MITM.
    – R.. GitHub STOP HELPING ICE
    Jul 27, 2018 at 16:57
30

What you want is to have the browser defend the user against "attack" performed by local administrator.

In such scenario, defense is impossible. The "malicious" admin can always substitute your legit Firefox for an impostor he compiled using his own CAs, that will display green padlock. When you're at work and you're using someone's machine (company's in this case), you're 100% at mercy of the machine owner. If the company wanted to snoop you covertly, they can always install keylogger and see your passwords before they even reach a secure browser.

The green box doesn't indicate safety against local threat, it indicates safety from remote snooping. In this case, it indicates secure connection to your TSL inspector. It indicates that your coworkers in the same LAN can't snoop your passwords, hence the green icon. What happens after the inspector is responsibility of your network admin and the browser cannot tell if it actually uses HTTPs.

What you can do, as an user, is to view the certificate and examine it's certification path. Your browser can't decide if certificate issued by DigiNotar is "better" than one issued by EvilCorp (which may happen to be your employer). Certificates are constantly changed and the CAs also are changed. Browser can't decide if one CA is more trustworthy than the otwer. Only you can decide who is the issuer and if you can trust them - and with what kind of information. You're supposed to use the machine only for work-related activities, so technically you're not doing anything you don't want EvilCorp to see.

Improve this answer
2
  • 1
    I agree with all this answer except "view the certificate path". Does that give you anything, can't a certificate claim to be from any organisation it likes?
    – Richard Tingle
    Jul 27, 2018 at 7:57
  • 1
    @RichardTingle You're bit right. I excluded a truly malicious eavesdropper that would issue "DigiCert High Assurance EV Root CA", install that in your browser and then issue all the chain down to *.stackexchange.com, because admin with that kind of determination has better ways. I guess it's left up to the user to use common sense when installing root CA to install something they recognize as "my CA".
    – Agent_L
    Jul 27, 2018 at 8:27
9
  1. Because the official list changes over time.
  2. Because enterprises have a legitimate need to include "Internal" CAs.
  3. Because enterprises have a legitimate interest in being able to Man-in-the-Middle for security, compliance, or HR purposes.
  4. Because developers and testers have a legitimate need to Man-in-the-Middle.

Would you rather be trusting StartCom today? That's what you'd get with non-trivial modification.

Improve this answer
8
  • 2
    #3 turns out to be a really bad idea. I can prove that no product on the market actually works due to the pigeonhole principal. Hint 1:if a cert were to fall ... Hint 2: what does the MitM unit do with self-signed certs?
    – Joshua
    Jul 26, 2018 at 18:45
  • 1
    @Joshua I'm curious how the pigeonhole principal fits in here? "There can only be N certs in existence, so when I introduce an N+1'th cert, it must match an existing one" ?
    – Mike Ounsworth
    Jul 26, 2018 at 19:06
  • @Joshua #3 may or may not be a really bad idea, but there are a surfeit of vendors (Websense, Netskope, ...) who happily provide it to enterprises who happily use it. A good list of problems is here... but don't expect your boss to change his mind based on it.
    – gowenfawr
    Jul 26, 2018 at 19:08
  • @MikeOunsworth: The interceptor doesn't know which certs to trust, and can only send 2 states to the browser: trust or no trust. In this case N is 2: this cert is trustworthy or this cert isn't. But the real count is 5: Trustworthy, untrustworthy, hard-revoked cert (by browser security update), revoked root cert, or self-signed cert (the user must decide on self-signed).
    – Joshua
    Jul 26, 2018 at 19:12
  • @Joshua Interesting point: the trust/notrust decision is moved from the browser to the proxy. That does raise some interesting issues, but I'm not sure that it's really a counting argument.
    – Mike Ounsworth
    Jul 26, 2018 at 19:18
6

One of the main reason to allow for custom root CA is for web developer. Dev and test build very often use in-house certificate (mainly for cost and ease of creation). Not allowing you to add your root CA would result in (more) different state betwen your dev/build instance and the production one which could generate hard to fix bugs.

Also, company proxy, as a company is (in most legislation) responsible for what you do with its internet, they often use man in the middle, which while ethicaly dubious, is mostly legal and expected.

Another reason to not hardcode root CA is to allow you to remove the one you do not trust anymore (maybe they are under control of a governement you do not trust, maybe they recently had leaked key, etc.) independantly of your browser consideration toward them.

Improve this answer
13
  • 1
    They could still generate a warning about it, and not claim that the website is secure..? That would allow for development to proceed unimpeded, but still warn users that they are not secure.
    – eddi
    Jul 26, 2018 at 14:32
  • 1
    I've seen, played and written website test where anything other than a "secure" in your web browser is a failure, such thing are often black or white, not gray
    – Sefa
    Jul 26, 2018 at 14:35
  • 1
    @eddi If custom additions are still not regared as secure because the original list had them not, then what's the point of custom additions in the first place?
    – deviantfan
    Jul 26, 2018 at 14:36
  • 5
    Another reason within companies: Internal websites with confidential things, that shouldn't be sniffable by the wrong employees just be pluggin in some cable somewhere in the own computer, but won't have a public CA certificate because eg. it's not even reachable outside of the company.
    – deviantfan
    Jul 26, 2018 at 14:38
  • And regarding company sniffing: It's your companies computer and the time your company pays you for. As long as they inform their employees that there is such surveillance, even the moral problem isn't that big anymore. Most companies also have no problem with sending an email to a family member etc., but they don't want to have excessive private usage, malware, p*rn sites, and movie streaming while you're supposed to work.
    – deviantfan
    Jul 26, 2018 at 14:41
1

Generally adding new root certificates requires Adminstrator or root-level access. So, they cannot be installed without the consent of the owner of the computer (unless an exploit is used).

The problem seems to be that you have a misunderstanding of who owns the computer. If the computer was issued by your employer, and they have root access, it’s not “your” computer. It’s theirs and they are letting you use it. You should have no expectation of privacy using that system. It probably said something to that effect in your employee agreement. (The details on this can vary depending on your local laws.)

Improve this answer
0

If your computer is part of a corporate network then it makes sense to add custom root CAs for internal websites that use HTTPS or various update packages or internal apps you push to your clients/=.

Improve this answer

You must log in to answer this question.

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