Mozilla HTTP Observatory
observatory.mozilla.org
observatory.mozilla.org
Even if we do care about these nefarious men in the middle, the elephant in the room is that a large part of the encrypted traffic these days go through major CDNs, and for them to actually pages and and route requests and be anything more than a glorified NAT, they need to inspect what's being sent, and keep track of who is sending it. Even if they totally pinky swear they aren't doing anything nefarious with their position of being able to inspect and analyze a huge portion of the Internet's traffic, and even if we believe them, that can change.
Remember SourceForge? Remember when they were the heroes of open source, the go-to host for source code and binaries? Remember when they were bought up and subsequently were caught with their fingers in the cookie jar bundling malware in said open source packages?
All I'm saying is that there sure is a lot of eggs in that basket. Is a lot easier to lean on one or two CDN operators than it is to lean on every ISP in the country.
First of all, that's ignoring how easy it is to MiTM on a public wifi network.
Secondly, if a CDN starts misbehaving, customers can switch to a different one. For many people in the US at least if an ISP is misbehaving, there may not be any other option to switch to.
And how would you find out if a cdn was misbehaving, especially in the context of gag orders? And even if we did find out, it's out in the open that Facebook and Google is doing all this really invasive tracking, yet nobody seems to be leaving them in any hurry.
What kinds of clients dont support HTTPS?
There is also a growing problem with stale root certs that are not always possible to update.
Take Hacker News for example. If you go to the home page without logging in, you'll see a list of posts. Does this need HTTPS?
Using your logic, it wouldn't.
But there's a login link in the top right corner of the page. If someone were to MITM the home page, they could make this login link go elsewhere, and harvest data.
The same is true of any site which has links to login/signup/payments/contact forms etc.
That describes virtually every site these days.
It's much easier to have every part of the site on HTTPS, than to have to worry about this.
Plus you avoid the possibility of malicious ads, scripts, and malware being injected into the page.
1. inject javascript on the kitten site that, in case if you move on to a different tab for five minutes, redirect the page to a spoofed version of the login page of your payment provider or email account usable to recover other credentials, so that if you go back to that tab you might think that your session there just expired and "re-login".
2. inject javascript on the kitten site that replaces any legitimate links to social media platforms with links to spoofed login pages for these platforms.
3. inject javascript on the kitten site that adds an overlay over the kitten videos where clicking on it prompts you to download video_player_plugin_totally_legit.exe in order to watch the kitten videos.
4. inject javascript that replaces any ads (or just adds them) with attacker-controlled ones; possibly for some targeted scams.
5. inject javascript that runs cryptomining in the background. The attacker earns some pennies, but your computer temperature and battery life starts to suck.
6. perhaps they get to inject a javascript sandbox escape - those are rare and not actively exploited at the moment but if your browser isn't up to date for some reason, then sooner or later another exploitable vulnerability will appear again in the wild.
In short, any http-only site is effectively potentially fully attacker-controlled for malware delivery, as much as websites can be used for malware delivery.
None of those attacks work unless you whitelist the site to run javascript, and if you are dumb enough to do that, those are all attacks you should be worried about the site itself deploying even if it is on https.
This would probably mean supporting both certificate observatories and trust-on-first-use, at the users discretion.
It's a bit weird that HTTPS-everywhere was initiated in the aftermath of the Snowden leaks. If your enemy is the CIA or NSA etc, HTTPS probably won't help you: They can compromise your CDN or simply go for your hoster directly.
However, there are many smaller and more common threats against HTTPS provides significant defense that wasn't there before. In particular manipulative ISPs or public WiFis or third parties who are logged into the same WiFi as you and are capturing traffic. (Remember Firesheep etc)
That being said, I also believe there are some significant downsides to the HTTPS push (and also DoH, eSNI and friends) that browser vendors refuse to address. In particular:
- It's a huge driver of "platformisation" of the web: To access an increasing amount of browser features, you now have to rely on third party services - at the very least, you need a domain. This is particularly problematic for hobbyist projects, local-only networks and home servers.
- It normalizes a situation where network traffic is treated as a black box. It's a good thing if my ISP or the cafe I'm working in can't inspect my packets - it's highly problematic if my company's admin has no idea what is going on inside the network or if I can't even inspect traffic from my own devices. I'm seriously wondering who is protecting against what here. This seems less for protecting users against snoopers and more for protecting tech companies against their own users - which is really the opposite of privacy.
Yeah, this is... troublesome, especially how fond software developers seem to be of telemetry these days. For software you haven't compiled yourself, that's completely opaque data leaving your network.
Especially in the light of how incredibly difficult it is to disable that telemetry collection in Firefox, it's not a great look for mozilla.
I don't know if this is the authoritative guide du jour, but the steps usually go something like this: https://gist.github.com/gamunu/7fbee4e2318fdc080395a7f74cc34...
I'm not sure this trust we're effectively being coerced to put in software and platforms is great from a privacy standpoint. But as you said, there has not been a lot of talk about this.
Well, actually, we have Siri, Alexa, Cortana and Google Assistant now, and the pitch is eerily familiar in many ways.
In addition here are a few notes that I collected using it, no criticism - just (hopefully) constructive feedback:
- The SSH (H not L) Observatory part seems to be broken for a long time (months at least). Not exactly sure what it was supposed to do anyway and how useful it would have been.
- I find the nomenclature for the Compatibility Level a bit unfortunate. As far as I understand, the highly secure and practically useful configurations recommended by Mozilla and elsewhere, all end up classified as Intermediate. The more desirable sounding Modern seems to be unachievable for any real world site. I'd love to see counterexamples if I'm wrong.
- It seems not to be very actively maintained since its main (and original?) author April King left Mozilla. About a half a year ago I filed an issue where the Observatory scan hung forever for certain sites [2], but apparently no one ever looked at it. (Maybe it is not an issue with the Observatory, but I think I wrote a decent report and hoped for some feedback).
[1] https://pokeinthe.io/2016/08/25/observatory-by-mozilla-a-new...
[2] https://github.com/mozilla/http-observatory-website/issues/2...
I'd agree that the description of "M" in https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende... is unrealistic for a site with a large and diverse audience, so far. The primary issue is that it requires turning off TLSv1.2.
Wikipedia is a good example of "about as Modern as you can get in the real world with a big global audience". It's a little stricter than "Intermediate", but doesn't quite meet the "Modern" description. The key items there are that Wikipedia still supports TLSv1.2 (but only with TLSv1.3-like ciphers) and it still supports dual cert compatibility (ECDSA+RSA). The RSA support is likely to be on chopping block Soon, as the only real use-case for RSA in this config is to support ancient installs of the last-known-good version of Chrome (49) on WinXP SP3, but Wikipedia will likely have to continue supporting TLSv1.2 for quite some time.
In any case, though, Wikipedia still gets an "M" rating in the check, so either the description is wrong or the check is buggy:
https://observatory.mozilla.org/analyze/en.wikipedia.org#tls
TLS 1.3 downgrade protection means that most downgrade attack avenues aren't viable. In earlier versions the downgrade protection was pretty flimsy so it's more of a worry that a server offering TLS 1.0 through TLS 1.2 could be vulnerable to downgrade and then a TLS 1.0-only attack works on clients that could have done TLS 1.2 but were downgraded. Nobody's halfway decent TLS 1.3 client will allow that, if you try to downgrade it, the client gives up instead. Denial of service was always possible, but downgrade needn't be.
Most of this is actual design work in TLS 1.3 but a fair amount is simply willpower from major clients like web browsers. Deciding that OK, if you insist on downgrading the protocol we would rather tell the user the site is inaccessible than allow that.
But I guess I wouldn’t use this tool on such a trivial site anyway.
I get 40⁄100, D⁺, because of this stuff, and I have not the slightest intention of changing it because I’m stubborn and know that I don’t need them. Well, it’s better than the 0⁄100 it gave me at the start of 2019, or the 20⁄100 back in 2016.
It needs some sort of profile system for the rankings, so that you can say “anything”, “static site”, “static site with no third-party resources”, that sort of thing, and in the lattermost case have it say “OK, then we’ll just suggest CSP, XCTO, XFO and XXP rather than screaming about them”.
wholly unrelated but I had no idea about the existence of U+2044 FRACTION SLASH!
-25 for not defending against Javascript attacks on my javascript free domain
-40 for not forcing HTTPS
-35 more for not protecting against non-existing javascript being manipulated
For most of the websites out there (that might want to accept user input, or ensure that the page content isn't manipulated or hijacked), that indeed would be a good recommendation.
What would prevent someone from adding a few <script> tags here and there with ads on your site, or code to spy on your users? ISPs have historically already abused this, here's just one example, though you can look up plenty more through your search engine of choice: https://stackoverflow.com/questions/30505416/eliminate-isp-i...
Personally, i really dislike that the web has come to this.
Nothing, probably. In a sane country and legal system doing things like that would be illegal. But on the other hand forcing HTTPS means that some users will never be able access it due to old browsers and/or hardware.
More likely though is that I mess up the HTTPS certificates, either by mistake or inaction, and lock out everyone who doesn't dare click the correct sequence of "ignore warning" buttons.
I've already managed to block access for normal users to several sites, several times, by running too old certbot versions, not integrating things properly and whatnot. It's a good thing I'll never use HSTS and HPKP, or I'll make permanent messes.
Always fun when you lock yourself out of your own website for several days.
It should, but it isn't always the case. Not only that, but even if it is technically illegal, it still might be done because of a lack of people who'll take the guilty parties to court over it. So, in reality, you cannot avoid viewing that as a well founded risk.
> But on the other hand forcing HTTPS means that some users will never be able access it due to old browsers and/or hardware.
In a similar argument about what "should" happen - Google shouldn't just abandon numerous Android devices out there, nor should any other vendor. There should be mechanisms in place to ensure that these devices continue to function for the decades to come.
But since that's not the case, it's inevitable that you'll cut off a small portion of your potential userbase, same as with many sites simply not functioning because the developers made the choice to require JS. Of course, that is your choice, unless other concerns (like security) force your hand.
> More likely though is that I mess up the HTTPS certificates, either by mistake or inaction, and lock out everyone who doesn't dare click the correct sequence of "ignore warning" buttons. I've already managed to block access for normal users to several sites, several times, by running too old certbot versions, not integrating things properly and whatnot. It's a good thing I'll never use HSTS and HPKP, or I'll make permanent messes.
I run a couple of sites through a .dev domain and i do agree with what you're saying, since locking yourself out sooner or later is inevitable, but in my eyes i'd treat it like any other problem out there, much like messing up exposing the correct firewall ports - fix the problem, set up monitoring to be alerted of any problems in the future and move on.
That's why having development/test/staging environments is really useful and in case you fear rate limits, Let's Encrypt also has a staging environment that you can use before switching over to prod: https://letsencrypt.org/docs/staging-environment/
Not only that, but there are a few web servers here and there that attempt to improve the situation with ensuring SSL/TLS, like Traefik. Personally, however, i've found Caddy to be the most painless, since with it i don't need to mess around with integrating certbot with Apache/Nginx, but instead can just use it, since it works out of the box for the most part: https://caddyserver.com/
Apart from that, you can always just expose a version without HTTPS on the server's ports locally, so that you can set up a tunnel through SSH and access it from your device in emergency situations (or just use a self signed certificate for the "private" version).
To be fair, I've done that on my personal site a few times too, and if HTTPS is broken, I consider the site broken (the same as being offline). It's time for fixing it, not for hacking around an HTTP version.
That said, I never cared about HSTS and CSP. Those headers are a joke. The correct way to force HTTPS and certificate verification is on the client, not as a hint by the server. Yeah, I will put them there if I ever bother to customize those webserver settings, there just isn't much of a reason either way.
I agree that HTTPS is more effective than CSP but HSTS addresses the problem of doing that without breaking the web: if you don't have a way for someone typing www.google.com into the browser's location bar or following an old bookmark, you're leaving millions of people vulnerable to potential MITM attacks on the local network. HSTS allows sites to opt-in after they verify everything is working so most traffic is protected long before every antiquated enterprise IT site is updated.
The CSP analysis section (and maybe some others) could use a bit of improvement. For example, currently you get the following output:
Clickjacking protection, using frame-ancestors
The use of CSP's <code>frame-ancestors</code> directive offers fine-grained control over who can frame your site.
Thankfully, the recommendation section does have some useful links apart from that! Not step by step guides, but still would lead you in the general direction of what you need.
Full disclosure, this is my project.
Some of the icon tests are bogus. I deliberately don’t put any <link rel=icon> on my site, but have a favicon.ico containing (among other sizes) 16×16 and 32×32. Your tool complains about meta tags for 16×16 and 32×32 not being found in the HTML. Well, they’re not, but they’re not necessary, because I haven’t put anything in place that would disrupt the favicon.ico fallback. 192×192: … why? Won’t things gladly scale that 512×512 you want down? Manifest and other large icon sizes: this stuff isn’t relevant to all sites. And that’s a problem with these sorts of tools in general, they give scores tuned to a single usage profile which simply isn’t suitable in all cases. As with HTTP Observatory’s XSS stuff commented about elsewhere in this thread. What we need for tools like this is profiles that twiddle rankings. Things like “personal content site” which changes manifest and Apple/Safari/large icons to optional. As it stands, the weighting of this extra stuff is way off base—I get given an F for that section, when I honestly think it should get at least an A, when operating under my hypothetical “personal content site” profile.
Test 48 is bogus, the <body> start tag is optional.
Test 111, wanting initial-scale on the viewport meta tag, I’ve been casually searching for someone to confirm what it actually does, and if it’s still needed. Most indications suggest it was basically a workaround for an ancient iOS Safari rotation bug, but I’ve come across at least one person stating (without detail) that it still did something. Any chance you have Apple stuff and can investigate more as to whether it’s actually still at all useful?
Test 33, DMARC record formatting, looks bogus.
If you know what you are doing, but all means feel free to disregard any tests that you don't agree with. The suggestions that Validbot makes are meant to be general purpose "best practices" to help web developers make sure they are paying attention to everything they should be. Sounds like you are and have made some good decisions.
- The section on FLOC is a bit inaccurate; I wrote about what the interest-cohort permis. policy does and doesn't do:
https://seirdy.one/2021/04/16/permissions-policy-floc-misinf...
- Safari now supports normal icons for pinned tabs. apple.com no longer uses a mask-icon.
- X-XSS-PROTECTION should be set to 0 (disable) according to OWASP's latest guidelines, since XSS filtering has been found to introduce new sec vulns:
https://owasp.org/www-project-secure-headers/#x-xss-protecti...
- Some implementations of HSTS and auto HTTPS upgrades mandate that HTTP-to-HTTPS redirects don't change the hostname, including the www prefix. If anything, this tool should recommend against a single redirect for HTTP->HTTPS upgrades and www subdomain prefixing/removal.
- Very, very few browsers do support X-Frame-Options but lack support for CSP; even fewer have a modern TLS stack that works with secure cipher suites. X-Frame-Options no longer should be needed since the CSP header fills its use case.
I'd recommend taking a look at some existing checkers for reference. Webbkoll, check-your-website.server-daten.de, Hardenize, Lighthouse, and Webhint.io are some good ones.
Idea was to run almost same set of checks as tab HTTP Observatory does using CLI I created: sailor. We decided to have it as CLI, for sake of simplicity of integrating it into CI & CD.
After I decided we won't be trying to build a business around it, I removed SaaS dependency and open-sourced it.
You can check it here: https://github.com/hidalgopl/sailor
https://observatory.mozilla.org/analyze/government.github.co...