Will data be encrypted if an HTTP page POSTs to a HTTPS handler that redirects back to HTTP?

Question

My host gave me a subdomain of their domain that has HTTPS:

https://mysite.example.com

My own domain name has no SSL installed, so the only way I can take advantage of encryption is by using the address above

I would like to secure the registration page of my website by putting a form on my HTTP website. That form will have an action URL to https://mysite.example.com/register_data. That form handler will then redirect back to my HTTP website.

Users will never see the HTTPS address. They will open the HTTP address, put in the data, submit the data and be redirected back to the HTTP site.

Will the submitted data be secured and encrypted normally?

Answer 1

Will the submitted data be secured and encrypted normally?

Yes, when the data is submitted from HTTP to HTTPS (via the form's action attribute), the data will be sent via an encrypted connection. However, the user will probably be unaware of this, so the "user trust" that HTTPS provides is non-existent.

...that redirects back to HTTP?

The redirection (part) back to HTTP will obviously not be encrypted. No passwords should be sent back at this stage, so that shouldn't be a problem, although a username might be if you are repopulating the login form on failure? But any authorisation (or session) cookie will also be sent back unencrypted, so this could potentially be sniffed. (Although if an authorisation cookie is also validated against the users IP address it will be harder to hijack, but also harder for your users if they have frequently changing IP addresses!)

Answer 2

This is not secure (but better than posting to HTTP). The data will only be encrypted in cases where no man-in-the-middle attack is undergoing, but of course one of the reasons for offering HTTPS is the assumption that such MitM attacks could happen.

Attackers will be able to tamper with your HTTP page. They could, for example:

• change the form-action URL to one under their own control (so they get the data instead of you)
• change the form-action URL from HTTPS to HTTP (so everyone listening can see the submitted unencrypted data)
• inject some JavaScript that gives them access to the data entered into the form (so they get the data in addition to you)

To protect against this, also the registration page has to be served via HTTPS.¹

---

¹ But if you only use HTTPS on some pages, and your users don’t check if they’re on HTTPS currently, attackers could serve them a HTTP variant of the registration page. The simplest solution is enforcing HTTPS for the whole site + HSTS.

Answer 3

The POST request will be protected by SSL, but there are other problems to think of:

1. When switching between HTTP and HTTPS it is easier to do an SSL-Strip attack.
2. The session id will be sent to HTTP requests too and therefore can be sniffed easily.

It is surely a good idea to switch to HTTPS for the whole site, but if that is out of question, then you could at least separate authorization from session handling:

1. Use a second cookie for authorization and send it only to HTTPS requests.
2. Send the session cookie to HTTP and HTTPS requests, but use it only to maintain the session, not for authorization.

More information and an example you can find on my homepage.