6 ms·

Although I do not deny the necessity for certificate authorities for convenience, I do not understand why using CAs is the only option. Why does the TLS protoco

Although I do not deny the necessity for certificate authorities for convenience, I do not understand why using CAs is the only option. Why does the TLS protocol not allow for using a key pair which is agreed-upon between a server and a client beforehand, like in SSH connections where a public key to be used in a connection is placed in a server prior to the connection? There are many CAs out there and in the event of China or Russia hacking into one of them, it would enable them to perform man-in-the-middle attacks. I'd like to eliminate such a possibility, but the TLS protocol requires me to trust a certificate authority. I might just be a conspiracy theorist, but I am suspecting why it's impossible to use TLS without trusting a third-party called certifcate authority is exactly because someone needed to leave a way to do MITM attacks.

tashian 6y ago
TLS does have a mode that uses a pre-shared key, but in TLSv1.3 I believe it's only used for session resumption. Edit: Also, I recently learned about DNS Certification Authority Authorization (CAA) records. You can specify which of the public certificate authorities a browser is allowed to respect, for your domain. I don't think it's verified by all browsers yet, but it's a step.
- mmalone 6y ago
  Pretty sure CAA is supposed to be enforced by CAs, not by browsers. So, for instance, Let's Encrypt should refuse to issue a cert for your domain if you have CAA setup for digicert.
  - JonathonW 6y ago
    CAA records (which specify which CAs are allowed to issue certificates for a given domain) are intended to be enforced by CAs, not by browsers. This prevents unintentional misissuance of a certificate, but not deliberate MITM attempts if the CA is actively involved. Their counterpart for browsers are TLSA records, which associate specific keys or certificates with a domain name. This is the part that actually prevents MITM attacks on the client side (assuming the client's getting a complete and accurate DNS response, which is a whole other issue), since it'll cause a compliant client to reject any other keys or certificates. (No idea how widespread the implementation of this is on the client side, though.)
    - mmalone 6y ago
      Neat. I had never heard of TLSA. I’ll also add that certificate transparency (CT) is another mechanism designed to mitigate malicious cert issuance by a CA. A CT log is an public, append-only data structure. It doesn’t actively prevent anything, but it does ensure that a malicious issuance is easily detectable. In practice it seems to be a pretty effective deterrent against nation-state attacks: they won’t go undetected for long.
- tialaramex 6y ago
  Other people responded to your CAA mistake (CAA absolutely shouldn't be enforced by anybody else except a CA, even researchers monitoring it for other sites is dubious, though as a research project it isn't inherently dangerous like enforcement would be) But let's talk about PSKs (pre-shared keys). TLS 1.3 itself doesn't care why this PSK is used. It's true that today your Web Browser will only use it for resumption, because it offers a significant speed-up in some scenarios on second and subsequent visits. But for IoT applications it is envisioned that a group of devices might share one or more PSKs out of band. Maybe they're a factory setup thing, maybe the devices are to be set up in close physical proximity using low bandwidth Bluetooth, then they'll build themselves a WiFi network when deployed using PSKs to secure TLS. Browsers could do that, but all the vendors are clear there's no way they'd actually want to do that. What would the UX look like? "Please enter the hexadecimal PSK for the site in this box?". So today they only use PSKs for resumption. The reason this one feature (PSKs) has two very different purposes is to narrow the security proof work. Mathematicians worked really hard to prove some important things about TLS 1.3 and the more extra different features it has, the less focus can be put on any particular feature. Even as it is they missed the fact that PSKs are symmetric. If Alice and Bob have a single PSK to "authenticate" them and are both capable of serving, then Mallory can trick Alice into thinking she's talking to Bob when she's actually talking to herself. It's a small problem, but the proofs didn't cover it, and so it was not spelled out in the TLS 1.3 document that you should worry about this.
mmalone 6y ago
See my response to superkuh elsewhere in this thread. This would introduce new problems and, overall, would probably make Web PKI worse.
bmm6o 6y ago
I don't think TLS cares why the certificate is trusted, validating certificates is higher on the stack, and you've probably seen the browser UX for accepting an invalid certificate. I know I've added a non-CA cert to my trusted list (on Windows) and gotten the result you are describing.
1vuio0pswjnm7 6y ago
https://en.wikipedia.org/wiki/Trust_on_first_use#First_known_use_of_the_term https://en.wikipedia.org/wiki/Trust_on_first_use#First_known...
- mmalone 6y ago
  Firefox is the only browser that ships with a built-in trust store. Other browsers use your operating system’s trust store and you can add & remove trusted CA certs from that trust store using OS-specific utilities. The big three root store programs are run by Apple, Microsoft, and Mozilla/NSS. Most (all?) Linux distros are based on the Mozilla store. Until recently, Google also used Mozilla’s store for things like ChromeOS and Android. They just recently announced that they’re gonna start running their own program though. FWIW the browsers seem to do a pretty good job of policing CAs. Probably better than most end-users would do.
  - 1vuio0pswjnm7 6y ago
    Can users remove CA certs from ChromeOS and Android?
    - mmalone 6y ago
      Good question. I know you can add a root CA cert. I’m on iOS and don’t have an Android or ChromeOS device handy. I don’t see a way to remove a cert from Apple’s iOS trust store (settings just tells me what store version I’m running). There may be a way to do it using mobile device management (MDM) tools.
      - SAI_Peregrinus 6y ago
        On Android (Galaxy Note9 in my case), you can disable any CA certificate from being used. There's a "view security certificates" screen with the ability to disable each individually.
  - corty 6y ago
    Browsers do a crappy job in general for any CA usecase that isn't https on public websites. Guidelines for the WebPKI are, of course, very web-centric. E.g. short lifetimes may be acceptable there. Automated frequent reissuance may be an option. But if you e.g. look at email and auth certs, possibly stored on a smartcard, things are quite different. Lifetime should be long and can be long, because the key is used rarely (compared to webservers) and maybe stored in dedicated smartcards. Verification is another thing thats totally different for an email address or a person's name.
kjaftaedi 6y ago
You don't have to use a third party, you just have to specify an authority. If you say the self-signed certificate is the authority, that's no problem. In my private lab environment I have one certificate (for everything). The certificate is installed on all servers, and even the clients use the same certificate to authenticate, and everyone trusts the cert as an authority. You'd never run a production setup like this, but there is nothing stopping you.
tinus_hn 6y ago
It does, you just have to wrap a certificate around it.
tssva 6y ago
TLS-SRP allows using an agreed to password alone or in conjunction with a certificate. Gnutls, openssl, curl and a few other libraries contain implementations. It just has not found widespread use and none of the major browsers support it.
nsgi 6y ago
Because the SSH trust model relies on verifying the fingerprint out of band, which isn't practical with a website, and even if it was non-technical users and even most technical users wouldn't do it. Certificate Transparency is a good mitigation for the risk of a CA being compromised

tashian 6y ago

TLS does have a mode that uses a pre-shared key, but in TLSv1.3 I believe it's only used for session resumption. Edit: Also, I recently learned about DNS Certification Authority Authorization (CAA) records. You can specify which of the public certificate authorities a browser is allowed to respect, for your domain. I don't think it's verified by all browsers yet, but it's a step.

mmalone 6y ago
Pretty sure CAA is supposed to be enforced by CAs, not by browsers. So, for instance, Let's Encrypt should refuse to issue a cert for your domain if you have CAA setup for digicert.
- JonathonW 6y ago
  CAA records (which specify which CAs are allowed to issue certificates for a given domain) are intended to be enforced by CAs, not by browsers. This prevents unintentional misissuance of a certificate, but not deliberate MITM attempts if the CA is actively involved. Their counterpart for browsers are TLSA records, which associate specific keys or certificates with a domain name. This is the part that actually prevents MITM attacks on the client side (assuming the client's getting a complete and accurate DNS response, which is a whole other issue), since it'll cause a compliant client to reject any other keys or certificates. (No idea how widespread the implementation of this is on the client side, though.)
  - mmalone 6y ago
    Neat. I had never heard of TLSA. I’ll also add that certificate transparency (CT) is another mechanism designed to mitigate malicious cert issuance by a CA. A CT log is an public, append-only data structure. It doesn’t actively prevent anything, but it does ensure that a malicious issuance is easily detectable. In practice it seems to be a pretty effective deterrent against nation-state attacks: they won’t go undetected for long.
tialaramex 6y ago
Other people responded to your CAA mistake (CAA absolutely shouldn't be enforced by anybody else except a CA, even researchers monitoring it for other sites is dubious, though as a research project it isn't inherently dangerous like enforcement would be) But let's talk about PSKs (pre-shared keys). TLS 1.3 itself doesn't care why this PSK is used. It's true that today your Web Browser will only use it for resumption, because it offers a significant speed-up in some scenarios on second and subsequent visits. But for IoT applications it is envisioned that a group of devices might share one or more PSKs out of band. Maybe they're a factory setup thing, maybe the devices are to be set up in close physical proximity using low bandwidth Bluetooth, then they'll build themselves a WiFi network when deployed using PSKs to secure TLS. Browsers could do that, but all the vendors are clear there's no way they'd actually want to do that. What would the UX look like? "Please enter the hexadecimal PSK for the site in this box?". So today they only use PSKs for resumption. The reason this one feature (PSKs) has two very different purposes is to narrow the security proof work. Mathematicians worked really hard to prove some important things about TLS 1.3 and the more extra different features it has, the less focus can be put on any particular feature. Even as it is they missed the fact that PSKs are symmetric. If Alice and Bob have a single PSK to "authenticate" them and are both capable of serving, then Mallory can trick Alice into thinking she's talking to Bob when she's actually talking to herself. It's a small problem, but the proofs didn't cover it, and so it was not spelled out in the TLS 1.3 document that you should worry about this.

mmalone 6y ago

See my response to superkuh elsewhere in this thread. This would introduce new problems and, overall, would probably make Web PKI worse.

bmm6o 6y ago

I don't think TLS cares why the certificate is trusted, validating certificates is higher on the stack, and you've probably seen the browser UX for accepting an invalid certificate. I know I've added a non-CA cert to my trusted list (on Windows) and gotten the result you are describing.

1vuio0pswjnm7 6y ago

https://en.wikipedia.org/wiki/Trust_on_first_use#First_known_use_of_the_term https://en.wikipedia.org/wiki/Trust_on_first_use#First_known...

mmalone 6y ago
Firefox is the only browser that ships with a built-in trust store. Other browsers use your operating system’s trust store and you can add & remove trusted CA certs from that trust store using OS-specific utilities. The big three root store programs are run by Apple, Microsoft, and Mozilla/NSS. Most (all?) Linux distros are based on the Mozilla store. Until recently, Google also used Mozilla’s store for things like ChromeOS and Android. They just recently announced that they’re gonna start running their own program though. FWIW the browsers seem to do a pretty good job of policing CAs. Probably better than most end-users would do.
- 1vuio0pswjnm7 6y ago
  Can users remove CA certs from ChromeOS and Android?
  - mmalone 6y ago
    Good question. I know you can add a root CA cert. I’m on iOS and don’t have an Android or ChromeOS device handy. I don’t see a way to remove a cert from Apple’s iOS trust store (settings just tells me what store version I’m running). There may be a way to do it using mobile device management (MDM) tools.
    - SAI_Peregrinus 6y ago
      On Android (Galaxy Note9 in my case), you can disable any CA certificate from being used. There's a "view security certificates" screen with the ability to disable each individually.
- corty 6y ago
  Browsers do a crappy job in general for any CA usecase that isn't https on public websites. Guidelines for the WebPKI are, of course, very web-centric. E.g. short lifetimes may be acceptable there. Automated frequent reissuance may be an option. But if you e.g. look at email and auth certs, possibly stored on a smartcard, things are quite different. Lifetime should be long and can be long, because the key is used rarely (compared to webservers) and maybe stored in dedicated smartcards. Verification is another thing thats totally different for an email address or a person's name.

kjaftaedi 6y ago

You don't have to use a third party, you just have to specify an authority. If you say the self-signed certificate is the authority, that's no problem. In my private lab environment I have one certificate (for everything). The certificate is installed on all servers, and even the clients use the same certificate to authenticate, and everyone trusts the cert as an authority. You'd never run a production setup like this, but there is nothing stopping you.

tinus_hn 6y ago

It does, you just have to wrap a certificate around it.

tssva 6y ago

TLS-SRP allows using an agreed to password alone or in conjunction with a certificate. Gnutls, openssl, curl and a few other libraries contain implementations. It just has not found widespread use and none of the major browsers support it.

nsgi 6y ago

Because the SSH trust model relies on verifying the fingerprint out of band, which isn't practical with a website, and even if it was non-technical users and even most technical users wouldn't do it. Certificate Transparency is a good mitigation for the risk of a CA being compromised