17

I am not sure I understand how TLS works correctly. To my understanding trusting a certain website's certificate is all about trusting that website or not, but the questions below suggest that trusting ONE certificate would put everything you do online at risk.

My college is forcing me to install their SSL certificate. How to protect my privacy?

I can't access websites that use HTTPS, instead getting the message “your connection is not private”!

I have trusted self-signed certificates more than once from many websites because they simply can't afford to pay for a certificate. Does this mean everything I do is vulnerable to MitM?

Community
  • 1
Ulkoma
  • 8,793
  • 16
  • 65
  • 95
  • 8
    There is a difference between a certificate and a root certificate. – techraf Mar 28 '16 at 12:06
  • 1
    @techraf how do I know the certificate type? is the delivery method different? – Ulkoma Mar 28 '16 at 12:11
  • Yes, the delivery method is different. With regular certificates it is the website that sends it to a browser. For CA it must be installed administratively. If a company controls your PC, then for MSIE they can distribute it automatically. For other browsers users are asked to manually install the certificate. – techraf Mar 28 '16 at 12:22
  • 4
    It's not a cost problem. Certs are cheap to free (StartSSL and the new LetsEncrypt). – Neil Smithline Mar 28 '16 at 14:14
  • 13
    The certificate doesn't tell you the website is trustworthy; it tells you that you're probably connected to the website you think you are (they might have had their private key stolen). It doesn't provide any safeguards over what they do with data you give them, such as an email address, username, or password you use in more than once place. – Phil Lello Mar 28 '16 at 15:09
  • I would "politely" remind your college that they are accessing every student's online banking details. WHEN (not if) there be a breach on their proxy server they WILL BE LIABLE TO THE ENTIRE SUM OF LOSSES ACROSS EACH AND EVERY STUDENT. I would also quietly post on the dark net the name of the college and initiate a free-for-all on their proxy...Your college is playing with forces it is not able to comprehend. – Aron Mar 29 '16 at 03:47
  • 8
    @Aron First of all, the "college" question is from somebody else last year, not this poster. Second of all, going online and inviting a bunch of people to attack your university's systems is an absolutely terrible idea that must be condemned in the strongest terms. – Chris Hayes Mar 29 '16 at 06:18
  • 1
    @Aron Agreed with Chris on both points. Also, there's no need to try to hack the proxy in that question because its private key was already compromised (that vendor used the same CA certificate on all of their proxy servers because they're just that incompetent.) – reirab Mar 29 '16 at 15:01

5 Answers5

16

Trusting one site's untrusted (self-signed or blatantly invalid) certificate could potentially compromise the connection to that particular domain, however you're still safe for other sites, except in the rare case when the other sites embed content from that site with the untrusted cert. For self-signed certs the only danger is the initial trust you put in the certificate, since you have no way to verify if you're talking to a legitimate server vs. an MITM. Once you trust the certificate the first time your browser still checks whether the cert is the same on subsequent connections (if an MITM were to appear next time you won't get owned unless you also trust their own certificate). As far as cryptography is concerned the type of certificate has no incidence on which cipher suites will be in use, and HTTPS with a self-signed cert is no easier to break than HTTPS with a trusted cert.

The nightmare begins when you start trusting someone's CA certificate (by manually downloading the cert and importing it), in that case you're telling the computer "let that entity vouch for any website you encounter", and from there you're giving that CA the power to tell your computer whether any site you visit is trusted, since any site that has a cert signed by that CA (let it be for legitimate reasons or because of the CA owner MITM'ing you) is now automatically trusted by your browser.

