66

This question indicates parents are to buy laptops for a school to install software and certificates. I am seeking to understand reasons for site certificates installation:

  1. Why would site certificates be installed?
  2. What is the potential for issues with the practice?

I am seeking to understand both legitimate (constructive) reasons for certificates and potential for misuse / abuse. It is unclear from the thread how schools could somehow decrypt traffic with certificates.

gatorback
  • 1,541
  • 2
  • 12
  • 17
  • 13
    Very strongly related if these are root certificates: [My college is forcing me to install their SSL certificate. How to protect my privacy?](https://security.stackexchange.com/q/104576/46674) – reirab Jan 09 '19 at 20:01
  • 1
    Certificates are fine, are cool. are useful to grant whoever uses it is who they claim to be. An additional bonus is that if the relationship is broken, the certificate can be revoken from the certificate authority. – bradbury9 Jan 10 '19 at 08:52
  • I would suggest if you have doubts about the school info provided on certificates to edit the question and adding what exactly is unclear. – bradbury9 Jan 10 '19 at 08:54
  • 2
    Some states have [legislation requiring that schools filter web content](http://www.ncsl.org/research/telecommunications-and-information-technology/state-internet-filtering-laws.aspx). Some schools will set up a transparent proxy rather than relying on each device being set to explicitly use their proxy server (which some would argue is necessary to comply with the laws when people have control over their own devices). Installing their certs would keep the device from complaining about a MITM attack (which is basically what's going on) – Joe Jan 10 '19 at 14:17

7 Answers7

112

There are two different kinds of certificates you could install on a machine:

  1. The first type of certificate is root certificate authority. A root certificate contains just a public key of the certificate authority. A root certificate is a trust anchor that is installed in your machine so that your machine can identify "trusted" sites to connect to, a certificate authority can issue a claim in the form of a server certificate that "X is owner of domain Y" and because your machine trusts the root certificate authority, it'll trust that claim. If the school/company installs a root certificate to your machine, your machine will trust whatever connections made to the school/company's server thinking that it is legitimate. If you install a root certificate, the school/company would be able to intercept any SSL/TLS connections made by your machine that runs through their network without triggering browser certificate errors/warning.

  2. The second type of certificate is client certificate. A client certificate contains a private key that is unique to you and a certificate signed by the school/company's certificate authority. A client certificate is used for your machine to authenticate to the school's infrastructure, proving that it is you that is connecting. A client certificate is used as essentially a better solution to authentication credential than having to remember passwords. A client certificate cannot be used by the school/company to eavesdrop on connections made by your machine to servers that aren't owned by the school/company.

A client certificate is fine to install and shouldn't cause any security concerns. In contrast, be very wary of installing a root certificate, as it is a cause for concern as the root certificate can easily be abused.

gatorback
  • 1,541
  • 2
  • 12
  • 17
Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • 128
    I would state that last line a bit more strongly: a root certificate that is under the control of the same people who own the network used to connect to the Internet **should be regarded as spyware.** It should be avoided if at all possible, and if it's not possible, the machine should be treated as compromised and used as little as possible. There's no legitimate reason to require you to put one on your own personal property. If the school wants to do that, they can supply the laptops themselves. – Mason Wheeler Jan 09 '19 at 19:03
  • 24
    There are semi-legitimate reasons to have a root certificate authority installed. For example, they may find it useful to use an invalid domain (.local) on their private network, but still wish to support encryption. It comes down to trust, even in the larger PKI context. A valid CA isn't always trustworthy, see DigiNotar. – Jesse K Jan 09 '19 at 19:43
  • 14
    @JesseK You're absolutely right, but I'd still trust a public CA more than I'd trust a typical school system. A school system isn't at risk of "death" as a "collective organism" if their certificates get hacked the way a public CA is, a school system has the ability to *impose a severe incentive gradient* to the point of forcing in favor of being trusted while a public CA has no such leverage unless it reaches sufficiently large market saturation, and a school system leaking the master keys is way less likely to get reported or dealt with properly due to institutional factors. – mtraceur Jan 09 '19 at 20:22
  • 1
    @mtraceur Oh, I have no doubt the school system shouldn't be in the CA business, but there are lots of mediocre practices that you'll encounter in the world, and this is hardly the worst. – Jesse K Jan 09 '19 at 20:45
  • 7
    Not all trusted certificates need be root CAs. Windows, which relies on certificates for many authentication purposes in a domain, has the concept of "enterprise trust" certificates, which are limited to specific authentication tasks. Another example is WPA2-Enterprise/802.1x certificates, which nearly all operating systems allow you to provision a certificate trusted for network authentication only. – user71659 Jan 09 '19 at 21:21
  • @JesseK: In which case they should name-constrain it. See https://security.stackexchange.com/a/130674/25512 – Joshua Jan 10 '19 at 00:10
  • What is the alternative to installing though? The CA certificate is probably used to create certificates for internal sites. The alternative seems to be to use the sites without verification that it's the school you are talking to. That sounds also very unsecure. I think @Joshua commentary is useful, name-constraints seems, to me, better then outright not installing a certificate. – kutschkem Jan 10 '19 at 08:11
  • @kutschkem: If the app you use supports constraining the certificate, then you can do that. Otherwise, you may want to install the certificate into an alternate browser profile and use that alternate profile only for accessing the school sites. Firefox uses its own certificate store and I believe it's per profile. I believe Chrome and IE/Edge uses the system certificate store, and this is shared with all instances in that profile. Don't know if there's any way to constrain certificate to a specific Chrome/IE/Edge profile. – Lie Ryan Jan 10 '19 at 08:28
  • 27
    Maybe you can add a third kind of certificate to your post: When the school uses an untrusted certificate for their website, e-mail server or similar, they may install the server certificate on the clients, so it is trusted even when no trusted CA has signed it. This is another legitimate use without abuse potential, when it really is a certificate for their own domain name. – allo Jan 10 '19 at 10:09
  • 2
    Note that while seeing a root cert as spyware is reasonable, sometimes "spyware" is required on computers. For example, working on sensitive networks often involves monitoring of all user activities, including encrypted web browsing. Government laptops often have root certs installed so the firewalls can monitor all traffic and look for malware that is connecting outbound using HTTPS. Personally I'd be fine with my kid's **in school** computer activity being monitored in the same way, to make sure they are not being exploited or bullied, etc. – Todd Wilcox Jan 10 '19 at 15:04
  • 3
    @ToddWilcox Yes, but we're not talking about in-school computer activity. We're talking about laptops that 1) get taken home and 2) are the property of the student (or, more likely, their parents). There's no legitimate purpose for the school to put spyware on such a machine. – Mason Wheeler Jan 10 '19 at 15:34
  • 1
    @MasonWheeler I think the legitimate purpose is to monitor what goes on in school, and the resulting lack of security at home is a side effect of that. Maybe it's not a great way to achieve that purpose, but it is a legitimate purpose. – Owen Jan 10 '19 at 22:58
  • 1
    // , @MasonWheeler, could you be convinced to add that comment as an answer? I consider myself a pretty secure boy, but I only really got this when you pointed it out. – Nathan Basanese Jan 11 '19 at 01:41
  • @allo That would be just laziness on the school's part then. Getting genuine, signed SSL certificates is free as long as you have the domain. You could argue if it's internal only then it would incur the cost of maintaining the domain, but that's it. – Magisch Jan 11 '19 at 07:15
  • 1
    To get this info right (I'm learning myself), it seems that using such a root certificate would only be considered "spyware" when going through the school's servers? So would that only be when inside their network? – user3773048 Jan 11 '19 at 08:25
  • @Magisch Of course. But the question here is "why" and not "how can they do better". And this would be a fourth reason with some kind of legitimation, even when they *could* do better. – allo Jan 11 '19 at 09:13
  • @allo but the OP asks about "why would a school need to" and your example falls under "they don't need to, they're just too lazy to do security properly" – Magisch Jan 11 '19 at 09:18
  • Of course, they do not *need* to. But I think actual question seems to be about "Is there a reason to do this despite incepting traffic and other nasty things". And you do not know if there actually *is* a reason for an own CA or self-signed certificates (e.g. ``.local``) domains. Of course you can discuss if this is a bad way to manage the DNS in your network (it probably is), but this is more a question for serverfault than for security.stackexchange. – allo Jan 11 '19 at 09:36
  • @user3773048 Because the certificate contains root certificate authority. This means you can issue certificates for other sites and have them be trusted by the computer, and it's possible to do this without the site owner's knowledge or consent. This means that the network operator can decrypt HTTPS traffic coming in, re-encrypt it with their own fraudulent certificates, and forward it on to the client, which has a root certificate saying "there is nothing wrong with this transaction" when it's actually compromised. – Mason Wheeler Jan 11 '19 at 16:00
  • @NathanBasanese Done. – Mason Wheeler Jan 11 '19 at 16:18
  • @MasonWheeler I like and appreciate your full answer to this question, but a certificate, on its own, is not software; and therefore cannot be spyware, despite the obvious parallel that it can give an attacker some level of spying capabilities. I don't mean to be incredibly pedantic, but it infuriates me when the media incorrectly use security terminology, so we have to be very precise about how we use these terms. A root certificate 'facilitates spying', that i don't think anyone can argue with. Upvoted your answer. – hiburn8 Jan 16 '19 at 19:27
22

Well there is at least a legitimate use case. It is common for large organizations and university to run a private PKI. That means that they have a (secured) root certificate that is used to sign (with enventual sub authorities) various certificates.

And it is also common to use that private PKI to sign HTTPS servers which are not intended to by publicly used: the only requirement is that the (internal) clients all declare the private root certificate.

The risk is a MITM attack on HTTPS connections. In fact it is often presented as a feature by security admins. Many of them would never allow HTTPS connections from a secured environment if they cannot be deeply inspected (*). That actually means that when you HTTPS from the internal network through the dedicated proxy, everything can be logged. The only rule is that users shall be warned about it. It something is really private, it should simply not be done from the internal network.

It is common to use a strong peripheral security on large organizations through filtering proxies. Those proxies analyzes the peer and the kind of traffic in order to prevent various attacks and infections. But as HTTPS is crypted the proxy cannot know what is actually exchanged unless the MITM attack is active.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 5
    It would be great if this kind of internal CAs declared authority only over the domains used inside the organization, but I don't think most systems support this kind of limited trust anyway. – Jan Hudec Jan 09 '19 at 22:45
  • @JanHudec I think you can issue and install a private wildcard certificate for `*.mydomain.local` with no need to install a root certificate. – jjmontes Jan 11 '19 at 14:50
  • 1
    In theory [HPKP](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) should alleviate the MITM problem, but it's not widely deployed (for good reason). – jjmontes Jan 11 '19 at 14:51
  • @jjmontes, you can, but in a larger organization you really do want to have a separate certificate for each service to limit the damage in case the one in compromised, and that means installing an organizational certification authority. But that authority should only have authority over your domain—both to again limit damage in case it gets compromised, and to prevent accusations of misusing it. – Jan Hudec Jan 11 '19 at 20:59
  • *.mydomain.local is under reserved TLD. While it used to be somewhat common practice, as of 2012 CA/B, public CAs are no longer allowed to issue certificates for internal domains. This means that using TLS with .local TLD will always require installing root certificates. – Lie Ryan Jan 14 '19 at 09:36
9

If the browsers of student's systems has a school certificate in the trusted root of the certificate installation (depending on the browser this cert might need to be the system's certificate bundle, or the browser's) then if traffic is going via an intercepting proxy (such as via on the school's wifi), the school is able to decrypt the traffic with the private key. Connections to the websites are therefore not secure end-to-end, but the proxy can re-establish a secure connection to the website itself and keep the data secure in transit at least. These devices are also known as SSL-Decrypters (although really its TLS/SSL), and almost every organisation i've worked with uses these in some capacity (i'm a penetration tester, i work in a lot of banks).

