Suppose I want to talk to example.com over TLS the and server I am redirected to is foo.com. But during the handshake it can prove it holds the private key that matches example.com certificate.
Why does that trigger a warning in the browser?
-
The question is invalid or not worded properly. You can't be redirected to foo.com when you want to talk to example.com on TLS. – Cristian Dobre Aug 2 '15 at 17:31
-
@CristianDobre When I improved the OP's question, I did not know what to do with the verb redirect too, so I left it that way. But regarding the description he gives of his problem, I think he means that when the SSL handshake occurs, the browser requests a certificate from the server before it shows the host header, so this late one (server) can not to decide which certificate to send. This scenario is typically present in shared hosting environments. – user45139 Aug 3 '15 at 4:53
-
Need any more explanation adding to my answer? – SilverlightFox Aug 14 '15 at 18:12
Actually, the answer is within your question:
But during the handshake it can prove it holds the private key that matches example.com certificate
This outlines that that the common name in the SSL certificate doesn't match the address that is in the address bar of the browser (foo.com). I mean the warning claims that the certificate that has been picked up by request is issued for example.com, not for foo.com .
It is like foo.com is trying to intercept the communication between you and example.com, and that is the reason of the legitimate security warning you got.
The problem is that the certificate is only valid for use with example.com. A redirect means that there is a completely new connection (to foo.com), and thus the browser treats it as a different server.
To see why this is important, lets look at a hypothetical (and slightly simplified) example. If the browser would accept the certificate belonging to example.com for foo.com, then you could enter your password for foo.com and send it to example.com -- if you imagine that example.com is an attacker, and foo.com is your online bank, then you just sent the attacker your bank password!
In general, redirects are a bit complicated for TLS, because there is no easy way to know whether foo.com and example.com are controlled by the same entity.
answered Aug 2 '15 at 14:58
The certificate provides authentication. That is, some level of trust that you are connecting to the server that you intended to.
If a MITM redirects your plain HTTP connection from example.com to https://foo.com instead of https://example.com, it doesn't matter if foo.com has the private key for the example.com certificate - your browser will be looking for the authentication for foo.com not example.com - it does not care that you were redirected there from example.com.
answered Aug 3 '15 at 13:40
