mjhjmtu

Question

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:

Why would site certificates be installed?

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.

Very strongly related if these are root certificates: My college is forcing me to install their SSL certificate. How to protect my privacy? — Jan 9 at 20:01
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. — Jan 10 at 8: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. — Jan 10 at 8:54
Some states have legislation requiring that schools filter web content. 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) — Jan 10 at 14:17

gatorback 5681512 · Accepted Answer · 2019-01-11 01:27:05Z

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

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.

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.

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. — Jan 9 at 19:03
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. — Jan 9 at 19:43
@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. — Jan 9 at 20:22
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. — Jan 9 at 21:21
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. — Jan 10 at 10:09

Serge BallestaSerge Ballesta 16.5k32661 · Accepted Answer · 2019-01-09 17:16:38Z

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.

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 9 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. — Jan 11 at 14:50
In theory HPKP should alleviate the MITM problem, but it's not widely deployed (for good reason). — Jan 11 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 11 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. — Jan 14 at 9:36

hiburn8hiburn8 31717 · Accepted Answer · 2019-01-09 14:50:29Z

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.

"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. — Jan 9 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. — Jan 9 at 15:10
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. — Jan 9 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. — Jan 11 at 15:03

jacob_projacob_pro 3013 · Accepted Answer · 2019-01-10 15:19:08Z

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.)

score 6 · Accepted Answer · 2019-01-10 20:53:11Z

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.

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. — Jan 10 at 11:27
@Philipp you also never can be sure that they didn't listen yesterday when you checked, but are listening today. — Jan 10 at 11:29
// , For more on the malicious (or simply arrogant) causes for which an organization might do this, check security.stackexchange.com/a/201288/78278. — Jan 11 at 17:52

Filipe dos SantosFilipe dos Santos 1737 · Accepted Answer · 2019-01-09 14:17:39Z

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.

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. — Jan 9 at 17:29
@CyberDude If there's malware on a laptop that logs keys, that malware could also easily steal the certificates ;) — Jan 9 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. — Jan 9 at 19:23
@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. — Jan 10 at 4:37
This response is a bit ambiguous as it makes no distintion between client and server and root certificates. — Jan 11 at 15:09

Mason WheelerMason Wheeler 1,4261913 · Accepted Answer · 2019-01-11 16:18:14Z

(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.

gatorback 5681512 · Accepted Answer · 2019-01-11 01:27:05Z

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

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.

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.

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. — Jan 9 at 19:03
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. — Jan 9 at 19:43
@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. — Jan 9 at 20:22
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. — Jan 9 at 21:21
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. — Jan 10 at 10:09

Serge BallestaSerge Ballesta 16.5k32661 · Accepted Answer · 2019-01-09 17:16:38Z

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.

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 9 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. — Jan 11 at 14:50
In theory HPKP should alleviate the MITM problem, but it's not widely deployed (for good reason). — Jan 11 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 11 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. — Jan 14 at 9:36

hiburn8hiburn8 31717 · Accepted Answer · 2019-01-09 14:50:29Z

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.

"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. — Jan 9 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. — Jan 9 at 15:10
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. — Jan 9 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. — Jan 11 at 15:03

jacob_projacob_pro 3013 · Accepted Answer · 2019-01-10 15:19:08Z