There are a number of reasons why you would want to do this, but most installations boil down to companies wanting to snoop on users to more easily spot potential security incidents (malware on the wire) or just detect improper usage.

I was a school kid once and half of what i did on those computers was not school work at all, if schools can work out how to tackle the problem of kids using systems (even their own) for illegitimate tasks, its a good thing in my book. I'm a huge privacy advocate, but the school will only have these decrypting powers when you are connected to the internet via their proxy. So if you are connected to a network you don't trust and don't own, on a system you didn't provision yourself, you are playing by (and agreeing to) someone else's rules.

hiburn8
  • 441
  • 2
  • 11
  • 3
    "the school will only have these decrypting powers when you are connected to the internet via their proxy" depending on how the machine is set up, this may not necessarily be true, it is possible that the machine is setup to still use the school's proxy even when outside the school network. Also, if the school leaked their private key to this certificate, your machine will be vulnerable to eavesdropping by the hacker if they set up a proxy/access point that you happen to be using outside of school network. – Lie Ryan Jan 09 '19 at 15:02
  • Good point about the system-wide proxying, upp'd. Although 'proxy even when outside the school network' is just not possible. If you are saying that the system could connect to an internet-facing proxy at all times... sure... but that internet-facing endpoint is the school's network in my opinion, even if its hosted on AWS or wherever. If you can stop the system talking to that proxy, it cannot physically proxy anything. – hiburn8 Jan 09 '19 at 15:10
  • 2
    Assuming OP is referring to adding a root certificate to the truststore (which I assume is the case) this is the best answer. I don't think this is a *good* practice but unfortunately it does seem to be the norm, at least for large corporations. – Captain Man Jan 09 '19 at 20:47
  • If it's your device, even if you are using the school network, common traffic for other services like mail, chats, software upgrades will be under school's control (and maybe logged or seen by someone), putting users at risk. Nowadays users don't really have control over the background processes that run on their devices so asking them to not use those services is not an option. Bottom line is: an organization not in the CA business should never require root certificates that can sign arbitrary domains in users personal computers, and users should never accept them. – jjmontes Jan 11 '19 at 15:03
