Earlier 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…
Why Static Websites Need HTTPS
71–80 of 268 posts
Re: Why Static Websites Need HTTPS
#72How 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.
Self-signed certificate (or own CA and certificate signed by that). Buying a certificate for an IP is more expensive than a domain.
I'll try with my own CA.
Re: Why Static Websites Need HTTPS
#73Earlier quoted context omitted.
You can set up your apache/nginx or whatever webserver to redirect http requests to https. That way you can still link to your website with an http:// URL.
Appreciated, but this is a hacky solution. If you use the graph explorer, both the http and https addresses have different counts. It's very frustrating - shouldn't be that way.
Re: Why Static Websites Need HTTPS
#74I want to go one further: WHY does a regular user need to buy a human-readable domain name, maintain it, and pay for a hosting company to host on that domain?
It used to be worse - you had to have your own machine or use some crappy shared hosting service. Amazon figured out that letting people share managed virtual machine instances was good savings. That’s now called “the cloud” but it’s still under the control of some landlord - Amazon, DigitalOcean, etc.
Let’s face it, the easiest thing we have today is some web based control panel by CPanel running on some host that charges $5/month or something.
It’s 2018. Why don’t we have something like MaidSAFE and Dat working yet? We should have:
1) End to end encryption
2) One giant, actually decentralized cloud composed of all nodes running the software
3) Storing chunks of encrypted data using Kademlia DHT or similar
4) Maybe even periodic churn on the back-end so you can’d find and collude with the servers hosting the chunks
5) All underlying URLs would be non-human-readable and clients would display (possibly outdated) metadata like an icon and title (this metadata may change on the Web anyway). Storing and sharing could occur using QR codes, NFC bluetooth, Javascript variables, or anything else. For static files, the links could be content-addressable.
6) All apps and data would be stored encrypted in the cloud and only decrypted at the edges. They would run on the clients only. Apps could also be distributed outside the cloud, but usually just via a link to a cloud URL.
7) Communities would likewise be just regular users, rather than private enterprises running on privileged servers running some software like github is now. No more server side SaaS selling your data or epic hacks and breaches.
8) Users would have private/public key pairs to auth with each community or friend. They would verify those relationships on side channels for extra security if needed (eg meet in person or deliver a code over SMS or phone). Identity and friend discovery across domains would be totally up to the user.
9) Private keys would never leave devices and encryption keys would be rotated if a device is reported stolen by M of N of other devices.
10) Push notifications would be done by shifting nodes at the edges, rather than by a centralized service like Apple or Google. In exchange for convenience, they can expose a user to surveillance and timing attacks.
No more waiting endlessly to be “online” in order to work in a SaaS document. The default for most apps is to work offline and sync with others later.No central authorities, CAs or any crap like that. Everything is peer to peer. The only “downside” is the inability to type in a URL. Instead, you can use one or more indexes (read: search engines) some of which will let you type existing URLs, or something far more user friendly than that, to get to resources.
Domains and encryption key generation would be so cheap that anyone can have a domain for a community of any kind, or even just for collaborating on a document.
There won’t any longer be a NEED for coupling domains to specific hardware somewhere, and third party private ownership/stewardship of user-submitted content would be far less of a foregone conclusion, fixing the power imbalance we have with the feudal lords on the Internet today.
Once built, this can easily support any applications from cryptocurrency to any group activities, media, resources etc.
If you are intrigued by this architecture, and want to learn more or possibly get involved, contact greg+qbix followed by @ qbix.com - we are BUILDING IT!
Re: Why Static Websites Need HTTPS
#75Here'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…
Re: Why Static Websites Need HTTPS
#76When 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…
My landlord sent a handyman in while I was on vacation once, and the handyman didn't close the front door all the way (or try to lock it). My door was open for 3 days, visible from the street, and I don't live in the nice side of town. No one stole the TV, but my electric bill was high that month.
A MITM attack on a static site is definitely possible, maybe even easy, but I'm not going to worry about it unless I have something important to protect.
Re: Why Static Websites Need HTTPS
#77Earlier quoted context omitted.
Appreciated, but this is a hacky solution. If you use the graph explorer, both the http and https addresses have different counts. It's very frustrating - shouldn't be that way.
Add your site to the HSTS Preload List, then it'll be very unlikely to have any HTTP hits.
But again, it's not exactly up there for John Everyman - and it doesn't sort Facebook having different share counts for the https and http domain.
Re: Why Static Websites Need HTTPS
#78Earlier quoted context omitted.
Add your site to the HSTS Preload List, then it'll be very unlikely to have any HTTP hits.
Didn't realise that existed. Very useful thanks! But again, it's not exactly up there for John Everyman - and it doesn't sort Facebook having different share counts for the https and http domain.
Re: Why Static Websites Need HTTPS
#79And one reason it doesn't: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... Secure websites make the web less accessible for those who rely on metered satellite internet (and I'm sure plenty of other cases). Know who your demographic is and make sure you don't make things more difficult for them. Maybe provide an option for users to access your static site on a separate insecure domain, clearly labeled…
Now, upgrading satellites is trickier and more expensive than upgrading your home cable box, at the extreme obviously sending a bloke up to "swap out this board for a newer one" is either tremendously difficult or outright impossible depending on the orbital characteristics. But we shouldn't act as though high packet loss rates at the IP layer are to be expected, they are avoidable. And fixing them will do a lot more than just enable HTTPS to work better.
Re: Why Static Websites Need HTTPS
#80There is no doubt that this change is designed to take power away from some entities and to put it in the hands of a few key players which Google trusts.
Also, the video created by the author is highly deceptive; the author makes it look like he has hacked the website itself; in reality, he has only intercepted the traffic to his own machine so in reality he has only modified his own view of the website; he hasn't actually hacked anything. I'm sure that the author is being intentionally deceptive; he knows exactly who the target audience for that video is and he knows exactly what it looks like.