Hacker News Reader

Comment by jspaetzel | Hacker News Reader

I don't suppose we should be checking the pages that should actually be secure. IE Ubuntu is listed as bad, why not check their login page? https://login.launchpad.net/ or launchpad.net. Perhaps once https://letsencrypt.org/ comes available it will be worth the extra effort to encrypt everything. In the interim it's most likely a waste of funds, especially for projects that operate on donations.

Edit: I was surprised to see the WSJ listed as Bad. Checking their login form, something that should be encrypted, the post goes to... https://id.wsj.com a secure page. I wont go through the entire list, but I expect most of the ones in this list have a similar configuration.

View on HN

Just encrypting the login page or a form action does not work.

Think about, say, browsing on some public WiFi network (airport, cafe, etc.), but it turns out it's actually a rouge access point. Or there's an MITM at the ISP or somewhere. If you hit an unsecured page, I can rewrite the links to be insecure, so now instead of going to https://login.launchpad.net, you actually go to an http page that I proxy to the real page, so you probably don't notice the difference and I can steal your details.

Same with the form - I can rewrite the form action to regular HTTP and seamlessly send it back to the HTTPS once I have stolen your details.

If you have anything that requires security, the entire domain needs to be HTTPS.

Then, of course, there is also the risk of session hijacking.

You're right for pages with links to login pages. Fortunately in this case, ubuntu does not appear to link to login.launchpad.net anywhere on their main website as far as I can tell. I'm sure it's linked somewhere but I was only able to find it via a search. Odd.

In any case I understand the point of all this, get the big sites using it so that the little ones might adopt it as well, the issue is that the cost of adding ssl does not add value to sites without logins. Perhaps letsencrypt.org will make it worthwhile to encrypt those static sites as well, it'd be nice to see hosting providers include this as a default.

Using HTTPS on your login and account management servers but not on other pages of your site that need access to the login (like WSJ's article pages) can leave you vulnerable to session hijacking attacks (like those demonstrated by Firesheep[1] a few years ago against Facebook and Twitter). If you want to be secure, resources that require authentication should always be accessed over SSL, and your session cookies for logged-in sessions should be set as secure (so the browser won't send them over plain HTTP).

[1] http://en.wikipedia.org/wiki/Firesheep

Session hijacking only works on webpages with sessions. Most of these urls are static informational pages without sessions, from the several I looked at.

The WSJ specifically requires login to view articles (because they require an active subscription to read anything on their site). Most of the other newspaper sites (at least; not going to go and pick through the whole list) are the same, with different thresholds for when login is required.

I'm not sure what happens on the site after login on WSJ, if they are doing it semi-correctly then it should be a secure page after login. If that's not the case, then yea they should improve this. Not picking through them individually, there are a number of pages outside the newspaper category that are strictly informational without even login forms.

No, everything should be HTTPS, and these sites fail that. HTTP SHOULD NOT be carried on the bare wire.

Don't be surprised to see port 80 formally deprecated soon.

Reply on news.ycombinator.com