HTTPS Watch (opens in new tab)

Mostly mobile from a risk perspective. If you connect to other people's WiFi networks or even have your own configured to auto-connect it's possible to use devices like the WiFi Pineapple and more to man-in-the-middle (MitM) your connection. If you aren't using a VPN, and lets face it, nobody really does, then a bad guy MitM could inject JavaScript of choice into the HTTP response for major sites, thus using them as a gateway to execute exploit code within the context of your browser. Many modern exploits don't rely on writing to disk and instead remain resident in memory so AV really doesn't even save you. If everyone on the web only supported HTTPS the risk of an evil MitM compromising your device while on WiFi goes down fairly significantly so long as you don't do something stupid and install a rogue root CA or accept browser crypto warnings and continue.

It also helps mitigate things like rogue advertisement injection by hotels, ISPs, etc.

Because no one has any business knowing what content you're accessing. That should be a secret between yourself and the website you're on.

It guarantees that the text you are seeing really comes from that website, that it hasn’t been tampered with by an actor between you and the server.

This means that Internet service providers and others between you and the website cannot insert ads in web pages. It also means that if you’re reading a newspaper online (for example), you can be sure that the articles you read really are from that newspaper, that all the articles are there and that they were not modified.

It also prevents URL or content-based censorship, since mans-in-the-middle cannot know what URLs you visit or what content you received from a website.

It does not prevent domain name or IP-based censorship, since the man-in-the-middle can know these, and it is also sometimes possible for a man-in-the-middle to know what page you are visiting by examining the length of the URL and content and comparing them with public information available on the website.

It's trivial to rewrite plaintext on the fly and the number of people in a position to do so is staggering. Like passing a note in class, it's basically about trust. You want to ensure the message hasn't been tampered with by the time it reaches you. HTTPS is one way, even if the recent past has backed it into a tiny corner (RIP SSLv2, SSLv3, TLSv1.0 and a long list of cipher suites).

For the reasons given by others, plus many news websites have login functionality for commenting, or for subscriptions etc.

That login info, or at least the cookies it produces, should not be sent unencrypted.

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.

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

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.

There is much more to HTTPS than just ciphers and HSTS, i would personally use the following rating.

1 None - No HTTPS Support/Invalid certificate/Broken or vulnerable cipher or protocols (POODLE, SSLv2 etc'.) Cookies not set as 'SECURE'.

2 Poor - Valid certificate, weak or anonymous cipher suits, none standard ciphers. Site serves mixed content. Any certificate issues like SHA1/MD5 signatures, low rated CA's, lack of revocation lists etc.

3 Good - Fully validated cert and chain, including revocation lists, supports only secure cipher suits with forward secrecy. HTTP-HTTPS redirection or HSTS, all cookies are set as 'SECURE'. No mixed content.

I think the main problem is mixed content. Wikipedia has excellent HTTPS support, but would be listed as mediocre because it isn't the default (I've heard this is due to it needing to be accessible in countries like China). The New York Times (and many other sites) is unusable in HTTPS but has the same classification.

So depending on the application and use case, it may be acceptable to not accept connections on port 80. I still think setting the HSTS header is important, but the redirect isn't (always important).

It's an incredibly common pattern. What's bad about it?

Compatibility maybe?

Why?

Chur bro. Pretty quick turnaround there

Note that westpac's sensitive area is on a separate subdomain sec.westpac.co.nz and does enforce http->https redirect - www.westpac.co.nz is just static marketing stuff.

Also for TSB, you have 'The HTTPS site redirects to HTTP.' but this doesn't seem to really be the case in a web browser.

How are you not affiliated with your friend?

It's part of the HSTS spec that a server receiving a request over HTTP should redirect to HTTPS.

I assume the logic here is that as it's best practice for any site with HTTPS to use HSTS also, all HTTPS sites should not be available over HTTP apart from a redirect to the secure version of the page.

Not yet, as there was a bit of an argument in the HTTP/2 WG about that.

I may suggest a SHOULD NOT again, however.

You can install the Calomel addon in Firefox and see how secure those certificates are. https://addons.mozilla.org/nl/firefox/addon/calomel-ssl-vali...