0

Here's how I understand what SSL certificates actually do, in 4-year-old-child terms. There need to be three parties involved. Two parties are just my client, and the server I'm communicating with, while the third is the certificate issuer. My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

Here's the thing though. When I searched for other people asking about man-in-the-middle attacks, answers said it would only be possible if the third party (the certificate holder issuer) got its private key stolen, which the man in the middle could use to fake its identity by completing the challenge, or something like that...

However, without stealing the private key, and without stealing anything -- if the man in the middle can impose as the server of the site I'm trying to reach (simply by redirecting its domain name to its own IP), then what's stopping it from doing the same with the certificate issuer's server? So for example, it could redirect Facebook's IP address to its own server to try to get me to enter my account credentials, and when my browser tries to ask Digicert (the certificate holder for facebook.com) whether I'm communicating with the authentic Facebook server, the man in the middle could also redirect Digicert's IP address to itself again, and wrongly confirm to me that Facebook really is Facebook.

Digital Ninja
  • 129
  • 5

3 Answers3

1

My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

No, you don't have to separately contact the issuer to verify a certficiate. Otherwise you would just be shifting the trust problem. Instead there has to be a local trust anchor.

That's why your browser (and eventually your OS) already comes with pre-installed certificates for certificate authorities that were deemed to be trustworthy. From the Mozilla CA Certificate Policy:

When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla may include with such software a default set of X.509v3 certificates for various Certification Authorities (CAs). The certificates included by default have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to verify certificates for SSL servers and S/MIME email users without having to ask users for further permission or information.

When your browser establishes an SSL connection to facebook.com, the server presents the certificate along with a signature to prove that this certificate was issued by DigiCert for the domain facebook.com. The browser checks this by verifying that the certificate is transitively signed by DigiCert's root certificate that came with the browser. If the corresponding root certificate can't be found or isn't trusted, then there is no valid certificate chain and the verification fails.

As an additional security mechanism Facebook uses the HTTP Public Key Pinning (HPKP) feature which stops a man-in-the-middle attacker even if they managed to compromise a CA and generate seemingly valid certificates:

The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser.

(Source)

While any website can announce their own pins via a Public-Key-Pins header that will become active after your browser's first visit (TOFU model), Facebook and some other high-profile sites have their pins built-in in Firefox and Chrome, meaning that these browsers trust Facebook's certificates directly and don't need to check with the DigiCert root at all.

Also note that there are independent mechanisms where clients do actually contact a CA directly. For example, your browser can use OCSP to check a particular certificate's revocation status.

Also see:

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • Shame you choose Facebook as your example, since it is on most HSTS pinning lists. A slightly different sequence of events occur for Facebook. – Aron Mar 15 '17 at 04:35
  • @Aron That's true, blame OP. :-) I'm going to clarify that. (BTW, it's the HPKP list. HSTS is just for enforcing HTTPS per se.) – Arminius Mar 15 '17 at 04:44
0

There is some misinformation embedded in your question, so I would encourage you to more closely read a general article on how SSL/TLS works. The short answer is that the CA provides a secret (the certificate) which is hosted by the Facebook or other target server. Without that certificate, signed by the CA, the CA knows that the attacker isn't who they claim to be. A MITM attack that actually has the certificate (and appropriate information to use it) is indistinguishable from the target. It is therefore important for server owners/operators to protect their certificates.

PKI also provides a mechanism for certificate revocation in the event that a certificate is compromised, so that a certificate can be invalidated and reissued.

Jesse K
  • 1,068
  • 6
  • 13
  • I don't think you understood my question. Your answer is referred to in the 2nd paragraph of my question. But in the 3rd one what I'm asking is, could it be possible that my client never actually talks to the CA, but instead talks to the man in the middle, who is posing as the CA (and falsly confirms the servers "true" identity)? – Digital Ninja Mar 15 '17 at 02:38
  • No, a CA publishes a public key which can be used to verify its identity, for example by encrypting something with its private key... though this isn't something that actually happens, because modern browsers ship with trusted CAs. – Jesse K Mar 15 '17 at 15:08
0

My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

That's not how TLS/SSL works. In TLS/SSL, the client doesn't need to ask the certificate issuer whether or not the server is who they really is. Instead what's happening is that the client sends a random number to the server (a challenge) and asks the server to cryptographically sign that number using the certificate issued by the certificate issuer (Client Hello). The server then signs the random number with its private key, and returns the signature and the certificate to the client (Server Hello). The client can verify that 1) the signature is valid for the challenge it sends and the certificate returned by the server, 2) the certificate is for the correct server and is still valid, 3) the certificate is cryptographically signed by an issuer trusted by the client.

The random number signed in the ClientHello is also used to derive the encryption key, using a process called Diffie-Hellman key exchange. The end result is that the server and client both derive a session key that cannot be known by q MITM even when all the exchanges up to that point is over MITMed and in plain text.

The only time that the certificate issuer ever need to contact the server to validate the server is before the certificate is issued, during domain validation when the certificate issuer themselves are verifying the identity of the server. Afterwards, the certificate issuer doesn't really need to contact the server again.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • A possible reason to contact the issuer at a later point would be to check for a revocation (via OCSP). – Arminius Mar 15 '17 at 02:55
  • @Arminius: that's correct, I skipped over revocation check (CRL/OCSP) to keep the explanation simple. – Lie Ryan Mar 15 '17 at 03:06
  • SSL/TLS server doesn't sign any challenge; for _some_ keyexchanges it signs ServerKeyExchange, and for all its Finished effectively MACs the handshake _and_ proves possession. Only some keyexchanges use DH or ECDH (which are defined as distinct, though equivalent in principle) but all derive a session secret and _multiple_ keys. Could you be conflating with SSH2? That does always use (EC)DH, and does always sign data including an explicit challenge, but doesn't use certs except for a rare OpenSSH extension, – dave_thompson_085 Mar 15 '17 at 04:19