7

It depends on what you mean by "site certifite", but this answer is for the case of a root certificate authority:

Most schools - at least in the UK - I don't know about other countries, use some form of web filtering. This typically involves a firewall/proxy that intercepts web traffic and inspects the content of the page.

However HTTPS provides end-to-end encryption between the user's computer and the website, as a result when connecting to a HTTPs website all the proxy would be able to see is the destination IP address, but no information about the contents of the web page.

It would not be practical to simply block all HTTPS traffic, so instead to maintain the filtering system requires the school to break the end-to-end encryption model, by terminating the encryption at the firewall/proxy. It then passes on the connection to the user, but it has to be using their own certificate. This setup enables them to read all communication between the user's computer and the website. (A man-in-the middle attack)

HTTPs certificates are used to prevent this occurring maliciously - because the certificate presented was signed by the school's firewall/proxy (rather than a trusted certificate authority, e.g. Verisign) the laptop's software will not trust the connection (you would see a security warning/error message in your browser). However by installing the school's certificate as a trusted root authority, the connection would instead be trusted and your browser would then function as normal.

The consequence of this is that any HTTPS communication from your laptop can be intercepted and read by the school (even though it appears in the browser as being secured).

More generally anyone who had access to the school's certificate and private key, and also had physical access to intercept your laptop's internet traffic, would be able to read your SSL/TLS communications.

