are http forms posted thru https secure?
October 13, 2006 12:07 PM 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.)
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.)
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
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
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
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
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:
posted by moift at 1:52 PM on October 13, 2006
Trying 127.0.0.1...On preview: what Khalad said
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.
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
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
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
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 [1 favorite]
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 [1 favorite]
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
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
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 [1 favorite]
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 [1 favorite]
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
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
Convient - yes
Widespread and common in practise - yes
Secure - not at all
posted by Rhomboid at 5:34 PM on October 13, 2006
Response by poster: 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]
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]
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:
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
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
This thread is closed to new comments.
posted by zeoslap at 12:14 PM on October 13, 2006