How can trusting ONE certificate jeopardize everything I do online?
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.
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.
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.comsite. - 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.comdomain 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.