What if your website is only accessible for you from within your LAN? Such as your router, LAN, or your settopbox? If you have DHCP as well and don't control the DNS or don't have root (such as on IoT devices) then you cannot use Lets Encrypt. Or am I missing something?
Why Static Websites Need HTTPS
51–60 of 268 posts
Re: Why Static Websites Need HTTPS
#52There is one static webpage that I won't put HTTPS on; the dashboard of my pi.hole.
Though it's more of an architectural decision as it enables the DNS server to blackhole HTTPS more effectively (since it just gets a CONNREFUSED back).
Really, it's an exception to the rule and only because I can't ask my guests to install my pihole CA on their devices (many of which don't support that stuff anyway).
Well and there is that other website but the prime directive forbids that I mention it...
Re: Why Static Websites Need HTTPS
#53Earlier quoted context omitted.
I may be misunderstanding but I don't believe the Same-origin policy will protect you there. You're browser wouldn't be able to tell whether the JS it's reading is the real one or the modified one. So it would be all "same origin" for it. It won't stop a modified code from pushing data to anywhere in the web either. > More fortunately still the application is a diff tool, so it can perform self validation Yes, if the…
Also if the attack did take place at the router then HTTPS certainly is irrelevant regardless of what the browser is doing. HTTP and HTTPS ride over TCP. If you can modify code at the router then you can change the TCP packets to spoof the page address or HTTP response and sidestep HTTPS or the requested domain entirely. https://en.wikipedia.org/wiki/Transport_Layer_Security Simply modify the TCP connection in transi…
It's far more common for this to happen beyond the router. A few years ago there was a spate of ISPs injecting ads onto sites they don't control, because HTTP doesn't prevent them from doing so. HTTPS does.
Re: Why Static Websites Need HTTPS
#54Here's the truth about security: people are clueless about it and so corporations and governments abuse that by pushing their own agendas, not related to security.
Same corporations that tell you to "secure" your unimportant static website with https also want to force you to run random javascript in your browser from unknown parties, identify you at all times, link everything to your phone number, etc. In the end we are all going to be worse off with this let's encrypted web, with more control than ever in the hands of those few US corporations.
Re: Why Static Websites Need HTTPS
#55When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…
wait, what? if you can get nginx running you can get lets encrypt running
Re: Why Static Websites Need HTTPS
#56Earlier quoted context omitted.
A form submission would refresh the page to the evil domain. It would change the domain in the address of the page. This same vector of attack can still occur with HTTPS so long as the malicious code is injected from a XSS or CRSF attack. The page address is the web's equivalent of physical security. If you cannot trust that there is no security.
Put it in an iframe, then. No URL change, no page change. In any case, once the page has changed the URL visible to the user it's already too late. Their data is sent. I guess it's nice that they are informed that something happened but not really. And that unknown server could easily redirect the user straight back to the site they were on, so the user would only see a flash on their screen.
And even more stealthily, an iframe with display: none.
Re: Why Static Websites Need HTTPS
#57When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…
https://www.usenix.org/system/files/conference/usenixsecurit...
A big part of the problem here is that vendors do a _lousy_ job of making this easy. An out-of-box Apache is a fairly good HTTP server, but it'll take you an hour with a good tutorial to make it a half-way decent HTTPS server. Not because HTTPS is inherently difficult but because no relevant expertise was brought to bear in Apache's implementation.
And this isn't just a Unix flavour problem, the IIS handling of TLS is garbage too. Microsoft has documentation that's incomplete or flat wrong, and then you're expected to muddle along following blog posts and video tutorials.
There's a LOT of cargo culting in this space. Almost every instance of the name "Middlesex" you see in an X.509 certificate is a result of this sort of cargo culting, because the postal county of Middlesex ceased to exist before X.509 was even created, but it looks superficially as though you need to specify a "county" in X.509 and so people based in London dredged up Middlesex. And it didn't _break_ anything so they kept doing it without knowing why.
Re: Why Static Websites Need HTTPS
#58How can I go about securing a server without a domain? Just a static IP? Let's Encrypt doesn't allow IPs and the owner doesn't care for a domain.
Context: small business with a web based application in a local server, all they need is to be able to access reports from their phone.
Re: Why Static Websites Need HTTPS
#59Earlier quoted context omitted.
> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. I would argue this model of application is substantially m…
No. https://en.wikipedia.org/wiki/Same-origin_policy
SOP has the security properties of a piece of wet cardboard. That is, most attackers will refrain because punching wet cardboard gets them wet and covered in slimy cardboard, some will punch it extra hard for the same reasons.
Re: Why Static Websites Need HTTPS
#60When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…
The other side I would pose is: do you want anyone to alter your responses? I'm currently trying to find the RFC, but I recall an ISP defining an RFC for tampering with HTTP responses in-transit. In addition, I also recall seeing Comcast (I believe) injecting JS to users that they are approaching their plan limits.
Obviously, not the end of the world. But do you want any third party to easily alter the response from your server to the client(s)?