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?

Improve this question
8
  • 8
    There is a difference between a certificate and a root certificate.
    – techraf
    Commented Mar 28, 2016 at 12:06
  • 1
    @techraf how do I know the certificate type? is the delivery method different?
    – Ulkoma
    Commented Mar 28, 2016 at 12:11
  • 4
    It's not a cost problem. Certs are cheap to free (StartSSL and the new LetsEncrypt).
    – Neil Smithline
    Commented Mar 28, 2016 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
    Commented Mar 28, 2016 at 15:09
  • 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
    Commented Mar 29, 2016 at 6:18

5 Answers 5

Reset to default
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.

Improve this answer
13
  • 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
    Commented Mar 29, 2016 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
    Commented Mar 29, 2016 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
    Commented Mar 29, 2016 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 (but don't actually add it if you don't trust them)
    – watchowl
    Commented Mar 30, 2016 at 0:05
  • @IMSoP A certificate is only valid for a single domain (excepting wildcards, which are valid only on subdomains, and 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?
    – watchowl
    Commented Mar 30, 2016 at 0:14
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.

Improve this answer
10
  • 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
    Commented Mar 28, 2016 at 19:32
  • 1
    (Particularly since this question is on the HNQ sidebar and therefore more exposed to outside traffic.)
    – E.P.
    Commented Mar 28, 2016 at 19:46
  • @E.P. what is HNQ?
    – Ulkoma
    Commented Mar 28, 2016 at 19:55
  • 1
    @Bob according to security.stackexchange.com/questions/6873/…, most browsers reject those kinds of certs.
    – André Borie
    Commented Mar 29, 2016 at 2:36
  • 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
    Commented Mar 29, 2016 at 6:26
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.

Improve this answer
2
  • 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
    Commented Mar 29, 2016 at 1: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
    Commented Mar 29, 2016 at 2: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.

Improve this answer
1
  • I am aware of the first part of your answer, 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
    Commented Mar 28, 2016 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.

Improve this answer
3
  • Other than the links you posted can you highlight one useful sentence in your answer?
    – Ulkoma
    Commented Mar 28, 2016 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
    Commented Mar 28, 2016 at 21:15
  • @Ulkoma I've added it to the answer body with an example to be more clear
    – Alexey Vesnin
    Commented Mar 28, 2016 at 21:38

You must log in to answer this question.

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