
HTTPS Watch - kingkilr
https://httpswatch.com/
======
ggreer
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/](https://www.ssllabs.com/ssltest/)

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

~~~
ggreer
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/](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](http://tools.ietf.org/html/rfc6797#section-7.2)

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

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

------
benguild
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
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...](https://addons.mozilla.org/nl/firefox/addon/calomel-ssl-validation/)

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

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

------
kyhwana2
NZ version: [https://httpswatch.nz/](https://httpswatch.nz/)

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

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

~~~
kyhwana2
Oh, there was a bug in the script, i've merged gutworth's latest code that
fixes it (And the weird green tick when the TCP connection just gets reset).

Page has been updated :)

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

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

[http://sslswitch.com/](http://sslswitch.com/)

~~~
nodata
How are you not affiliated with your friend?

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

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

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

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

~~~
rvern
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
_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/](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.

~~~
rvern
That is not what subresource integrity is for.

Transport Layer Security guarantees, among other things, that the content
really comes from the server it should come from¹. This means that the content
was not manipulated by a man-in-the-middle.

However, it does not guarantee that the content was not manipulated by an
attacker with access to the server. If a web application (say Gmail) includes
a JavaScript library (say jQuery) served by a content delivery network (say
code.jquery.com), it can use subresource integrity to have the browser verify
that the library was not manipulated by an attacker.

This prevents the threat model where the content delivery network becomes
compromised and an attacker replaces the library by malicious code that sends
the private data of users to the attacker.

Subresource integrity can also prevent other attacks, but it complements end-
to-end encryption. It does not replace it.

¹ This assumes that the certificate is valid, of course. There are problems
with the current certificate authority model, but there are also solutions to
these problems.

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

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

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

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

~~~
cperciva
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".

~~~
stephen_g
So I should compromise my users security for the incredibly obscure use-case
of people who want to browse with their own hand-made tools?

There are several readily available TLS stacks for embedded systems (CyaSSL,
PolarSSL, etc.) and plenty for other platforms (Open/Libre/BoringSSL, NSS,
etc.), so 'people without a working TLS stack' is not a real-world use case
you need to take into account.

~~~
sanxiyn
The argument is that someone may not be able to _audit_ TLS stack, not that
someone may not be able to _use_ TLS stack.

Requiring TLS forces people to include TLS stack, which enlarges trusted
computing base a lot. Security depends on many things, but the size of trusted
computing base is an important factor.

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

------
jspaetzel
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/](https://login.launchpad.net/) or launchpad.net.
Perhaps once [https://letsencrypt.org/](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](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.

~~~
stephen_g
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](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.

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

