So I have an HTTP client which supports HTTPS. However, it doesn't follow the HTTP spec recommendation for redirects on POST(which is to ask the user before redirecting)

This means, in theory, if you POST to say https://example.com then it can redirect to http://example.com and the POST request will be sent in plain-text. This is very unintuitive, but is it insecure? Is it possible to stage an attack using this assumption if you have control of the routing and/or DNS of the client? Could you somehow hi-jack say https://facebook.com to redirect to your plain-text server and get away with their login info?

Note: it will of course error out on certificate mismatches or other certificate errors, but it will blindly allow you to redirect a POST or GET from an HTTPS link to an HTTP link

Is this exploitable from the point of view of a captive portal?

1 Answer 1


A redirect is when the server responds to the client: "to get what you look for, you must ask again as that URL". If the POST target, from the client, is an https URL, then the request and the response will be protected by SSL. In particular, SSL protects against "injection" by an attacker of a "redirect" response.

However, if the SSL server really wishes to redirect the client to a non-SSL address, then the client will do just that, and send its POST again, this time with plain HTTP. This second sending, being unprotected, is vulnerable to all the usual attacks since it is not protected: eavesdropping, alteration, misdirection...

It is like living in a bunker, then stepping outside. You decide, securely, to exit the bunker; and you take that decision while you are still in the bunker. But, once outside, anything goes.

You must log in to answer this question.

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