The real threat in this case was that sending the right string of data to a browser let a malicious actor execute a RCE and install malware. Either you trust the browser to be secure against such attacks or you can't trust much of anything.
This seems a lot more complicated than just going to any unencrypted website via network redirection of some sort. Do most people routinely visit encrypted sites that are easily hacked to target an RCE on an individual?
If someone were to be "secure enough" to be running drugs/guns/children - they'd _have_ to be totally disconnected from the internet and cellular networks, and probably all their first and second level associates as well.
I don't have any sympathy for those people, but sadly a journalist critical of a government has all the same problems there, and that's bad for humanity.
I've heard several times that this is largely driven by the crappier flavors of "media platform" and bottom-of-the-barrel ad networks breaking in spectacular fashion due to CORS and mixed-content problems when the main site tries to switch to HTTPS.
I don't doubt there are some bespoke ad servers or other dark corners of ad infrastructure where HTTPS support is still lacking, but that should be rare at this point.
That said,we still have to scan every creative for https compliance because a lot of them say they are but aren't.
What's 'creative' when it's a noun? A producer of 'content'?
edit- I do not have javascript-driven pages, they are PDFs or simple content
There are easily found examples of malicious content being injected into HTML -- malvertisements for example. I can only imagine what might get injected into a PDF which can run javascript [1]. PDF readers aren't exactly known for their security.
Frankly, I'd much rather be able to talk to you about something downloaded from your site and get you to fix it instead of allowing a third party to infect me and point fingers at you.
But I'm saying that what you're serving and what the user receives can be different. When you're using plain unencrypted HTTP then anyone between you and the user can inject javascript into the PDF. The user can get a PDF file with javascript in it even though you didn't put any javascript in it.
> Some hacker-wannabe that sets up a honey pot is going to be thwarted by HTTPS. But if we don't connect to shady hot spots HTTPS doesn't seem to provide that much protection.
Pinned HTTPS certificates provide a good degree of resistance to MITM attacks, and without installing local certificates on the device under attack HTTPS itself stops MITM attacks.
> It runs into the problem of anyone that can MITM via your ISP or home router probably has the resources to also find an exploit around HTTPS.
This is absolutely not the case. Home/work routers are often monitored by suspicious spouses, annoying housemates or intrusive companies. It's very rare that one of these has the resources to develop their own exploits against HTTPS.
I didn't say against, I said around. And your hypotheticals are good examples of that. If we are giving our bad actor physical access to devices in the house there are a lot easier/more effective attacks than a MITM on the router. Keyloggers, spy software, webcams, etc. are simpler and more effective tools. If they're sophisticated enough to do a believable MITM attack they can do all these other attacks as well.
This isn't true. All of these attacks are pretty hard to run against mobile devices unless you can install something on them.
> a believable MITM attack
This makes me think you don't actually know what a MITM attack is. MITM attacks are dangerous because they are invisible - ie, "believable" is implied by it being a MITM attack.
certbot is too hard to set up?
>edit- I do not have javascript-driven pages, they are PDFs or simple content
The issue is that if the http protocol can be tampered with, even if all you serve is plain text, the attacker can change your response to contain javascript. Anyone visiting using a browser (with scripts enabled) will be vulnerable.
You should see the list of root certificate shipped with most major browsers.
I did a quick manual count of yesterday's HN front page articles according to hckrnews.com and found 8 non-https links (vs. 109 total non-dead links). 2 of these have a working https version.
I use the HTTPS Everywhere extension set to the new "Encrypt All Sites Eligible" option. Instead of using a list as previous HTTPS Everywhere, this tries to access all websites via https and pops up a warning if it doesn't work (most of the time; one of the six non-https supporting sites was misconfigured in a way that didn't get the popup). Since I want to know anytime I access an http site, I choose the "open insecure page for this session only" option if I want to look at an http page to make sure that it tries the https site again in the future and that I know any time I am visiting an http site. There are simpler extension that just do that, but unfortunately they are not Firefox Recommended extensions that are monitored by Mozilla. Hopefully it won't be too long before browsers do this themselves.
The main root cause for missing https in HN submissions is old github pages before 2016.
GitHub rolled HTTPS but didn't enable it by default for older sites. Gotta go to settings and tick https.
In fact you can program almost any device (including very old and simple) to be a plain old HTTP client or a server but this is not the case with modern HTTPS.
But if your threat model includes nation states then LetsEncrypt should only be one part of your defense in depth strategy.
Besides, delivering vulnerability payload via advertising network is far more reliable — with http-only exploit chain police would have to wait and hope that Omar will someday visit an http-only site. I would expect a pricey exploit toolkit, used by governments, to be more robust than that.
LE is still tedious as heck to set up on your own, though, so I guess people who haven't migrated to modern hosting yet are still being left behind. Most hosting-for-devs platforms these days give you HTTPS by default and don't think would even let you host a website without.
January 31 of this year I got an email telling me that my LE client used the older ACMEv1 protocol, not the newer ACMEv2 protocol. They gave me 4 months notice to update my LE client to something compliant. I burnt the time and did the work.
On March 3 myself and many others[0] got an email demanding that we manually re-issue our certificates because of a vulnerability discovered in the LE service. They gave us one day to comply, after that they would revoke the certificates and our users would receive security errors. I begrudgingly went through all my servers and issued the command to forcibly renew certificates. Not a huge burden for me, but likely a bigger burden for larger operations.
As the feature set grows (new challenge types, wildcard support, etc.) and the service gets even more popular, it's going to be an even bigger target and the effects of a monoculture will really be felt. I'm starting to see the value in paying for certificates, and more specifically, using providers that don't provide a public certificate issuance API (or at least stick it behind a paywall.)
How many times would LE have to accidentally issue gstatic.com or fbcdn.net before they get the Symantec treatment[1]? Too big to fail: It's not just for investment banks. And that should give anyone seeking a decentralized internet pause.
[0]: https://www.zdnet.com/article/lets-encrypt-to-revoke-3-milli...
[1]: https://www.zdnet.com/article/mozilla-warns-it-plans-to-dist...
It took me maybe 10 minutes to set up for my nginx setup. Debian and OpenSUSE both package letsencrypt's certbot. Tedious to set up and maintain is essentially the opposite of my experience.
I agree that some problems are unfortunate. But let's contrast for a moment. LetsEncrypt has demonstrated track record of quickly fixing issues. Symantec has a demonstrated track record of hiding issues instead of fixing them.
It's wise to consider options carefully. LetsEncrypt isn't the be-all end-all service for TLS and your needs might not be compatible. But I don't think it's fair to shove LetsEncrypt aside just because it's had its share of problems.
For a free service it's pretty damn reputable.
Let's Encrypt has lowered the bar, but it's still a bar that needs to be overcome.
In particular a current Certbot (or similar software from other developers) will conclude that it should try to replace a certificate which has been revoked and not only certificates that will shortly expire. So if a similar event happened, and you missed the email, your Certbot will treat the certificates much as if they'd expired and replace them automatically.
Also if you didn't replace a revoked certificate the thing is: Online revocation is broken. Most of your users will not have noticed your certificate was revoked. Popular browsers do have an out-of-band way to enforce revocation but they didn't use it on that Let's Encrypt incident because they felt it was low risk. So maybe some people are running Internet Explorer (really?) or have explicitly turned on revocation, everybody else doesn't even see a warning page.
Our concern with Symantec was inadequate oversight.
This is not some clumsy "Three strikes and you're out" rule. Symantec did not have the culture needed to do the job properly and we had no confidence that their management was capable of instilling such a culture.
If you're American or just follow American events somewhat you may have seen the "One rotten apple" argument being pulled apart in respect of problems with their police. Symantec used this argument, asserting on two occasions that their policies were fine but an employee had fallen short and this employee was terminated so now everything is fine. I am not sure I believe them but it doesn't matter because:
That is not good enough. We need public CAs to design procedures so that merely incompetent or lazy employees cannot sabotage things. Because individual humans are by their nature incompetent and lazy, such problems are to be expected and must be allowed for in your processes.
The big incident that blew up for Symantec was Crosscert. Symantec had not explicitly disclosed that the Crosscert relationship existed. In fact even if you read their paperwork closely (as we did after the incident) they actually simply did not disclose key facts about the relationship to anyone, not to their users, not to relying parties (ie you and me), and not to their independent auditor. Perhaps not even to their own board of directors (of course maybe private documents available to the board had such a disclosure).
It is likely that in practice Symantec as a corporation was unaware of what Crosscert were doing. Even if one or two Symantec employees had a good idea, the organisation as a whole was ignorant. As a result there was in practice no oversight over this entirely separate entity in a foreign country issuing certificates!
We concluded that building confidence in a new management of new infrastructure would take several years and that was the minimum we could allow. At first Symantec decided to fight this at the executive level, which of course only made us more confident that we'd been correct not to have confidence in them. When that failed (my impression is that trying to bully Google senior management isn't a good strategy) they settled upon a plan of selling their CA business instead.
So all that's a long way from Let's Encrypt accidentally mis-issuing a certificate from their own systems to bad guys.
Here's what I recently did when I deployed a new site [0]:
{dnf,yum,apt-get,whatever} install -y certbot
certbot certonly --webroot -w /srv/_default -d systemd.software -d www.systemd.software
Then just point an nginx configuration file to the two [1] and tell nginx to test and reload its configuration.
cp nginx.conf /etc/nginx/default.d/systemd.software.nginx.conf
nginx -t && nginx -s reload
systemctl start certbot-renew.service
That's it! I'm not sure what you think is tedious about that process. Would you care to elaborate?
[0] https://systemd.software/index.html
[1] https://github.com/inetknght/systemd.software/blob/44c584c68...
[2] https://knightoftheinter.net/img/LetsEncrypt_Expiration_Warn...
caddy file-server --domain example.com
Or my other 1 liner cron job that runs certbot for other demos.
If the web server is compromised, then it’ll inject the malicious JavaScript code into the HTML, and transmit that to you. SSL is irrelevant in this regards.
Unless when not using SSL, then the HTML is getting intercepted in flight, and a malicious JavaScript code is injected into the HTML.
Is that more of what we are now seeing these days? The routers are compromised, and the HTML is getting compromised too.
This is a legitimate question.
Granted, I’m fully in support of SSL. Nobody should be seeing what you are browsing. This leaves too much digital breadcrumbs lying around.
It significantly helps to prevent MITM [1] (Man-in-the-middle) attacks. (without scary certificate warnings anyways)
>If the web server is compromised, then it’ll inject the malicious JavaScript code into the HTML, and transmit that to you. SSL is irrelevant in this regards.
The web server isn't compromised in this case, presumably the network is compromised.
>Unless when not using SSL, then the HTML is getting intercepted in flight, and a malicious JavaScript code is injected into the HTML.
Yes.
>Is that more of what we are now seeing these days? The routers are compromised, and the HTML is getting compromised too.
"Stingray" devices [2] spoof mobile towers so cellphones are tricked into believing they're connecting to "Just another cell phone tower" and at that point traffic can be captured/modified.
>Granted, I’m fully in support of SSL. Nobody should be seeing what you are browsing.
It's more than people just knowing what you're browsing (or issues such as leaking passwords/private info), it's that if someone can MITM you, they can also transparently modify unencrypted data (including adding exploits).
I suspected MITM is now technically feasible. Although I wasn’t quite sure how widespread it was.
The stingray is indeed worrying. And it’s been around for nearly 20 years now.
So everyone with a cell phone, or using WiFi over a cellular hotspot, can now get caught up in a MITM exploitation attack, if they browse a non-https website.
When will the network providers now issue a blanket ban on browsing over plain http?
Always on VPN on the phone beats this, imho.
But you can establish a point-to-point secured connection tunnel with the VPN.
Then the VPN goes to the non-SSL website, and gets the html in plain text.
But, if there are compromised routers between the VPN and the website, then you can still be MITM attacked.
Hmm.. a determined foe can still checkmate you, for visiting a non-SSL website, even over VPN.
If the insecure website itself is in Morocco then he's hosed either way, whether the website is behind SSL or not.