12 ms·

Can someone explain all this like im 5? I've always wondered what all this was about.

by Exuma 9y ago

grizzles 9y ago
An attacker (eg. a criminal or foreign power) can pretend to be a website you know. Certificate pinning is a way for website to alert you to a hostile change of certificate. HPKP Cert pinning has some issues that create other problems. Chrome is removing HPKP Cert pinning and replacing it with something better called Expect-CT.
dfabulich 9y ago
On the internet, when you send and receive data, your data gets handled by a lot of different people. In the old days, anybody who handled your data could tamper with it or impersonate anybody else. Cryptography to the rescue. Suppose "Alice" and "Bob" want to send secret messages to each other, without allowing "Eve" the eavesdropper to read them, even if Eve can intercept the messages. Traditional cryptography is "symmetric," where both Alice and Bob must share a secret before they can communicate. Symmetric cryptography won't suffice over the internet, because if Alice and Bob had a secure way of sharing secrets, they wouldn't need internet cryptography in the first place. So the internet relies on public-key cryptography, where Alice and Bob each have a pair of keys (a "key pair"), one "public" key that everyone can see, even Eve, and one "private" key that has to be kept secret. Alice can encrypt a message using Bob's public key that can only be decrypted using Bob's private key. At first, it might seem like public-key crypto solves the problem completely, but it creates a new problem: how will Alice get Bob's public key? If she asks Bob for his public key over an unencrypted public channel, Eve can intercept it and offer her own public key, acting as a "man in the middle" (MITM). Luckily, public-key cryptography has one more trick up its sleeve. If you "encrypt" a message using a private key, it can be "decrypted" using the public key. Only Bob (the owner of Bob's private key) can encrypt messages that can be decrypted with Bob's public key, so anything Bob encrypts that way is effectively "signed" by Bob. If Alice and Bob trust a third party, Charlie, Charlie can sign a message saying: "This is Bob's public key: 12345" and another message saying "This is Alice's public key: 23456". Eve can't impersonate Charlie without his private key. We call Charlie a "certificate authority." (CA) When you visit an HTTPS website, the site presents a certificate signed by a CA. Your browser trusts a ton of CAs all over the world, many of them run by governments that you may not really want to trust; any of them can use their private keys to impersonate any site on the internet. This is a hard social problem as much as a technical problem. High-value websites like Gmail, Facebook, or banks may want to say "Here's our certificate, but don't just trust any certificate authority about that. You should only trust Charlie's signature." That's called "pinning" the public key to a certificate authority. It's a nice idea, but how will Gmail convey that message to its users? If Eve is a hostile government who intercepts messages and owns a trusted CA, they can impersonate Gmail, saying "Oh, you don't need to trust Charlie exclusively. You can trust any CA, even me." Chrome comes with a static, hard-coded list of pinned keys for high-value sites, but that can't scale. They had the idea of allowing anybody on the internet to pin their keys, "dynamic" pinned keys or HTTP-based key public key pinning (HPKP). The problem is, if you pin your public key and you need to change it for some reason, or if you need to switch certificate authorities for any reason, you're in big trouble. People have used HPKP and brought their site down, unable to bring it back up again, because browsers don't trust their new valid key. As a result, very few sites used HPKP, so the Chrome team is planning to remove it. Surprisingly to me, they even plan to remove the static list of pinned keys, in favor of "Certificate Transparency" where it's publicly obvious which CAs are signing which certificates. Rogue CAs would then have to reveal that they've gone rogue, at which point browsers could revoke their automatic trust in them.
- Exuma 9y ago
  That's an amazingly AWESOME answer, thank you. So... what's an example of a CA that the most highest value targets on the internet trust? (like Google, Facebook, Amazon, and various banks). Is there like a very trustworthy company that handles most of the big companies?
  - DCoder 9y ago
    You can see overall statistics for CAs at [0] or [1]. Google recently created its own CA for its properties [2]. [0]: https://trends.builtwith.com/ssl/root-authority https://trends.builtwith.com/ssl/root-authority [1]: https://en.wikipedia.org/wiki/Certificate_authority#Providers https://en.wikipedia.org/wiki/Certificate_authority#Provider... [2]: https://pki.google.com/ https://pki.google.com/
  - toast0 9y ago
    There's a list of pinned CAs at the top of the hsts preload list [1]. Which gives you an idea of who might be trusted. Cert pinning is pretty nasty if you get it wrong. If you don't pin, there's a large number of CAs in most client's default trust stores. If you do pin, and the CA you pinned turns out to be bad, it didn't help. If you pin, but the CA stops issuing from the intermediate or the root that you pinned, you can't get a new cert (hope you had other options); note that CAs don't give much guidance about what to pin. If you pinned a CA that gets delisted, that's no good either. If you pinned two different CAs (a smart choice), but they merge, you no longer have a backup. So, you should pin a public key that you haven't gotten a cert with yet, and keep it safe,but also readily available for emergencies. But you only get one emergency -- hope your next emergency comes after you have time to figure out new pins and get them bundled everywhere; and in the meantime you have one key for everything, which isn't great. (Based only on the name) Expect-CT doesn't provide nearly as much protection, any CA cert will work, but only if it was publicly recorded. If you monitor for certs issued on your domains, at least you know to raise a fuss if a CA you didn't authorize issues on your domains. That's probably enough to keep CAs in line, unless Let's Encrypt drives the net present value of a well distributed CA to below the value of illicit certificates. [1] https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json https://chromium.googlesource.com/chromium/src/net/+/master/...

