So I was just thinking about how ARP poisoning can be used to intercept a clients request, forge an SSL cert, and send it back, with the caveat of not meeting certificate validation, but what if I were to intercept a client communication, send back a 301 to the http version of the site if the request is SSL, and then act on behalf of the client when communicating with the legitimate server over HTTPS.

if the client believes that I am the router, how would the client ever know that it has been forced to HTTP?

Obviously the browser bar would be white, not green, but that is almost a moot point regardless.

3 Answers 3


If the client's initial request is for HTTPS, then the client will insist on first doing the SSL handshake, and only then, within the newly created SSL tunnel, will the client send the actual HTTP request, the one you want to respond to with a 301 code. This means that if the client entered the https:// URL (either he typed it, or followed a bookmark which includes it), then, as an attacker, you still have a SSL thrown against you.

Of course, if the client is prone to click through the "friggin' browser warnings" then all bets are off.

Similarly, if the client always types the raw server name, and expects the server to receive the HTTP request and send back a redirect to HTTPS, then you can intercept that redirect and keep the client on a pure-HTTP fake site. It always bring us back to the client and what he is ready to accept. If the client performs an HTTP (not HTTPS) request at some point, and won't notice the lack of padlock icon or green URL bar, then you can leverage that single point of vulnerability to keep the client in a non-SSL world, intercepting all attempts at redirection to SSL. Automation of this attack has been demonstrated under the name sslstrip.


If the client specifically types in https in their browser, then you couldn't do what you are saying as the browser would first request the certificate before allowing you to send the 301 redirect. You don't have a valid certificate for the domain, so the user would see a certificate exception.

If the client does not initially try to set up an HTTPS connection, but instead clicks on an HTTPS link or gets an HTTPS redirect, there are lots of things you can do. One tool to automate this is sslstrip.


As the other answerers pointed out - if the client explicitly requested an HTTPS connection, then the downgrade attack that you describe wouldn't work. However, you could use an ARP-poisoning type of attack as a vector for a tool like sslstrip to transform https redirects and https links to http. This is why we now have things like HTTPS Everywhere and HSTS, to counter these types of attacks.

You must log in to answer this question.

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