Tags:




Advertise here: Contact FM.


are http forms posted thru https secure?
October 13, 2006 12:07 PM   RSS feed for this thread Subscribe

Can I deliver a form thru http, post it back to the server thru https and be secure?

A friend says that if a form is delivered thru http and the form posts back to an https location it will be transmitted back unencrypted to the https port 443. For the form to post back encrypted, the original form must be delivered thru https.

Is this correct? Can you referr me to an authoritative doc that spells this out (rfc, w3c or browser developer doc)

(Tried using sniffers but on FF they showed unencrytped form info and on IE they showed encrypted.)
posted by Pasa la bola chetu to computers & internet (18 comments total) 1 user marked this as a favorite
It will be transmitted securely
posted by zeoslap at 12:14 PM on October 13, 2006


The caveat is that if you redirect back to your http form say to display errors and what not then that info won't be encrypted.
posted by zeoslap at 12:19 PM on October 13, 2006


I don't see how posting to a secure URL (action="https://...") would ever be unencrypted.

Perhaps you can describe your test setup in more detail?
posted by kamelhoecker at 12:22 PM on October 13, 2006


Your friend is wrong.

The method used to request the form has no bearing on the method used to post the form. It is simply not possible to submit plaintext to an encrypted port--it will look like garbage to the web server and it would reject the form submission if a browser tried to submit the form unencrypted to that port.

The only problem with submitting from an unencrypted form to an encrypted URL is that the web browser won't show the padlock icon on the page (as most browsers do nowadays) to show that the form is secure, even though it will in fact be submitted securely.
posted by Khalad at 12:24 PM on October 13, 2006


To provide more detail on my second paragraph: when a web browser connects to port 443 it must establish an SSL connection before it can transmit the form data. That involves exchanging certificates and such--i.e., an SSL handshake. If the browser doesn't do a proper handshake the web server will simply close the socket in error. With that understanding it simply does not make sense that a browser would submit in plaintext.
posted by Khalad at 12:28 PM on October 13, 2006


It'll be encrypted, but it's best to serve the form itself over SSL as well so the user gets the lock and they know they'll be warned when they press submit if it's going to drop the SSL layer. For proof your friend is wrong, telnet to your server on the SSL port and act like you're going to go about your unencrypted business:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /


<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.
On preview: what Khalad said
posted by moift at 1:52 PM on October 13, 2006


The key fact everyone's missing is that HTTP is STATELESS.

When you submit to a web server, your browser has no knowledge of where it originally came from- a secure request, an unsecure request, local file, memory cache.

Every web page you see is the end of a request-response sequence. Using your example:

1) The browser requests a form, and receives a blank one as a response.
2) Your browser requests a processing confirmation, with the enclosed data, and receives a relevant response.

1 & 2 are, as far as the web server is concerned, totally unrelated. It's the browser, in its request, that is saying, "this sequence is encrypted".
posted by mkultra at 2:09 PM on October 13, 2006


The key fact everyone's missing is that HTTP is STATELESS.

methinks those in this thread understand this, it's the friend that does not.
posted by bitdamaged at 2:23 PM on October 13, 2006


If the form isn't secure though, you won't get the padlock indication in the browser which may create some concern about security with your users.
posted by willnot at 2:47 PM on October 13, 2006


The thing your friend was trying to articulate is that if you deliver the FORM itself over plain http then it is not secure against MITM attacks, and so someone could conceivably intercept it and change the submit location of the FORM to be their own site, thus receiving every user's login credentials (and then sending a fake error message or whatever) and you'd never know. By both delivering the FORM and receiving its POST over https you mitigate this type of attack.

So yes technically the data submitted only happens on the POST and so you can just use https for that, but this assumes that the evildoer has not altered the destination of that POST.
posted by Rhomboid at 3:00 PM on October 13, 2006


I should have said "the thing your friend was probably trying to articulate but was completely wrong about", i.e. the description given is completely bogus, but there is a grain of truth in the sentiment.

Incidently, many banking sites get this wrong. Here is a survey.
posted by Rhomboid at 3:05 PM on October 13, 2006


It doesn't matter if it's secure or not, because no one should ever be doing this.

It's becoming a somewhat common practice for web developers to place a form on an insecure http:// page and submitting it to a https:// URL. This method usually requires them to write a paragraph next to the login form that explains "why this is secure."

Please don't do this. It's really dumb. Yes, the form data will be submitted securely. However, novice users are already really confused about what is and isn't secure on web sites, and people who use this method are making it even more difficult to understand. The more you confuse these users, the more susceptible they are to phishing and other scams (and the more likely they are to avoid web forms altogether).

There are other security-related reasons not to do this, but the above reason should be convincing enough.
posted by helios at 3:05 PM on October 13, 2006


Taking this a slightly different direction, what do you mean by secure?

If you serve your page unencrypted, you're open to a fairly simple attack whereby your page is intercepted in transit and the POST action replaced with a redirect to www.badguys.com. The user fills in their details, hits submit, and everything is delivered directly to the bad guys.

So, while the particular phenomenon your friend is talking about is non-existant (Khalad nails why here), the answer to your title question is "No, you can not deliver a form via http and expect your overall transaction to be secure".
posted by tkolar at 3:15 PM on October 13, 2006


On non-preview, what Rhomboid said.
posted by tkolar at 3:16 PM on October 13, 2006


Helios: In general I agree with you that it's clearer to get the form via https, for a number of reasons. One reason reason not to, however, is so you can have a login section on the top of lots of pages of your site for unlogged in users. The whole site doesn't need to be https, but the "log me in" button's action can be.
posted by aubilenon at 4:55 PM on October 13, 2006


One reason reason not to, however, is so you can have a login section on the top of lots of pages of your site for unlogged in users.

Convient - yes
Widespread and common in practise - yes
Secure - not at all
posted by Rhomboid at 5:34 PM on October 13, 2006


all of these answers echo my argument to my friend, but he demonstrated what he meant.

how many of you are familiar with rfc 2817?

Apparently the problem he was discussing is that not all installations of mod_ssl support the "Upgrade" header described in the rfc.

I just confirmed with a traffic sniffer that using https to POST a form delivered thru http will start out in cleartext. The server replies back with the 'Upgrade' header using the same TCP connection and the browser reposts using TLS. If the server's outgoing headers are rewritten to remove the "Upgrade" header the POSTing continues thru in cleartext.
posted by Pasa la bola chetu at 8:09 PM on October 13, 2006 [1 favorite has favorites]


The salient point here seems to be not that the form is delivered via http, but that you are using port 80 to do both encrypted and non-encrypted. Quoting from the rfc:


This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
initiate Transport Layer Security (TLS) over an existing TCP
connection. This allows unsecured and secured HTTP traffic to share
the same well known port (in this case, http: at 80 rather than
https: at 443)


I'd be interested to know what you did to demonstrate this... what server you're using etc.
posted by RustyBrooks at 8:33 PM on October 13, 2006


« Older Can a retail store sell produc...   |   How can I get Illustrator CS2'... Newer »
This thread is closed to new comments.