Can someone explain all this like im 5? I've always wondered what all this was about.

by Exuma 9y ago

Can someone explain all this like im 5? I've always wondered what all this was about.

An attacker (eg. a criminal or foreign power) can pretend to be a website you know. Certificate pinning is a way for website to alert you to a hostile change of certificate. HPKP Cert pinning has some issues that create other problems. Chrome is removing HPKP Cert pinning and replacing it with something better called Expect-CT.

dfabulich 9y ago

On the internet, when you send and receive data, your data gets handled by a lot of different people. In the old days, anybody who handled your data could tamper with it or impersonate anybody else. Cryptography to the rescue. Suppose "Alice" and "Bob" want to send secret messages to each other, without allowing "Eve" the eavesdropper to read them, even if Eve can intercept the messages. Traditional cryptography is "symmetric," where both Alice and Bob must share a secret before they can communicate. Symmetric cryptography won't suffice over the internet, because if Alice and Bob had a secure way of sharing secrets, they wouldn't need internet cryptography in the first place. So the internet relies on public-key cryptography, where Alice and Bob each have a pair of keys (a "key pair"), one "public" key that everyone can see, even Eve, and one "private" key that has to be kept secret. Alice can encrypt a message using Bob's public key that can only be decrypted using Bob's private key. At first, it might seem like public-key crypto solves the problem completely, but it creates a new problem: how will Alice get Bob's public key? If she asks Bob for his public key over an unencrypted public channel, Eve can intercept it and offer her own public key, acting as a "man in the middle" (MITM). Luckily, public-key cryptography has one more trick up its sleeve. If you "encrypt" a message using a private key, it can be "decrypted" using the public key. Only Bob (the owner of Bob's private key) can encrypt messages that can be decrypted with Bob's public key, so anything Bob encrypts that way is effectively "signed" by Bob. If Alice and Bob trust a third party, Charlie, Charlie can sign a message saying: "This is Bob's public key: 12345" and another message saying "This is Alice's public key: 23456". Eve can't impersonate Charlie without his private key. We call Charlie a "certificate authority." (CA) When you visit an HTTPS website, the site presents a certificate signed by a CA. Your browser trusts a ton of CAs all over the world, many of them run by governments that you may not really want to trust; any of them can use their private keys to impersonate any site on the internet. This is a hard social problem as much as a technical problem. High-value websites like Gmail, Facebook, or banks may want to say "Here's our certificate, but don't just trust any certificate authority about that. You should only trust Charlie's signature." That's called "pinning" the public key to a certificate authority. It's a nice idea, but how will Gmail convey that message to its users? If Eve is a hostile government who intercepts messages and owns a trusted CA, they can impersonate Gmail, saying "Oh, you don't need to trust Charlie exclusively. You can trust any CA, even me." Chrome comes with a static, hard-coded list of pinned keys for high-value sites, but that can't scale. They had the idea of allowing anybody on the internet to pin their keys, "dynamic" pinned keys or HTTP-based key public key pinning (HPKP). The problem is, if you pin your public key and you need to change it for some reason, or if you need to switch certificate authorities for any reason, you're in big trouble. People have used HPKP and brought their site down, unable to bring it back up again, because browsers don't trust their new valid key. As a result, very few sites used HPKP, so the Chrome team is planning to remove it. Surprisingly to me, they even plan to remove the static list of pinned keys, in favor of "Certificate Transparency" where it's publicly obvious which CAs are signing which certificates. Rogue CAs would then have to reveal that they've gone rogue, at which point browsers could revoke their automatic trust in them.

Exuma 9y ago
That's an amazingly AWESOME answer, thank you. So... what's an example of a CA that the most highest value targets on the internet trust? (like Google, Facebook, Amazon, and various banks). Is there like a very trustworthy company that handles most of the big companies?
- DCoder 9y ago
  You can see overall statistics for CAs at [0] or [1]. Google recently created its own CA for its properties [2]. [0]: https://trends.builtwith.com/ssl/root-authority https://trends.builtwith.com/ssl/root-authority [1]: https://en.wikipedia.org/wiki/Certificate_authority#Providers https://en.wikipedia.org/wiki/Certificate_authority#Provider... [2]: https://pki.google.com/ https://pki.google.com/
- toast0 9y ago
  There's a list of pinned CAs at the top of the hsts preload list [1]. Which gives you an idea of who might be trusted. Cert pinning is pretty nasty if you get it wrong. If you don't pin, there's a large number of CAs in most client's default trust stores. If you do pin, and the CA you pinned turns out to be bad, it didn't help. If you pin, but the CA stops issuing from the intermediate or the root that you pinned, you can't get a new cert (hope you had other options); note that CAs don't give much guidance about what to pin. If you pinned a CA that gets delisted, that's no good either. If you pinned two different CAs (a smart choice), but they merge, you no longer have a backup. So, you should pin a public key that you haven't gotten a cert with yet, and keep it safe,but also readily available for emergencies. But you only get one emergency -- hope your next emergency comes after you have time to figure out new pins and get them bundled everywhere; and in the meantime you have one key for everything, which isn't great. (Based only on the name) Expect-CT doesn't provide nearly as much protection, any CA cert will work, but only if it was publicly recorded. If you monitor for certs issued on your domains, at least you know to raise a fuss if a CA you didn't authorize issues on your domains. That's probably enough to keep CAs in line, unless Let's Encrypt drives the net present value of a well distributed CA to below the value of illicit certificates. [1] https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json https://chromium.googlesource.com/chromium/src/net/+/master/...