Have a look at this vendor for example: https://www.rm.com/products/online-safety-tools/rm-safetynet/ssl-interception

To avoid this, don't install their certificates, and instead use an OpenVPN connection over a port that they are not blocking (try 53, 80, 8080, 443 etc.)

jacob_pro
  • 321
  • 1
  • 4
6

There are two reasons:

The innocuous reason is that the schools is implementing certificate-based authentication and have their own PKI. The clients need the PKI-root certificate to verify the server certificates they are presented.

The malicious reason is SSL interception. With a root certificate installed, browsers can be redirected to a proxy, where SSL is intercepted and the content inspected before it is re-encrypted and sent to the actual server (or vice versa).

Unfortunately, you can't get one without the other. A root certificate is a root certificate. Your countermeasure is to not use this computer for sensitive things, such as online banking or private messaging.

Tom
  • 10,124
  • 18
  • 51
  • You could check if they are doing SSL interception in your web browser by checking the certificate information in your browser about the website you visit and check who issued the certificate. If you are on Facebook, you check the certificate chain and notice that "Facebook's" certificate is signed by your school CA, you are being watched. But note that this is only specific to this one connection. They might only eavesdrop on specific TLS connections while routing others normally. – Philipp Jan 10 '19 at 11:27
  • 2
    @Philipp you also never can be sure that they didn't listen yesterday when you checked, but are listening today. – Tom Jan 10 '19 at 11:29
  • // , For more on the malicious (or simply arrogant) causes for which an organization might do this, check https://security.stackexchange.com/a/201288/78278. – Nathan Basanese Jan 11 '19 at 17:52
