The following is a scenario for an attack where one website can impersonate another. I am told (including by this answer) that it's impossible, but I would like to understand exactly what prevents it.

Alice uses websites that fetch a trusted JS resource from Bob's server, using HTTPS to prevent MITM attacks. Bob's resource is popular, and he starts to use a CDN to distribute it. Now Alice's browser is making an HTTPS connection to a server belonging to the CDN.

The CDN uses Subject Alternative Names to share a certificate between multiple customers whose sites share an IP address on the CDN. Eve happens to own a site which is on the same certificate as Bob's (1). Eve knows Alice's favourite coffee shop, and can intercept signals on the wifi there.

Since Eve doesn't have the certificate's private key, she can't read Alice's HTTPS traffic. Instead, she waits for a request for the resource on Bob's site (2), and replaces it with a request to her own site, via the same CDN IP address that proxies both sites. The CDN server decrypts the request, fetches a malicious resource from Eve's site, and encrypts that using the shared certificate. Alice's browser sees a valid response from the CDN IP that it sent the request to, and seemingly has no reason not to accept it. Note that Eve doesn't need to modify the response by MITMing - the CDN server sends back the malicious content from a server behind it.

  1. Or is able to hack into one. One of them is bound to be insecure.
  2. Is the URL encrypted in an HTTPS request? If so, assume Eve replaces all requests going to the relevant IP address and bets on detection being unlikely.

I'm not especially familiar with SSL, so I'm willing to believe that something in that doesn't hold, but I'm not sure what, exactly.

  • The flaw in this argument is the "shared certificate". There is no such thing. Commented Aug 6, 2014 at 3:20
  • @Jeff-InventorChromeOS: Possibly I'm calling it the wrong thing. At least one major CDN does use Subject Alternative Names to have certificates which are valid for multiple unrelated domains.
    – Thomas K
    Commented Aug 6, 2014 at 16:35

1 Answer 1


In such a case when multiple websites are served from the same server on the same port, that server differentiates between them by comparing the Host: header in the HTTP request.

Once TLS negotiation has occurred, it is not possible to read anything inside that request. You further cannot swap between two simultaneous SSL connections because a simple Diffie-Hellman key exchange produces a different key for each negotiation.

This is the crux of the issue: the Host: header is within the SSL encrypted transmission. Therefore, it is not possible to tamper with that header and not possible to redirect that request even to a different VirtualHost on the same machine.

Without the Private Key, there's not a lot you can do to break SSL.

EDIT: Yes. What you're suggesting would require some sort of tampering with the request. SSL basically consists of a TCP packet with an entirely garbled content, and what you want to do in this case is alter the garbled content to illicit a different response from the server. That isn't possible without breaking SSL. The only alteration you could make is to the TCP header to change the destination IP or port, but in your case that won't accomplish anything as you still intend to target the same service on that same server.

Clarification On SSL Negotation

The SSL negotiation uses a different key each time. Basically, the client generates a random number and encrypts that using the Public Key. This can only be decrypted with the Private Key. At this point, only the Client (who generated the key) and the server (who was able to decrypt that with its own private key) know this random number.

There is no way for an attacker to get that number. You could, theoretically, repeat that same encrypted secret to the server to open up a connection using that same key, however you still would not know the secret nor would you be able to alter any packets encrypted with it.

This would, however, allow you to use a replay attack (and repeat a request like "delete next item" again), so my guess is that there are other features within SSL to mitigate this risk.

  • Thanks! So in the scenario I described, is it the case that Eve cannot forge an SSL request to elicit a valid response to Alice, because Alice's browser will only accept a response on the same SSL connection that it established? I think that makes sense.
    – Thomas K
    Commented Aug 6, 2014 at 16:40
  • Correct. See the clarification above. Commented Aug 6, 2014 at 21:04
  • And just to double check: while Eve can obviously create a new, valid SSL packet with a different request to the same server, the response from that can't be routed on to Alice, because Alice's browser has established a different key for its SSL session, right?
    – Thomas K
    Commented Aug 6, 2014 at 21:13
  • Yup. I added a clarification on SSL negotiation to the answer, because I think a lot of issues with SSL come from a lack of concrete understanding of asymmetric cryptography like RSA. Commented Aug 6, 2014 at 21:24
  • Thanks, I've accepted this answer. Now that I'm satisfied about the security: the real case I was interested in was that of Mathjax, which is served over Cloudflare.
    – Thomas K
    Commented Aug 6, 2014 at 21:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .