HTTPS Watch

by kingkilr • 12 years ago

136 56 12 years ago

mnx• 12 years ago

"If a verified TLS connection cannot be established or no page can be loaded over TLS, the site is given the Bad rating."

So, bad = none.

benguild• 12 years ago

I think this is a really good idea. I mean, today to most people the measure of whether or not a site is “secure” is just whether or not the lock icon displays when they’re browsing.

An actual “public shaming” of sites with bad security is probably all that’s effective at this point.

rogeryu• 12 years ago

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...

jspaetzel4• 12 years ago

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.

JonathonW2• 12 years ago

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

jspaetzel4• 12 years ago

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

stephen_g3• 12 years ago

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.

jspaetzel4• 12 years ago

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.

AlyssaRowan3• 12 years ago

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.

ggreer2• 12 years ago

The current ratings seem too simplistic and strict. I think a better rating system would be:

1. None. Not listening on https.

2. Bad. Invalid cert or broken cipher suites.

3. Ok. Valid cert and good cipher suites, but no redirection to https.

4. Good. Http redirects to https.

5. Great. Redirects to https and sets HSTS header.

6. Amazing. In browser HSTS preload lists.

It may make sense to change the criteria as sites improve, but that list seems sane today. I'd also recommend using letter grades (A+, A, B, C, D, F), but that might cause confusion with SSL Labs[1].

1. https://www.ssllabs.com/ssltest/

daigoba66• 12 years ago

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).

ggreer2• 12 years ago

Redirecting to HTTPS is heavily encouraged by the HSTS spec.[1] Clients are just as easily man-in-the-middled if you refuse connections on port 80. The middleman can connect to your HTTPS and use it to send valid (though maliciously corrupted) HTTP responses to the client.

There's only one way to ensure clients aren't MitM'ed on first connect: Go to https://hstspreload.appspot.com/ and submit your site to Chrome's HSTS preload list. Firefox slurps Chrome's list from time to time. The lists are shipped with browser updates, so the whole process takes months.

1. http://tools.ietf.org/html/rfc6797#section-7.2

dogma1138• 12 years ago

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.

nsgi• 12 years ago

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.

slimetree• 12 years ago

For someone who doesn't get it, why do you need https on websites that just show you some text?

CaveTech• 12 years ago

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.

patcheudor• 12 years ago

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.

wampus• 12 years ago

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).

rvern2• 12 years ago

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.

Animats• 12 years ago

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.

That's what subresource integrity is for. (http://www.w3.org/TR/SRI/) Links with subresource integrity include the hash of the content to be delivered. Subresource integrity allows caching by content delivery networks and ISPs without allowing them to change the content.

Using HTTPS for general static content is that it breaks caching and CDNs. Because it breaks CDNs, many CDNs (especially Cloudflare) break HTTPS by terminating the HTTPS connection at the CDN. They may or may not encrypt from the CDN to the actual host. This makes big CDNs a central point of attack for snooping purposes.

While this is an unpopular opinion, I consider HTTPS Everywhere a form of security theater. We need really strong security on logins, financial data, and such. We do not need to encrypt newspapers or public cat videos.

christop2• 12 years ago

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.

rocky11382• 12 years ago

Is there a search engine which returns only results which themselves use https?

markbao• 12 years ago

I'm curious why this lists but few of the Alexa top 10, such as Google, Yahoo!, Facebook, Twitter, and others. The first two are mega-sites and only the root domain would count most likely, but social sites constitute a lot of communication. (Even better would be to say whether app connections are secure, such as knowing whether Snapchat connections are over TLS or not, though that's probably out of scope.)

jMyles• 12 years ago

Is it protocol at this point to always redirect from HTTP to HTTPS? Is there an RFC for that?

stephen_g3• 12 years ago

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.

AlyssaRowan3• 12 years ago

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.

watchesfromch• 12 years ago

Forcing a HTTP to HTTPS redirect is a really bad behaviour.

rocky11382• 12 years ago

Why?

ninkendo• 12 years ago

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

cperciva3• 12 years ago

It makes your site inaccessible to people who don't have TLS stacks. I can write and carefully audit an HTTP/1.0 client in a weekend; auditing even the bare minimum the code needed to speak TLS would take months or years.

"HTTPS Everywhere!" means "Heartbleed-like bugs everywhere".

0xCMP• 12 years ago

Compatibility maybe?

hughes• 12 years ago

I would love to see a list of financial institutions included. I checked www.bankofamerica.com and secure.bankofamerica.com on SSL labs found both to have identical (B-grade) security.

IkmoIkmo• 12 years ago

Healthcare.gov being an example to the rest... go figure.

theVirginian• 12 years ago

I was looking forward to a smartwatch that somehow made use of https. Now I feel like an idiot.

BorisMelnik2• 12 years ago

would also like to recommend my friend who runs a similar product (I have no affiliation):

http://sslswitch.com/

nodata• 12 years ago

How are you not affiliated with your friend?

BorisMelnik2• 12 years ago

normally when people say I have no affiliation, it is infered that they mean they are not part of, invested in, a member of, that company.

kind of like how I have a friend that works for Coca-Cola, but I'm not affiliated with them.

christop2• 12 years ago

I always find it slightly weird, when reading Snowden-related articles and looking at the NSA PDFs on Der Spiegel, that they don't use HTTPS (and even actively, permanently redirect to HTTP).

kyhwana23• 12 years ago

NZ version: https://httpswatch.nz/

mappu• 12 years ago

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.

kyhwana23• 12 years ago

Yeah, it looks like the script doesn't handle the . to www. redirects. I've fixed them all up (hopefully) and a few scores have changed.

It's only checking the main sites, not the separate internet banking login pages atm.

aksophist• 12 years ago

Where is the line item for "prevents downgrade of HTTPS connections to vulnerable protocols"?

HTTPS Watch

Related Stories