3

This question already has an answer here:

What does having a certificate issued by a Content Authority protect against? In everything I've red (and watched) they teach it as "you are given the public key to communicate with Alice, but how do you know it is actually from Alice?" in comes the PKI...

what I don't understand is the problem "how do you know the public key came from Alice"?

You contacted the resource, whether it with a host name or IP address. Let me know if my question doesn't make sense and I'll try to reword it. What I'm asking is basic: what's the need of a certificate: you always know the IP address of the person your sending to. Does this have something to do with if someone sends you the public key then the person may be an attacker and give you a bogus public key? But you would still be sending packets to the actual intended recipient so they would likely return an error message saying there's something wrong with the way your messages are encrypted.

marked as duplicate by RoraΖ, user45139, Deer Hunter, StackzOfZtuff, Xander Oct 19 '15 at 14:23

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4

you always know the IP address of the person your sending to

Oh, do you? Personally I have no clue under which IP addresses I can find my favourite web services. Usually I type in a domain and my computer contacts some third party to ask about the corresponding IP. This is known as Domain Name Service (DNS). You'll see in a second why I mention this.

A classic example of a potential man-in-the-middle (MITM) attacker is the person controlling the router you are connected to. Without PKI in place, they can easily pretend to be someone else.

Let's say you go to a public cafe and want to access your Gmail inbox. You type 'gmail.com' into your browser's address bar, and you are presented with a page that asks for your Gmail account name and password. How do you know that page is in fact the one hosted by Google, and not, say, served from a local machine in the back room of the cafe? One issue here is that your computer will have sent a request to a remote DNS to ask for the IP required, but this request goes through the router, so without additional security measures in place, the MITM can return an arbitrary IP. Second, the router might have left your DNS request and answer unchanged but then served up the fake page regardless of what IP you were actually trying to reach. After all, you relied on them to relay your request and Gmail's answer.

And this is where transport-layer encryption and the public-key infrastructure come into play. When you try to contact a server that runs HTTPS, it will present you with a public key to encrypt further communications, and that key will usually be signed by a trusted CA. Thus, without access to the server's private key, an intermediary can not read or manipulate the exchanged data (hence the name end-to-end encryption for this kind of mechanism). What the CA does is ensure that the public key originally presented cannot be spoofed without you noticing it.

Similarly, DNSSEC (DNS Security Extensions) relies on PKI to detect a MITM who is manipulating DNS requests/responses.

0

The trust relationship for almost all Certificate Authorities is provided via your trust in the operating system and browser vendors. The CAs' public keys are pre-loaded in your OS and browsers and/or provided via updates. Therefore, there is a out of band method of confirming the identity for your trust basis.

A key concept in PKI is that of the trust relationships. Most of that process is based on an out of band foundation otherwise, as you suggest, the process could be subverted.

  • 1
    Ok thanks, I think that answers my other questions "why can't a MITM attack just spoof the CA" and I see it's because the CAs public keys are preloaded into the OS so it can securely connect with the CAs? – Celeritas Oct 19 '15 at 21:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.