Reverse proxy sharing one certificate for multiple servers using Subject Alternative Name

Question

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.

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.