5

(Posting this as an answer by request, and also since the original comment seems to have been well-received and I wouldn't want it to get deleted in a comment purge.)

In response to Lie Ryan noting that there are two basic types of certificates, root certificates and client certificates, and that client certificates are fine but you should be wary of custom root certificates because they have a potential for abuse, I added:

I would state that last line a bit more strongly: a root certificate that is under the control of the same people who own the network used to connect to the Internet should be regarded as spyware. It should be avoided if at all possible, and if it's not possible, the machine should be treated as compromised and used as little as possible. There's no legitimate reason to require you to put one on your own personal property. If the school wants to do that, they can supply the laptops themselves.

Another commenter asked what the link is between spying potential and being the operator of the network. So, some further expounding:

What a root certificate means is that the certificate owner not only certifies that its site is legitimate, but also has the authority to issue other certificates. This is how Certificate Authorities and the entire certificate infrastructure works: by installing the root certificate you say that you trust the judgment of the CA, and the CA then certifies that ordinary sites are legitimate, which you accept because a trusted CA said so.

The thing is, there's no technical requirement anywhere in that process involving input from the owner of the site. That's where the trust part comes in; we accept on faith that they've authenticated the site before issuing a certificate for it, and the few times when a CA has been caught failing to do so, retribution from the Internet has been swift and decisive, bringing consequences up to and including the CA going out of business for betraying the trust of essentially the entire world.

But if your main business isn't being a CA, that changes the calculus. If you run a network and can issue a rogue root CA on your clients' computers, you gain the ability to perform a man-in-the-middle attack. It works like this:

  • Client navigates to https://security.stackexchange.com
  • Network MITM system pretends to be a client and decrypts the content
  • Network MITM re-encrypts the content with its own fraudulent StackExchange certificate, issued by the network's root CA
  • Client's browser receives the data, checks the encryption, sees that it's using a certificate signed by a trusted root CA, says "there's nothing wrong with this connection," and displays it to the user
  • User is unaware that the network is potentially capable of both reading and modifying his or her HTTPS traffic

This will only work on the certificate owner's network because other networks that don't have a root certificate installed on your machine aren't going to be serving up phony site certificates.

Mason Wheeler
  • 1,625
  • 1
  • 11
  • 15
4

You can make a parallel with a company. Why would a company need to install certificates on employee laptops (or personal devices)?

It comes to authentication. A certificate can be used as a credential to access a secure resource (school/company portal) without the need to provide a password. We all know the disadvantages of using passwords, thus a certificate (or another credential) is issued to each student that will identify him/her when accessing school web applications (mostly).

In the company I work for, prior to moving our authentication infrastructure to SAML 2.0, if we wanted (for convenience) to access enterprise related web applications using our personal mobile devices, a company certificate was installed in the device.

Filipe dos Santos
  • 1,090
  • 4
  • 15
  • 1
    I totally agree with the above response from Filipe. Using certificates is the modern way of overcoming password usage on multiple enterprise/organization portals. This also helps from password leaks via Malware with keylogger utilities. – CyberDude Jan 09 '19 at 17:29
  • 1
    @CyberDude If there's malware on a laptop that logs keys, that malware could also easily steal the certificates ;) – marcelm Jan 09 '19 at 19:00
  • @marcelm This statement applies to every laptop/device that holds a certificate. It's not a concern regarding the specific requirement of the school to use certificates. – Filipe dos Santos Jan 09 '19 at 19:23
  • 1
    @marcelm There's modern OS features that prevent that. For example, Windows has TPM-based virtual smart cards place the certificates solely in the TPM and iOS/macOS has similar secure element-based keys. Windows Defender Credential Guard isolates domain secrets in a separate VM outside the OS. – user71659 Jan 10 '19 at 04:37
  • This response is a bit ambiguous as it makes no distintion between client and server and root certificates. – jjmontes Jan 11 '19 at 15:09
  • @jjmontes it makes no sense for a school to install root or server certificates in a personal device... – Filipe dos Santos Jan 11 '19 at 15:10