-2

As I understand it, CAs have the job to make sure that the encryption via a passphrase used when visiting a website (https://) stems from the website itself and nobody else. Or that if I exchange public keys with other entities, they stem from them and only them. So, for example, a CA makes sure that when I visit https://stackexchange.com all network traffic is encrypted with the key, that was generated from stackexchange itself and nobody else.

  1. The "only" reason, I can imagine, why CAs exist is that somebody uses a man-in-the-middle attack and sends keys that he, the attacker, created before. Why else would you use CAs? Because when I visit https://stackexchange.com, it is a clear website with a clear IP and everything. They could just send me their key for encryption and everything's fine, isn't it? The only reason I see is a man-in-the-middle attack.

  2. How come, there are, as far as I know, no concepts like CAs in Tor Browsing? You have an onion address (http://hahgstsbsjservbu.onion) and get the key when visiting the hidden service. As far as I know, the key lies somewhere on the server that provides the hidden service. Why are there no CAs?

schroeder
  • 123,438
  • 55
  • 284
  • 319
BeldCode
  • 11
  • 1
  • 1
    TLS doesn’t encrypt all network traffic with the public key, which would be very computationally expensive and would mean that the client couldn’t decrypt it, since the client doesn’t have the corresponding private key. It only encrypts a symmetric encryption key that is then used to encrypt the actual network traffic. – Mike Scott Aug 08 '18 at 19:51
  • 3
    You might need to read this first: https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work All of your underlying assumptions about CAs are incorrect. – schroeder Aug 08 '18 at 19:58
  • 1
    The CA job is only to act as an entity that signs your SSL cert, and verifies the person requesting the signature for the domain is authorized to do so for that domain. That's all they do. They don't verify anything else. – Steve Sether Aug 08 '18 at 21:08
  • "_passphrase used when visiting a website_" You mean domain name? A domain isn't a "passphrase"! – curiousguy Aug 08 '18 at 22:14

1 Answers1

2

  1. A certificate authority signs messages that associate arbitrary human-chosen domain names to public keys. If you didn't have a certificate authority, you would need a different way of determining the correct public key for a domain name. If you just ask the server, then you're vulnerable to a man-in-the-middle.

  2. Tor services don't need certificate authorities because a Tor service name is actually a hash of the server's public key. A man-in-the-middle couldn't swap the certificate for their own because their own certificate won't hash to the Tor service's name.

It basically comes down to different trade-offs being chosen from Zooko's Triangle. Regular domain names are arbitrary human-chosen values, so some kind of authority must be used to associate the domain names with keys. Tor services sacrifice the "human meaningful" quality by forcing Tor service names to just be a hash of the public key, which allows them to not need any authority to associate Tor service names to keys.

Macil
  • 1,482
  • 9
  • 11
  • Thank you, @Macil! I am a little confused about the domain names and their association with public keys. I thought there were no public keys involed. I couldn't find anything on the internet. So, TLS uses symetric encryption and domain names are associated with public keys? I can't quite get it straight... – BeldCode Aug 09 '18 at 13:52
  • @BeldCode Have you read the answer Schroeder linked? – AndrolGenhald Aug 09 '18 at 15:34
  • @AndrolGenhald yes I have read it and I searched a bit on the internet. I think I get it now... the Client (e.g. a Browser) receives the public key from a server (a CA verifies, that the key stems from the correct server), which it can use to encrypt a key (computed by the client) necessary for symmetric encryption. This key can be decrypted by the Server using it's private key. That's how I understand it (now)... – BeldCode Aug 09 '18 at 18:39
  • @BeldCode "I thought there were no public keys involed.": HTTPS/TLS certificates contain a public key and some metadata like the domain it's for, the expiration date, etc. "So, TLS uses symetric encryption": TLS uses asymmetric (public key) cryptography for the initial handshake to establish a temporary private key to use for symmetric encryption the rest of the connection. – Macil Aug 09 '18 at 20:46