Is it acceptable to submit from an http form through https? It seems like it should be secure, but it allows for a man in the middle attack (here is a good discussion). There are sites like mint.com that allow you to sign-in from an http page but does an https post. In my site, the request is to have an http landing page but be able to login securely. Is it not worth the possible security risk and should I just make all users go to a secure page to login (or make the landing page secure)?
Asked
Active
Viewed 3.5k times
74
-
1http://www.youtube.com/watch?v=nm-85-bDP6c – Albert Renshaw Jan 08 '14 at 19:24
11 Answers
53
Posting a form from an http page to an https page does encrypt the data in the form when it is transmitted in the most simple terms. If there is a man-in-the-middle attack, the browser will warn you.
However, if the original http form was subjected to man-in-the-middle and the https post-back address was modified by the attacker, then you will get no warning. The data will still actually be encrypted, but the man-in-the-middle attacker would be able to decrypt (since he sent you the key in the first place) and read the data.
Also, if the form is sending things back through other means (scripted connections) there may be a possibility of unencrypted data being sent over the wire before the form is posted (although any good website would never do this with any kind of sensitive data).
Jason Coco
- 77,985
- 20
- 184
- 180
-
-
I'll also add that HSTS solves this ( well , except for the first request) – Royi Namir Feb 15 '17 at 07:28
33
Is there any reason not to use HTTPS for the entire transaction? If you can't find a very good one, use it!
It's arguably simpler than switching protocols.
The MITM risk is real.
Following your link, the user "Helios" makes an excellent point that using 100% HTTPS is far less confusing to the user.
Adam Liss
- 47,594
- 12
- 108
- 150
-
1I've found people /did/ it in the past for performance reasons, which were legitimate at the time. However, it's one of those issues where the pattern of doing it has been taught as almost dogma even though throughput and performance on servers and clients is more than capable now. – Jason Coco Nov 08 '08 at 03:11
-
1Agreed. Back then, it was also difficult to do vector graphics on an abacus. :-) – Adam Liss Nov 08 '08 at 03:15
-
Indeed :) It's one of the things I don't like about CS programs, they're so behind so they teach these outdated methods and then it's part of everyone's religion... *think* people, think! :) – Jason Coco Nov 08 '08 at 03:17
-
Outdated? You should've seen the 20-pound resistors we used in my undergrad EE lab! At least Ohm's law hasn't changed. Yet. – Adam Liss Nov 08 '08 at 03:25
-
7I think it's better for users to get into the habit of NOT entering login information on a page that is not HTTPS. If I see HTTP and it asks me to login, I just hit login and see if it goes HTTPS, then I actually enter some informaton. – Bratch Nov 08 '08 at 20:01
-
@unknown: Thanks for the link. This appears to be a classic man-in-the-middle attack that depends on an initial http (not https) connection, which is insecure. The solution I suggested requires the user to browse to an address that begins with https: and is therefore both encrypted _and_ authenticated. – Adam Liss Jan 26 '10 at 13:15
16
This kind of thing is popping up all over the net, especially in sites for which login is optional. However, it's inherently unsafe, for quite subtle reasons, and gives the user a false sense of security. I think there was an article about this recently on codinghorror.com.
The danger is that while you sent your page with a post target of "https://xxx", the page in which that reference occurs is not secure, so it can be modified in transit by an attacker to point to any URL the attacker wishes. So if I visit your site, I must view the source to verify my credentials are being posted to a secure address, and that verification has relevance only for that particular submit. If I return tomorrow, I must view source again, since that particular delivery of the page may have been attacked and the post target subverted - if I don't verify every single time, by the time I know the post target was subverted, it's too late - I've already sent my credentials to the attacker's URL.
You should only provide a link to the login page; and the login page and everything thereafter should be HTTPS for as long as you are logged in. And, really, there is no reason not to; the burden of SSL is on the initial negotiation; the subsequent connections will use SSL session caching and the symmetric crypto used for the link data is actually extremely low overhead.
Lawrence Dol
- 63,018
- 25
- 139
- 189
10
IE Blog explains: Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page)
- How does the user know that the form is being submitted via HTTPS? Most browsers have no such UI cue.
- How could the user know that it was going to the right HTTPS page? If the login form was delivered via HTTP, there's no guarantee it hasn't been changed between the server and the client.
Kornel
- 97,764
- 37
- 219
- 309
6
Jay and Kiwi are right about the MITM attack. However, its important to note that the attacker doesn't have to break the form and give some error message; the attacker can instead insert JavaScript to send the form data twice, once to him and once to you.
But, honestly, you have to ask, what's the chance of an attacker intercepting your login page and modifying it in flight? How's it compare to the risk of (a) doing a MITM attack strait on the SSL session, and hoping the user presses "OK" to continue; (b) doing the MITM on your initial redirect to SSL (e.g., from http://example.com to https://example.com) and redirecting to https://doma1n.com instead, which is under the attacker's control; (c) You having a XSS, XSRF, or SQL injection flaw somewhere on your site.
Yes, I'd suggest running the login form under SSL, there isn't any reason not to. But I wouldn't worry much if it weren't, there are probably much lower hanging fruit.
Update
The above answer is from 2008. Since then, a lot of additional threats have become apparent. E.g., access sites from random untrusted networks such as WiFi hotspots (where anyone nearby may be able to pull off that attack). Now I'd say yes, you definitely should encrypt your login page, and further your entire site. Further, there are now solutions to the initial redirect problem (HTTP Strict Transport Security). The Open Web Application Security Project makes several best practices guides available.
-
2Yes, there is likely lower hanging fruit; but that mindset is why the web is so incredibly insecure... everyone's out there saying it's not that important... but what if some unsuspecting user uses the same password on your site and on their bank's website??? – Lawrence Dol Nov 10 '08 at 01:34
-
3"what's the chance of an attacker intercepting your login page and modifying it in flight?" It's not a question of probability, it happens or not at the choice of the attacker. And yes, MITM does happen in practice. "There are probably much lower hanging fruit" is just about the weakest argument one can make about anything. Really, can you think of a weaker one that not just plain false? Besides, even if your attacker can be counted on to pick the lowest fruit first, what is to say they stop there? – Marsh Ray Nov 07 '09 at 07:42
-
"Chance" is definitely a bad choice of words on my part. However, I don't think you're gaining much actual security, because of the other attack vectors. A MITM attack may compromise your users one user (or ISP) at a time, but a SQL injection may compromises all your uses at once. It makes sense, I argue, to spend your security time where you'll get the most bang for the buck, and that's probably not SSL vs. non-SSL login pages. – derobert Nov 11 '09 at 21:50
-
1If there's a MITM attack, you've got bigger problems. First off, they could easily just change the "sign in" link to point to their own attack site, or, better yet, they could intercept the DNS lookup to make their site look completely legit to the user. And before you say "oh, but the browser will warn the user"--no, no they won't. Even if the user checks for valid SSL certificates, there are ways around that. So your only option I guess is to do all commerce offline. – Lèse majesté Nov 20 '10 at 00:17
2
This post is the key one. Yes, if the user's data is sent to you, it will have arrived somewhere securely. But there is no reason to believe that somewhere will be your site. The attacker isn't just going to get to listen to the data moving in each direction at this point. He'll be the other end of the user's session. The your site is just going to think the user never bothered to submit the form.
Jay Kominek
- 8,674
- 1
- 34
- 51
2
For me (as an end-user), the value of an HTTPS session is not only that the data is encrypted, but that I have verification that the page I'm typing my super-secrets into has come from the place I want it to.
Having the form in a non-HTTPS session defeats that assurance.
(I know - this is just another way of saying that the form is subject to an MITM attack).
Michael Burr
- 333,147
- 50
- 533
- 760
1
No, it's not secure to go from HTTP to HTTPS. The originating and resulting points of the request must be HTTPS for the secure channel to be established and utilized.
Kon
- 27,113
- 11
- 60
- 86
-
The question was whether or not it is save to provide an initial form on HTTP, and post the data through HTTPS. It's not possible to switch half-way through a transfer, but is possible to have items placed on both. – Raymond Martineau Nov 08 '08 at 06:10
-
6+1 This answer is absolutely correct. You can't even guarantee the form will be submitted via HTTPS if it was delivered via HTTP. – Marsh Ray Nov 07 '09 at 07:37
1
Everyone suggesting that you provide only a link to the login page seems to be forgetting that the link could easily be changed using a MITM attack.
RWS
- 11
- 1
-
1But then, when the user follows the link to the (secure) login page, the SSL negotiation can alert them if any shenanigans are going on. – Mr. Shiny and New 安宇 Jul 01 '10 at 19:09
-
@Mr Shiny and New: Only if they look closely at the URL. The best option is to HTTPS your entire site. – Bart van Heukelom May 14 '11 at 21:58
-
1@Bart van Heukelom: HTTPs'ing the entire site only works for properly-typed-in urls or properly-saved bookmarks, then, doesn't it? If the user NEVER looks at the url (or anywhere on the location bar of modern browsers which provided enhanced visibility of the hostname you're connected to), then SSL is fairly pointless. – Mr. Shiny and New 安宇 May 16 '11 at 11:53
-
@Mr Shiny and New: That's true, but the initial redirect from HTTP to HTTPS, especially if the user then bookmarks the HTTPS version, is a smaller window for a hacker than every time the login link is clicked. – Bart van Heukelom May 16 '11 at 14:46
-
@Bart: Yes, and the user can just as easily bookmark the HTTPS login page, which is what I do, after verifying the login URL is correct which I only have to do when I bookmark it. – Lawrence Dol Aug 08 '12 at 20:36
1
One of the biggest things missed out in all of the above is that there is a general trend to place a login on a home page (Huge trend in User Experience Trends).
The big problem here is that Google does not like to search secure pages with good reason, so all those Devs who are wondering why not make it all secure, well if you want your page invisible to Google, secure it all. Else, the second best option to post from http to https is the lesser of two evils at this point?
glenn
- 11
- 1
-
1No, the second-best option is to link from the HTTP site page to the HTTPS login page. – Lawrence Dol Aug 08 '12 at 20:38
-2
I think the main consideration of this question has to do with the URL that users know and the protocol scheme (http:)that browsers substitute by default.
In that case, the normal behavior of a site that wants to ensure an encrypted channel is to have the http://home-page redirect to https://home-page. There is still a spoofing / MitM opportunity, but if it is by DNS poisoning, the risk is no higher than if one starts out with the https: URL. If a different domain name comes back, you need to worry then.
This is probably safe enough. After all, if you are subject to a targetted MitM, you might as well start worrying about keyboard loggers, your local HOSTS file, and all sorts of other ways of finding out about your secure transactions involving your system already being owned.
orcmid
- 2,618
- 19
- 20
-
1"After all, if you are subject to a targetted MitM, you might as well start worrying about keyboard loggers, your local HOSTS file, and all sorts of other ways of finding out about your secure transactions involving your system already being owned". And how did your system get owned in the first place I wonder? – Marsh Ray Nov 07 '09 at 07:45