Hacker News Reader

Comment by al_james | Hacker News Reader

There has got to be a sensible way around this. It seems overkill to require every pageview to be over HTTPS, even for otherwise public sites. For example, should these public discussion pages be over HTTPS on hacker news?

On my site I am planning the following: operate the login page over HTTPS and issue two cookies. One is HTTPS only and other other is for all pages. The public (non HTTPS) cookie is only used for identification (e.g. welcome messages and personalisation). However, all requests that change the database in any way are handled over HTTPS and we check to make sure the user has the secret HTTPS cookie as well. Often forms submit to a HTTPS backend and then redirects back to the public page over HTTP. Also, all account information pages (sensitive pages) will be over HTTPS.

This way, the worst that can happen via cookie sniffing is that someone can see pages as though they were someone else. In your case, this is not much of a risk.

View on HN

This is just dangerous. Example. If news.ycombinator.com implemented this dual cookie method. A man in the middle could intercept the page I'm looking at now, where I'm entering this comment in a textarea. They could modify the underlying form to post to the same page as the update form on the profile page, and set a hidden email field. Then when I hit the "reply" button, even though I'm posting to a HTTPS page, I'm not posting to the one I think I am, because the page containing the form it's self wasn't protected by HTTP.

I hope I explained that well enough. Mixed content is hard to do right. Forcing every page over SSL prevents anyone making any modifications to any page, and is just inherently safer.

Wait, if you've got the capability to intercept and rewrite arbitrary http forms, couldn't you just rewrite the homepage of Google.com the same way? The "action" attribute on the form gets changed to https -mybank- dot com slash profile, hidden fields are inserted, etc, and when the user clicks "Search" he's actually updating aforementioned profile page.

If this is possible, then the dual cookie method would seem to make sense.

True, as long as the site isn't doing referer checks, which most of them probably aren't. This is yet another argument for why the entire web should be secured with SSL.

This is all true but it is somehow different from the topic: one cannot do this kind of attack easily just using Firesheep kind of tool. I think sometimes these discussions are carried away to far.

Well, I would say its not 'just as dangerous' as a man in the middle attack is harder to set up.

Good point though. Maybe this could be solved by including a unique access code with the form that is a hashed value of the user'id and the url that you are submitting to (with salting to make this unguessable). Simply check this value upon submission to make sure it matches the URL seen by the controller. That would prevent anyone rewriting a form to submit to a new endpoint.

Isn't it why we need to implement xsrf protection on every form?

CSRF protection should be implemented even if your entire site is protected by SSL.

Also, I didn't say "just as dangerous", I said "just dangerous"

Sorry for misquoting you.

However, with proper CSRF protection your man in the middle argument is not the case is it?

Is all this extra effort really worth the alternative of just using HTTPS for everything?

Have you really examined the extra cost of 100% https compared with the scheme you've outlined? Sounds like this idea would require a decent amount of effort to identify where to use https, to ensure that each privileged request is using https, etc.

I can see that for some cases it is advantageous to stick to regular http for unimportant requests and use https for the important stuff, but I have a strong feeling that this is only applicable for the minority of use cases and websites.

We cant serve ads over HTTPS and we make most of our money from ads. So that would be very expensive!

You're think about right solution, but you're overdoing it and in the end you're unnecessary complicating very simple thing.

The simplest (and IMHO the best) solution is to have everything served over HTTP for unauthenticated users and everything served over HTTPS for authenticated users (this requires authentication cookie marked as "secure" and regular cookie "authenticated=true" that would redirect authenticated user to HTTPS version of the site in case that he/she would go to the HTTP site).

But then we can't server ads to signed in users which would be a large revenue cut for us.

Of course you can... unless you want to serve ads over HTTP, then indeed, you can't really do that.

All the advertising networks we deal with only offer HTTPS. Hardly any advertising networks support HTTPS.

...and if noone will complain about that then it won't change.

Reply on news.ycombinator.com