The recommendation of Cloudflare here seems poor. Using CF to make an HTTP only site support HTTPS will only prevent MITM between CF and the end user. MITM between my server and CF is not improved as it's still HTTP. Yes, you can add a self signed cert and tell CF not to check the cert validity, but that doesn't prevent MITM.<p>Worse, Cloudflare can inject JavaScript into your site. The default settings will show Captchas to users if CF thinks they are not trustworthy. So you end up with MITM anyway if you aren't careful. For a static site, does a captcha really make sense? Cloudflare makes the internet worse with insane defaults like this.<p><a href="https://community.cloudflare.com/t/getting-cloudflare-captchas-every-website-i-visit/9277" rel="nofollow">https://community.cloudflare.com/t/getting-cloudflare-captch...</a>
<a href="https://www.techrez.com/remove-cloudflare-challange-page/" rel="nofollow">https://www.techrez.com/remove-cloudflare-challange-page/</a>
I was disappointed the article is so thin on real substance. It could have listed out the reasons to always use HTTPS. Easily done:<p>1. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [0]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [1].<p>2. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs (this really has happened [2])<p>3. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad.<p>4. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though.<p>5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons:<p>* Reduced admin overhead not having to bother with certs<p>* It enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3]<p>* Better support for very old devices, such as old smartphones in the developing world<p>[0] <a href="https://www.theguardian.com/us-news/2016/jan/13/us-library-r.." rel="nofollow">https://www.theguardian.com/us-news/2016/jan/13/us-library-r...</a>.<p>[1] <a href="https://arstechnica.com/information-technology/2015/04/it-wa.." rel="nofollow">https://arstechnica.com/information-technology/2015/04/it-wa...</a>.<p>[2] <a href="https://doesmysiteneedhttps.com/" rel="nofollow">https://doesmysiteneedhttps.com/</a><p>[3] <a href="https://whydoesaptnotusehttps.com/" rel="nofollow">https://whydoesaptnotusehttps.com/</a><p>(Taken from an old comment of mine at <a href="https://news.ycombinator.com/item?id=21912817" rel="nofollow">https://news.ycombinator.com/item?id=21912817</a> )<p><i>Edit: Added the third reason not to use HTTPS</i>
The exchange between Troy Hunt and Jacob Baytelman is a little aggravating for me--they appear to be talking past each other.<p>Jacob challenges him to "hack [his] static blog". I don't know what 'hacking a website' means to him, but to you and me it probably means compromising the web server, which is not directly related to HTTPS (although I can think of a lot of ways that the use of HTTP could lead to a web server being compromised).<p>Troy responds by taking him up on this challenge, accuses Jacob of thinking that his site is immune from transport layer risks, and then performs a man in the middle attack on himself using Jacob's site (when in reality literally any HTTP site could have been used).<p>It's like these two are having completely separate conversations.
The first time I saw a mobile/prepaid ISP inject their notices on my own personal website, I realize I needed to get off my lazy ass and setup LetsEncrypt.
CITM - detected Corporations In The Middle (CITM) attack. requests blocked 15%, cdn.example.com dnjs.cloudyfaire.com troymcclure.disqus.com fonts.noodleapis.com fonts.noodlestatic.com platform.example.com noodletube.com example.com<p>https is easy. point everything DNS everything to cloudyfiare and click Purchase and by clicking Purchase agree to all the terms (but don't actually read any of them.) hand over root access to a program with the word bot in it, and allow it to update itself automatically (what could possibly go wrong.) Everything HTTPS all the time. <a href="https://en.wikipedia.org/wiki/DigiNotar" rel="nofollow">https://en.wikipedia.org/wiki/DigiNotar</a><p>call me skeptical, or the many ( <a href="https://slate.com/technology/2020/01/what-to-know-about-the-controversy-over-the-sale-of-org.html" rel="nofollow">https://slate.com/technology/2020/01/what-to-know-about-the-...</a> <a href="https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/" rel="nofollow">https://www.zdnet.com/article/kazakhstan-government-is-now-i...</a> <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticism" rel="nofollow">https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticism</a> ) many reasons Why My Static Website No Longer Exists.
Devil's advocate: HTTPS centralizes the web around big players. The CA trust model gives a privileged few the right to say what websites are "secure", even in cases where no user input goes down the wire. "Not Secure" in the top left brands and shames amateurs. <i>Come on, just make a Medium page! You should be posting this on a FAANG property!</i> Let's Encrypt is great, but don't forget that it could disappear overnight--after every browser started de facto blocking non-HTTPS traffic.
> HTTPS Is Easy<p>It is not easy at all. Getting a certificate and putting it into the conf is. Maintaining that certificate, applying the ever growing number of "security" headers, dealing with broken stapling, is anything, but easy.
Back in early 2009, I was launching a file storage web service similar to Dropbox (without the client, but with an API with OAuth 1 support) using AWS Ec2 and S3. I planned to use HTTPS, but it was expensive for me (as a college dropout), and the website is still online without it. I abandoned the project afterward. Recently, I started to migrate it from AWS to Google Cloud Platform, and one of the goals was to add HTTPS to it. However, I haven't had much time to finish the migration, and it's still not being served as HTTPS (even though it has all other sorts of protection that were the norm back then). I wonder how many other "legacy websites" have a similar issue (which I don't find justifiable for anything 'in production').
This article is two years old - think it’s been well established that sites need https, if for no other reason then browsers and search engines punish you in a variety of ways for not having it. Certificates are free with let’s encrypt so there is no excuse not to anymore.<p>In the case of Cloudflare (or any CDN) best practice is to reject requests not from the CDN. Cloudflare doesn’t support AWS S3 compatible storage directly - it won’t make signed requests - but you can write IAM policy that only responds to certain IP.
> In one of many robust internet debates (as is prone to happen on Twitter)<p>Maybe I just don't get Twitter. Every time I look at a thread it starts with some coherent conversation, but then devolves into a bunch of tangents that don't coherently follow each other.<p>HN and similar seem much better suited.
I’m stuck in a related situation: I own a website with heavy traffic that contains inline iframes to some http pages (about 30% of pages) hosted by third parties.
I can’t turn https on for my website, otherwise these iframes would be blocked by the browser.
Since I don’t offer https, it means that I can’t offer features such as login/sign up etc..
Any ideas?
HTTPS is bad:<p>- It wastes resources.<p>- It adds complexity.<p>- You can solve everything HTTPS solves over HTTP!<p>- It encourages passive destructive behavior.<p>- Troy Hunt probably has money coming in from certificates somehow.<p>HTTP/2 and HTTP/3 are also bad.<p>WebSockets are bad.<p>As a side note:<p>Vulkan is bad.<p>HDMI is bad.<p>Wakeup people. Time to get off that over-engineering couch and downvote the guy telling the truth again!
Discussed at the time: <a href="https://news.ycombinator.com/item?id=17857975" rel="nofollow">https://news.ycombinator.com/item?id=17857975</a>
Yes, add HTTPS, but keep the option for mere HTTP, because backwards compatibility is good.<p>Many parts of the world can't deal with TLS1.3 HTTP/2 websites only.
To prevent <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack" rel="nofollow">https://en.wikipedia.org/wiki/Man-in-the-middle_attack</a>
There are almost no arguments given, but all the other ones are nicely rebutted on n-gate:<p><a href="http://webcache.googleusercontent.com/search?q=cache:hV6m26a8hrAJ:n-gate.com/software/2017/" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:hV6m26a...</a>
Without HTTPS, Russians could MITM my knitting blog any minute now!<p>Indefinitely babysitting letsencrypt is a small price to pay to keep those grannies safe!
The problem with these calls for HTTPS is that those doing it believe http and https are mutually exclusive. They completly turn off human navigable webservers and leave only the machine navigable ones online. It makes the web only accessible to computer software written in the last 5 years.<p>There are plenty, I'd say most, websites which do <i>not</i> need HTTPS. And my static website does not <i>need</i> https. It's nice, sure, but it's a personal website and there's no money or personal information involved. Leaving an HTTP version going alongside the HTTPS and Tor hidden service is just fine.<p>The greater evil is having people run third party code by default on every website from every random domain that's called. Now that's insecure. It's like opening every email attachment you get. Every single "danger" of HTTP he lists is actually a danger of running third party code blindly and automatically.