0

SSL uses CAs which sign certificates for the domains after they validate that the person requesting is truly the owner and by a public/private key pair a encrypted connection is achieved which cant be decrypted by a MITM.

Now thinking on the long run, if someone has control over your network all the time, after some time the CA will have signed a couple of thousands more certificates which will need to be synced and downloaded to the browser using them. What is actually stopping a MiTM from intercepting that?

user36976
  • 3,233
  • 4
  • 15
  • 22
  • Why do you think that such synchronisation will be **online process** ? – Marek Sebera Mar 24 '14 at 14:49
  • @MarekSebera Because how else would it be done? – user36976 Mar 24 '14 at 14:50
  • Offline of course, ever heard about 'Cold Storage' systems? Private keys for such certificates are usually well protected, and even on online process, you won't transfer the data unencrypted, I personally would transfer them with at least as ciphered bulk file. – Marek Sebera Mar 24 '14 at 14:54
  • 1
    Your understanding of SSL appears to be highly flawed. The CAs don't sync all signed certificates to individual browsers. Any time you go to a site, that webserver sends its *own* certificate. This certificate has been signed by the CA, and that signature can be verified with anyone that has the CA's public key. – Stephen Touset Mar 24 '14 at 18:31

2 Answers2

1

After some time the CA will have signed a couple of thousands more certificates which will need to be synced and downloaded to the browser/app using them. What is actually stopping a MiTM from intercepting that?

The fact that the website's certificate is signed is what prevents a MITM.

I will prove my point with a simple example. I don't know if that's exactly how modern SSL/TLS works. But the basic idea remains the same.

Step 1, Bob's browser

Bob has a CA's public key. The CA public key is well known and never changing, therefore it's built into Bob's browser/OS.

Step 2, Alice sets up SSL/TLS

Alice wants to make her website protected. Alice creates a private/public key pair and sends the public key to the CA. The CA bundles Alice's public key, domain name, and some other information together in a single package. Then the CA encrypts that package with the CA's own private key and sends it back to Alice.

Now Alice has a signed certificate which contains her public key, domain name, and some other info. The certificate is encrypted(signed) with the CA's private key. It can be decrypted with the well known CA public key.

This step only needs to be done once.

Step 3, Bob connects to Alice

Bob conntects to Alice's website. Alice sends Bob her signed certificate. Bob gets the signed certificate and decrypts it using the CA's public key which he already knows. Now, bob checks if the domain name inside the certificate matches the one he is connecting to. Once done, Bob is confident he has Alice's public key and no MITM can occur.

(Assuming the CA isn't evil)

Step 4, Scar tries to intercept

Bob connects to Alice's website again. Alice sends Bob her signed certificate. This time Scar who is in control of Bob's network is listening to the communication stream. Although he can intercept and decrypt Alice's certificate using the well known CA public key, He cannot modify the certificate and re-encrypt it because Scar doesn't have the CA's private key. The best he can do is corrupt the certificate, but that would alert Bob and the connection would drop.

Hello World
  • 242
  • 4
  • 15
0

During certificate generation, the private key is never sent over the network. A private/public key combination is generated by the organization that has the server that needs a certificate. The public key/CSR is submitted to the CA (and encrypted such that it can't be altered in route) and the CA then signs the public key in to a certificate and returns that certificate to the organization. The organization then uses that certificate as proof that they are who they say they are.

Even with complete control of the network, the private key for the server and the private key for the CA are never disclosed, so it is impossible for the third party to produce a false cert or for the third party to get the CA to produce a false cert.

Based on your comment, it would seem you have a complete misunderstanding of how SSL works. Your question makes no sense in the context of the client connecting to the server. The CA doesn't send anything to the browser, ever. The browser comes with root public certificates for the CA pre-installed and trusted. That CA then uses the private key they control which corresponds to that certificate to sign an infinite number of other certificates.

When the server you are connecting to provides a certificate they say "here's my public key that you can use to talk with me and only I can understand it. See, it's been signed by a CA that you trust, so I really am me." There is no way for an attacker to fake this since they don't have access to the private key for the CA and can't sign a certificate to make it trusted.

AJ Henderson
  • 41,896
  • 5
  • 63
  • 110
  • Im asking about browser side/public key side not server side – user36976 Mar 24 '14 at 18:02
  • @nick - see my update (last two paragraphs), but you should really read up on [one of the more general questions](http://security.stackexchange.com/questions/20803/how-does-ssl-work) about how SSL works because your current understanding appears to be incorrect based on the question you are asking. – AJ Henderson Mar 24 '14 at 18:24