Hacker News Reader

Hacker News

Comment by joevandyk | Hacker News Reader

Parent Full thread

joevandyk

amazon uses https for any important/sensitive pages. there's two sessions, one for http, one for https.

View on HN

What if HTTP page is mitmed and links to secure pages are replaced to point to somewhere else? It's all or nothing.

What if DNS is mitmed?

No one cares as long as you are using HTTPS, which is the point.

If you aren't using HTTPS for all of your site, you are vulnerable to MITM attacks.

Presumably, the browser still needs to interrogate dns even if it talks over https, no?

Sure, and this is what HTTPS certificates from a CA are for. If your users are willing to click through the "warning: self-signed certificate" popups, then they're vulnerable, of course. But if they don't make that mistake, then your DNS result is reliable unless someone compromises the CA. Of course, CAs do get compromised.

Or did I miss the point of your comment?

IsTom's comment was about how an HTTP-served page might be modified to make the "secure" links actually point to a non-HTTPS fake login page (for example). This assumes the user will not notice that the connection is not secure (which I think is a fair assumption).

Given that, another attack might be to mitm DNS and serve an entirely fake Amazon site, all in HTTP, and the user will not notice there's anything wrong.

I think that's the point mro and troels were trying to make.

The only way I can imagine to mitigate this would be to use HSTS on the amazon.com home page.

Can you explain more on how two sessions would work? I mean if the hijacker hijacks the http session he can convert it to https by following the same steps the user does. Since amazon does not ask the user to reauthenticate on https pages.

You can set the secure flag when creating a cookie which will only send it over an HTTPS connection.

It is possible to use both schemes, but it is likely better to stick to all SSL if possible in case of developer error causing something to get exposed when it shouldn't.

You have two cookies, one for HTTP, one for HTTPS. The latter uses a secure flag so it can't be seen with HTTP connections. When the user logs in, both are set.

Reply on news.ycombinator.com