André Borie
  • 12,706
  • 3
  • 39
  • 76
  • 6
    Stating that "CA certificate" means "certificate authority certificate" might help someone who doesn't understand how certificates work, instead of using the acronym. – Yakk Mar 28 '16 at 19:32
  • 1
    (Particularly since this question is on the HNQ sidebar and therefore more exposed to outside traffic.) – E.P. Mar 28 '16 at 19:46
  • @E.P. what is HNQ? – Ulkoma Mar 28 '16 at 19:55
  • @E.P. nvm, found the answer [here](http://meta.stackexchange.com/questions/258499/sidebar-of-hnq-shows-only-the-users-who-asked-the-questions-but-not-those-who-a) – Ulkoma Mar 28 '16 at 20:04
  • Might also be a good idea to link to the wikis for [Root Certificate](https://en.wikipedia.org/wiki/Root_certificate) and [Certificate Authority](https://en.wikipedia.org/wiki/Certificate_authority) for further reading. – reirab Mar 29 '16 at 02:00
  • Couldn't you potentially trust a very broad wildcard certificate? e.g. `*.com`? – Bob Mar 29 '16 at 02:34
  • 1
    @Bob according to https://security.stackexchange.com/questions/6873/can-a-wildcard-ssl-certificate-be-issued-for-a-second-level-domain, most browsers reject those kinds of certs. – André Borie Mar 29 '16 at 02:36
  • -1 Although all of this content is correct. The take away isn't correct as the answer is not in aware of the context of the question. In this particular case the college wants to install a CA cert for the explicit reason to MITM attack ALL TLS connections. – Aron Mar 29 '16 at 03:44
  • 1
    @AndréBorie Ah, nice, thanks. So the other remaining risk is a cert with SANs including some common domains that don't use HPKP. – Bob Mar 29 '16 at 06:26
  • @Bob AFAIK, when you add an exception in most browsers, you are trusting the certificate *for a particular site*. Use on a different site would trigger a separate error, and require a separate exception, regardless of the content of the certificate. This follows from the fact that you can add an exception to trust an otherwise-valid certificate with the wrong Subject; it would be nonsensical for a browser to convert that cert into a global wildcard as soon as you add the exception. – IMSoP Mar 31 '16 at 14:34
12

Unfortunately, the word certificate refers to different things in similar contexts. Even within TLS/SSL, it can mean (at least) either:

  • A server / domain certificate
  • A CA (Certificate Authority) certificate
  • A client certificate

Most likely you've never used a client certificate. These are installed in your browser, and authenticate the browser to a certain server. Virtually all websites use passwords to fulfill this function, instead.

A server certificate authenticates a certain server to your browser - it makes your browser sure it's talking to the correct server, and not a impersonator server. Each server or domain usually uses a different certificate, so a server certificate is only valid there. Since there are many millions of servers and domains on the internet, your browser cannot possibly be shipped with certificates to all of them. Anyone can generate any (so called self-signed) certificate for any domain another way is needed to establish trust. This is where CAs come in.

CAs act as a trusted third party: they have broad authority to assert the identity (server certificates) of all the internet domains. This authority is granted by the browser developers, which ship their certificates built-in the browsers

Now that we know a bit more about TLS certificates, we can answer your questions:

the questions below suggest that trusting ONE certificate would put everything you do online at risk.

This is true if it is a CA certificate - not a server certificate. The procedure to install them varies. Since a CA is able to identify ANY domain on the internet, if you install a "bad" CA, all your browser-based communication can be immediately compromised.

I have trusted self-signed certificates more than once from many websites because they simply can't afford to pay for a certificate. Does this mean everything I do is vulnerable to MitM?

No. These are server certificates, are are only valid for the domain(s) they are issued to. You can see this information if you inspect the certificate details. Your browser may actually accept the certificate as valid for the domain you're visiting on even if it's different from the domains listed in the certificate, but it doesn't affect any other domains.

loopbackbee
  • 5,308
  • 2
  • 21
  • 22
  • If a web site can trick you into installing their cert into trusted root (as opposed to just trusting this particular cert) you might be compromised on more than just their website. Is this correct? – Andrew Savinykh Mar 29 '16 at 12:01
  • Although *most* server certificates certify only one site, there is no restriction on what they *can* list. The distinction is not that you are trusting a single-server *certificate*, but that you are adding a single-server *exception* in the browser - the same self-signed certificate used on a different domain would require a separate exception to be added. Otherwise, a site could persuade you to trust their self-signed cert, then use it to MITM every site you visit. – IMSoP Mar 29 '16 at 13:10
  • In fact, when manually trusting a cert, *none* of the details need be valid - it can be expired, self-signed, and have a CNAME for example.com, but still be used for encryption. Suggested wording for last para: "No. These are *server* certificates, and you have only trusted them *for a specific domain*. If another website uses the same certificate, your browser will reject it unless you add another exception." – IMSoP Mar 29 '16 at 13:18
  • @AndrewSavinykh Correct. What's interesting is that browsers make a huge fuss when you visit a site with a invalid server certificate, but for firefox the dialog to add a CA is quite inconspicuous. Try [this link](http://www.cacert.org/certs/root.crt) (but don't actually add it if you don't trust them) – loopbackbee Mar 30 '16 at 00:05
  • @IMSoP A certificate is only valid for a single domain (excepting [wildcards](https://en.wikipedia.org/wiki/Wildcard_certificate), which are valid only on subdomains, and [SubjectAltName](https://en.wikipedia.org/wiki/SubjectAltName), which is poorly supported). I'm actually not sure what would happen if you chose to accept a certificate in a domain and then navigated to another domain which was included in SubjectAltName - do you have any reference? – loopbackbee Mar 30 '16 at 00:14
  • @goncalopp In my experience, multi-domain certificates are commonplace and perfectly normal, so I'm not really sure why you're so confident asserting that a certificate is valid for only one domain. Regardless, you can add an exception to the browser for a certificate with the *wrong* subject name, so it really is irrelevant what the certificate has in it, only what you've opted to trust it for. – IMSoP Mar 30 '16 at 08:57
  • @IMSoP Can you point me to a website that uses a multi-domain certificate? Maybe I'm misinterpreting your statement. You're absolutely right in that you can accept a certificate with virtually any CommonName. – loopbackbee Mar 30 '16 at 14:35
  • @goncalopp How about ebay? https://www.ssllabs.com/ssltest/analyze.html?d=www.ebay.com&latest It may be that once upon a time SubjectAltName was poorly supported, but it's now a standard option from most CAs. – IMSoP Mar 30 '16 at 15:05
  • @IMSoP Is ebay *actually* providing that certificate when visiting any of the SubjectAltName domains? The few ones I tested had different certificates with different CommonNames https://www.ssllabs.com/ssltest/analyze.html?d=srv.in.ebayrtm.com&s=66.135.211.38&latest – loopbackbee Mar 30 '16 at 15:18
  • @goncalopp Yes, they really are. Browse to a secure image and check the cert info in your browser, e.g. https://ir.ebaystatic.com/rs/v/fxxj3ttftm5ltcqnto1o4baovyl.png Or just google "multi-domain certificate" and see how many people are selling them as standard products. Hell, Symantec use one for their own site - check https://m.symantec.com or [test it](https://www.ssllabs.com/ssltest/analyze.html?d=m.symantec.com&latest). – IMSoP Mar 30 '16 at 16:09
  • @goncalopp If you look carefully, even your example shows an Alt Name in use - you analysed srv.in.ebayrtm.com, but the Subject is srv.ebayrtm.com – IMSoP Mar 30 '16 at 16:10
  • @IMSoP Nice, thanks for the link! I hadn't seen this in practice before. I've reworded the last part of the answer – loopbackbee Mar 30 '16 at 18:45
  • (@IMSop) www.paypal.com www.google.com www.yahoo.com www.microsoft.com www.apple.com all use SAN certs -- although apple has only one name in SAN; the others have many. Also www.oracle.com, though it 301s to plain-http so was harder to check. https://www.digicert.com/subject-alternative-name-compatibility.htm (which itself uses SAN) asserts support in almost everything but some older mobile devices. – dave_thompson_085 Mar 31 '16 at 05:21
10

What these questions refer to is installation of a root certificate (Certificate Authority). Unlike regular certificates which are sent by visited website, the root certificate must be installed administratively into client machine's certificate store/vault.

Regular certificates are used to confirm the authenticity of a website presenting it. With self-signed that responsibility is on the user's side.

Root certificates are used to determine validity of certificates presented by websites through a certification path. This is why you don't need to validate each certificate of any site you visit individually.

What corporations do, is to either install automatically (e.g. MSIE) or ask users for manual installation (e.g. Firefox) of a root certificate for their proxy. Then:

  • User opens a browser and navigates to an https://example.com site.
  • The connection is redirected to a proxy (let's use BlueCoat for example) that captures the request.
  • To establish encrypted communication with the browser, the proxy must present its own public key, so sends it to the browser. The key is signed with a certificate for https://example.com domain signed with the BlueCoat-root certificate.
  • Normally a browser would complain that the certificate path does not lead to a trusted root CA. However if user installed root certificate of a proxy, then the browser trusts certificates signed by it and allows the connection without alerting the user.
  • Proxy initiates the communication with the destination server and relays all communication encrypting/decrypting it between itself and the destination website, as well as encrypting/decrypting it between itself and the browser.

That allows proxy to capture whole communication.

By installing a root certificate on their machines, users won't see warnings that certificates sent by the proxy are invalid (ie. the communication between the browser and the destination site is not encrypted end-to-end). Users can check and see that for every https:// connection the certificate was signed by BlueCoat proxy.

The method above does not allow Extended Validation, so sites that use these types of certificates will appear in browser as regular https-encrypted ones.

techraf
  • 9,141
  • 11
  • 44
  • 62
  • 1
    It's also probably worth noting that, in addition to itself being an MitM attack (which could compromise your data if the proxy is compromised,) this method also prevents you from noticing if someone else downstream is MitMing the connection or just outright spoofing the server. It's basically a voluntary hack that completely removes any notion of server authentication from TLS. Otherwise, though, this is a good answer. +1. – reirab Mar 29 '16 at 01:58
  • That's a valid point from a user's perspective (and the question actually asks for it). User cedes the responsibly for verification to the proxy. For organizations on the other hand, proxy vendors probably claim they do better job (and are more trustworthy) than individual users. – techraf Mar 29 '16 at 02:16
1

The certificate doesn't tell you the website is trustworthy; it tells you that you're probably connected to the website you think you are (they might have had their private key stolen).

Self-signed certs don't have any vetting by a 3rd party, but even a CA cert doesn't provide any safeguards over what the website do with data you give them, such as an email address, username, or password you use in more than once place.

The CA model is quite flawed, since any CA could (but shouldn't) issue certificates to anyone for any website. Installing a new root or intermediate CA increases risk. DANE and Certificate Pinning attempt to mitigate this.

Phil Lello
  • 1,122
  • 10
  • 15
  • I am aware of the first part of your answer, [Can an HTTPS site be malicious or unsafe?](http://security.stackexchange.com/questions/66355/can-an-https-site-be-malicious-or-unsafe). What I wasn't aware of is the existence of more one than type of the certificate, does the browser give a different response for each type? ie different warning. – Ulkoma Mar 28 '16 at 15:52
-2

You must take a deep look at the certificate you're offered to trust. Every certificate has it's own "permitted usage" flags - and you should examine them carefully. Take a further reading here and there - it will give you the whole idea about certificate types.

UPDATE: You must suspect the abilities of this certificate: can it be just a webserver's self-signed one, or it can be a full-featured CA and can sign other certificates. The attack vector when you're giving someone your certificate to be trusted is not just make them trust it, but allow you to alter their trusts further through that certificate once it's trusted. That's my point.

For example, you can be given a self-signed HTTPS certificate on a website, so far so good, but with CA capabilities too: so you're trusting it and securing your connection, but when you'll try to go to,let's say for example,gmail.com to check your mail, a MitM attack may be attempted with a certificate identical by text values to the original GMail one, but signed with that same certificate of a website and because you've just trusted it. Your browser will show no warning, because it's validated successfully.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
  • Other than the links you posted can you highlight one useful sentence in your answer? – Ulkoma Mar 28 '16 at 21:11
  • @Ulkoma you must suspect not the fact, that you're trusting is not trusted by you yet, *but the abilities* of this certificate : can it be just a webserver's self-signed one, or it can be a full-featured CA and can sign other cerificates. The attack vector when you're giving someone your certificate to be trusted is **not just make them trust it, but allow you to alter their trusts further through that certificate once it's trusted** That's my point – Alexey Vesnin Mar 28 '16 at 21:15
  • @Ulkoma I've added it to the answer body with an example to be more clear – Alexey Vesnin Mar 28 '16 at 21:38