Why Static Websites Need HTTPS

https://www.troyhunt.com/heres-why-your-static-website-needs-https/

by edward • 8 years ago

328 253 8 years ago

I have recently adopted HTTPS on my own site, because there are substantial performance benefits with HTTP/2 that are only available over HTTPS.

There are many arguments in the article, and more that he links to, arguing for the security benefits of HTTPS. HTTPS is good for protecting content.

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 more secure that sending data across the wire regardless of whether that transmission is encrypted. There is nothing individually identifiable or preferential about the application code. The content, identifiable information, and personal/private details remain with the user where they reside anyways.

---

EDIT

Before everybody jumps on the MITM attack bandwagon be aware of https://en.wikipedia.org/wiki/Same-origin_policy

A man in the middle attack can void the integrity of data crossing the wire, but it cannot trivially break privacy with simple modifications to code. This is by design in the architecture of the web.

The only violation in question is code integrity (availability portion of the security CIA triad). Fortunately, this is a solved problem so long as the application is open source. If an integrity violation occurs that renders the application defective simply compare the transmitted application code against the stored publicly available application code. This is made easier when the application in question is a diff tool that can fetch code from across the wire.

skuzye2• 8 years ago

If you don't use HTTPS you are also forgoing the integrity check and not only the encryption. Any router standing between your users and your servers could inject anything into your code, html, etc.

austincheney32• 8 years ago

There is the possibility of corrupting the integrity of the application code in this way, but this doesn't void privacy thanks to the same origin policy. https://en.wikipedia.org/wiki/Same-origin_policy

If integrity of the application is violated the application is broken or defective. Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application is a diff tool, so it can perform self validation across the wire by comparing the transmitted application code against the stored application code.

tialaramex7• 8 years ago

There's a corner case where, surprisingly, your parent's point kinda works, SRI:

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

If a site exists just to host resources protected with SRI then you can in principle use HTTP, the resource integrity protection will fire and so long as the main page's origin was genuine (e.g. protected with HTTPS) you come out OK...

But SRI isn't even implemented at all in Safari or IE. So, there's a good chance if you have Mac or Windows users they're screwed.

This really is a corner case, even if some day Safari and IE get SRI, you should always just use HTTPS to actually protect resources in flight. The purpose of SRI is more around not fully trusting a sub-resource you've intentionally linked not to be changed.

jsjohnst3• 8 years ago

The only thing that crosses the wire is a request for the application code and a response with that code.

If someone man-in-the-middled the downloading of the app code (trivial, if not HTTPS), then none of those constraints you later mention would be true and the user’s data is now compromised.

austincheney32• 8 years ago

In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed.

If you can break same origin policy submit a bug to Google. That would be a significant defect that would warrant their top tier bug bounty.

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

gsnedders5• 8 years ago

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 more secure that sending data across the wire regardless of whether that transmission is encrypted.

That's a case where HTTPS really is essential! If you serve your application code over HTTP, then I can MiTM that connection and replace your application code with something that reads all the user data from the user's browser and then sends it to evil.com.

austincheney32• 8 years ago

No. https://en.wikipedia.org/wiki/Same-origin_policy

syn0byte• 8 years ago

You can implement authentication without encryption.

Also, who says that HTTP content is always plaintext?

austincheney32• 8 years ago

and then sends it to evil.com.

How would a man in the middle attack grant you that? This is the reason same origin policy exists. It is the foundation of web security. If can break SOP and prove it in a demonstration you can report this issue to Google as a defect in the top tier of their bug bounty for a sizable reward.

askmike• 8 years ago

My site is a web application that stores all user data in their browser. Their data does not come back to the server.

If you weren't using HTTPS a very simple MitM attack would send all of that data straight to any server. HTTPS doesn't just prevent intercepting AJAX communications, it prevents anyone from changing your webapp (js file) into something that uploads everything to evilcorp.com.

austincheney32• 8 years ago

No. https://en.wikipedia.org/wiki/Same-origin_policy

dragonwriter6• 8 years ago

One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate.

If there is no content, you have no site, so the issue is moot.

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.

The application is content, and the thing you need HTTPS to protect. Otherwise, the application the user actually runs could be anything an attacker wants.

I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted.

It's not, because the code you send controls what happens with the data.

A man in the middle attack can void the integrity of data crossing the wire, but it cannot trivially break privacy with simple modifications to code.

It can, because in an MITM the attacker impersonates your site. The therefore can bypass any protection offered the same origin policy, because they own your origin.

austincheney32• 8 years ago

if there is no content, you have no site, so the issue is moot.

That isn’t true either as TLS protects http headers in addition to the http body.

Modification of requested content does not void the same origin policy. Just because you could modify page content does not mean you could transmit that content to an alternate location.

dvfjsdhgfv• 8 years ago

Well, the Same origin policy may protect the users a bit if the attack takes place after they've downloaded the app, but if they haven't - the attacker can modify it and they won't even notice.

some_account• 8 years ago

Why wouldn't you? It took me 30 mins to read and set up a cert from let's encrypt.

gt22• 8 years ago

Don't underestimate the weight of decisions, let alone the knowledge of a choice, and the care.

Also, see how often humans don't change from default settings -- ringtones, bootstrap themes, etc..

gt22• 8 years ago

A big reason is that Chrome (and others?) specifically show 'Not Secure' for all sites not using https.

H1Supreme• 8 years ago

This is a massive reason, imo. The average user views that url annotation as a bad thing. They don't know it's static, or even what "static" refers to.

AgentME8• 8 years ago

Even if they knew the site was static, "not secure" would still be valid. An ISP or malicious wifi network may be recording their browsing history, downsampling images, injecting or replacing ads, replacing executables with backdoored versions, adding fake login forms or popups to get the user to give a password of theirs, etc.

adwhit2• 8 years ago

When 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 how Let's Encrypt works).

[1] https://www.nspw.org/2009/proceedings/2009/nspw2009-herley.p...

tudelo• 8 years ago

Pretty sure you can use certbot and just run like... a few commands. Even easier than setting up Nginx.

adwhit2• 8 years ago

The point isn't that it is particularly difficult (if you know what you are doing). The point is that from a cost-benefit perspective, it probably isn't worth more than 2 minutes of your time, if that.

hrktb• 8 years ago

It's true that certbox is very easy to install and single run on stable machines with full command line access. Then a lot of Paas providers pre-package a let's encrypt feature to allow for simple setup of SSL cert (as simple as checking a checkbox most of the time)

Now certbox in itself is not really simple in my opinion, and one feels it very fast as soon as we fall out of the beaten path. For instance having it run for volatile instances isn't simple, or if the Paas misses the single feature you need (ex: wildcard support on heroku) you'll have to bear all the complexity again on your shoulders.

In particular the base principle is to renew the cert every 30 days, so inherently proper automation and error handling is the first barrier to entry for certbot. That's already a bit further than "a few commands" in my opinion.

mr_toad2• 8 years ago

Certbot has a issue with dependencies that I’d rather not deal with on a production server:

https://github.com/certbot/certbot/issues/1301

Not to worry though, there are over 100 other ACME clients that I can choose from.

kuroguro• 8 years ago

There's always things like CloudFlare? You have to use them as the main NS, but both transfering the domain and enabling HTTPS is a few clicks (properly configuring your server to only be accessible by CF might be harder, but may not be needed in a static site case).

MichaelApproved• 8 years ago

Cpanel comes with easy to use Lets Encrypt module. Auto-new the certificate and sends optional email alerts each time it renews or fails.

Web hosts are making it easy to use Lets Encrypt, which surprised me. I thought they'd be reluctant to give up the revenue from high margin certificate sales.

schoen8• 8 years ago

This varies a lot from web host to web host.

ss2003• 8 years ago

Not GoDaddy

pcnix• 8 years ago

It's not just about the chance of problems, it's also the fact that browsers are making it very obvious when a site doesn't have https, and this is enough to scare users away.

modzu• 8 years ago

wait, what? if you can get nginx running you can get lets encrypt running

tialaramex7• 8 years ago

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.

Ajedi324• 8 years ago

FWIW, Apache is getting native support for ACME certs: https://letsencrypt.org/2017/10/17/acme-support-in-apache-ht...

Hopefully in the future more web servers will implement this, and HTTPS will be enabled as the default configuration.

th3l3mons• 8 years ago

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)?

lostapathy2• 8 years ago

Exactly this. If you can't imagine the harm in that - pretend they are injecting NAMBLA ads or Goatse-type images into your blog.

saryant• 8 years ago

I've also seen airlines do this with their in-flight wifi. Looking at you, Icelandair.

squeaky-clean• 8 years ago

In addition, I also recall seeing Comcast (I believe) injecting JS to users that they are approaching their plan limits

This has happened to me. Re-installed Windows on my gaming computer and re-downloaded all my games. By the time I hit 900GB usage, any HTTP page would display a popup with "You have 100GB of data left".

I thought it was malware on the website trying to phish me the first time I saw it.

Aaron1011• 8 years ago

I believe you're think RFC 6018: https://tools.ietf.org/html/rfc6108

Related HN discussion: https://news.ycombinator.com/item?id=15890551

mrfredward2• 8 years ago

My house is insecure. There's no alarm, so anyone could just smash a window and steal my TV. But replacing my TV costs a lot less than an alarm system, and the risk of being caught for theft is greater than the TV's value.

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.

crtasm• 8 years ago

High bill because someone walked in and watched TV for three days? (I'm guessing it was actually due to heating/aircon)

dragonwriter6• 8 years ago

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.

HTTPS doesn't protect the content of your site from being stolen, it protects your users from hostile third-party content masquerading as yours.

Sol-• 8 years ago

I guess one problem with risks on the web when compared to your house analogy is that automation can make all the difference there. For the specific MITM example automation might be less likely, but on computer networks, even very unlikely risks can get amplified by the fact that someone can just automate the exploitation.

If automated drones roamed the country looking for open doors to break into, people might be more worried about their home security. Fortunately, the physical world protects us from wide-scale exploitation.

trash_panda5• 8 years ago

This is important. Because the discussion around HTTPS tends to train users into think that HTTPS = Web Security.

I totally agree that it's important, and I understand the attack vectors. But what about your outdated WordPress/Joomla installation? What about your default password on your admin site? Those I think are more serious issues, but of course harder to tackle.

To exploit a MiTM you need to be on the same network, this could be achieved through your local-cafe's WiFi or by compromising an internal system of a local network. Not a trivial task I would say. If you manage to pull it off, the impact is contained to that local network.

If you compromise the insecure site directly, you can have an much wider audience and HTTPS won't help you in this scenario.

jakelazaroff5• 8 years ago

To exploit a MiTM you need to be on the same network, this could be achieved through your local-cafe's WiFi or by compromising an internal system of a local network.

Or, say, your ISP injecting ads and tracking scripts into unencrypted pages your browser requests.

eridius• 8 years ago

You don't need to "understand how Let's Encrypt works" to use it. You can still copy & paste from a tutorial in order to set it up.

kelnos• 8 years ago

As a website visitor, if I don't see HTTPS, I worry -- ever so slightly -- that someone has added some junk to the content along the way, whether it's my ISP or someone with a fake AP in a coffee shop.

I also just don't want ISPs etc. knowing what content I read, in minute detail. No, I don't "have something to hide", but I'm sick of it being so easy for companies to build detailed profiles of my habits and then sell that information to people who want to sell me things. No thanks.

Sure, I could run a VPN all the time. But I think to be a good web citizen, site operators should do all they can to protect their users from malicious actors out there. TLS is just one piece of that.

And honestly, for a modest static blog site, you can set up Let's Encrypt in less than an hour.

Groxx• 8 years ago

The worry is well-founded too, as e.g. tons of hotels I've visited have added junk, even recently, as have some coffee shops (mostly prior to widespread wifi-ification though, I haven't seen it in a while). Airplane / airport wifi has as well.

HTTP feeds this kind of hostile behavior.

linuxftw• 8 years ago

No need to worry. That static site is probably loading dozens of javascript libraries and mining every click on the page anyway... err, analytics.

derefr• 8 years ago

You know what's even easier than a simple Nginx server setup? A simple https://caddyserver.com server setup. Which will automatically provision a LetsEncrypt cert for you, no configuration required.

Or, let's go even simpler: no server of your own at all. Anyone who uses GitHub Pages for their static site, gets an automatic LetsEncrypt cert provisioned for their custom domain if they set one. (I'm honestly surprised that other SaaS hosts that set you up with some service on a subdomain, and allow you to map it to a custom domain, haven't followed along and done the same. It's an easy feature to offer!)

Deploying Nginx is a uniquely-bad example to use right now for TLS ease-of-use. There are all sorts of setups where TLS "just happens"—some of which web-development novices will likely encounter before they become experienced enough to consider "deploying their own web server" to be a sensible action.

yboris• 8 years ago

Thank you for sharing Caddy -- haven't heard of this until your comment. Cheers!

Area12• 8 years ago

I've had a quick look at the paper you reference, but my immediate question is ... this was written around 2009. If the costs and likelihood of getting hacked or phished have increased significantly, some of the conclusions of the paper may now be misleading, at least in detail. Has anyone done an update in the last year?

I still like the paper for one good reason ... it challenges IT people to ask the question: what risk am I mitigating with this rule on the users, and is it worth everyone's effort that will go into it? If yes, see if you can impose the rule. If no ... just be sure you didn't get the numbers wrong.

cm2187• 8 years ago

Actually one service that DNS providers should offer is generating and renewing let's encrypt wildcard certificates automatically, and offering their clients to download them through some API. That would make life a lot easier for less technical devs who are intimidated by the complexity of pki.

davidmurdoch• 8 years ago

And 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 as such.

r3bl• 8 years ago

That article specifically mentions that service workers avoid these issues. There's nothing stopping static pages from making service workers available.

HTTPS and a service worker are a far better solution than having an insecure domain.

pc862• 8 years ago

There's nothing wrong with making something "more difficult" if it serves the greater good or has a larger positive impact than negative. For one, using a trivially higher percentage of a metered satellite feed is not "more difficult," just perhaps marginally more expensive. What percentage of folks reading static blogs are on a metered satellite connection?

I think if every site and application that is currently HTTP was HTTPS a year from now it would be a net positive for internet users.

MrStonedOne• 8 years ago

Nope.

Thats fixable in the client using a http proxy.

The whole point of https is to roll back the ability for middleware devices to modify traffic without the authority of the client or the server.

This is a good thing. He shouldn't be setting up a situation where he is intercepting traffic that neither party of the connection had authorized him to intercept. Regardless of how righteous his intentions are.

sigotirandolas• 8 years ago

Couldn’t you set up the local cache as a proxy server instead of a MitM to solve this? Though it’s a less transparent solution (you have to set up the proxy and its CA on every client).

zaarn5• 8 years ago

Yeah that's pretty much not the case once you setup a HTTPS proxy with a cache. HTTPS merely requires this to be an opt-in from the client unlike HTTP where you can just do it, to hell with the client.

Don't spread BS.

Faark• 8 years ago

Secure makes less accessible for those with shitty connections

This demographic seems especially vulnerable to untrusted 3rd party networks that promise speed or unlimited traffic. People able to make an actually informed decision about security trade-offs are probably a more difficult and could probably work around negative trade-offs by themselves, as mentioned by others. So unless you target especially them, you should probably go with the safer default.

tialaramex7• 8 years ago

Having very high packet loss means something is badly wrong. A good wire-level (yes I know, there are no wires, nevertheless) protocol aims to hit lower packet loss rates by fiddling with other parameters. Example: Let's say you have 40MHz of assigned frequencies, but when both ends measure they find 4MHz of that is full of noisy crap, the rest is fairly quiet. Well, rather than lose bits in those 4MHz and toss away many packets, why not keep 36MHz with a much lower error? If only 6000 packets per second get through of 10 000 sent, then an option to send 9000 and receive 8000 of them is already a win.

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.

zaarn5• 8 years ago

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.

At that distance the very physical latency limit is almost a second. You can literally not go below. The high latency will have a lot of protocols simply time out or consider the packet lost.

At that distance you need some well engineered ground equipment to handle the signal losses. A dish and a high powered transmitter that need to be within a degree of the target. If you're off by a degree you're likely going to hit very bad packet loss. A degree is not much and you could be cause by the ground below stretching and twisting over the day due to temperature changes. TV doesn't have to deal with sending data up the link other than using the massively more powerful and expensive dishes from TV networks.

Lastly, from ground to geostationary orbit you may find that your 40MHz band is full of crap. Not because someone else is sending but because you're sending through a solid belt of radiation and magnetic flux. You'll find that for a wide range of bands they either suck at penetrating the atmosphere, penetrating the magnetic field or get sucked up by interference from half the universe.

The layers above IP have ways to handle packet loss for a reason (although the reason was bad copper cables and bad MAC). Also, the MAC is another problem; you're not the only one who wants to use the very limited resources of the sat. One of the most common and effective forms of bandwidth limiting is dropping packets and it's normal. Packets drop all the time, every TCP connection drops packets. It happens and almost all protocols deal with it on one level or another.

tambourine_man• 8 years ago

Let's Encrypt is one of the best things that happened to the web recently. I wish we had more choices though. Relying so much on a single party is unnerving.

nofunsir• 8 years ago

Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...

jimktrains2• 8 years ago

What use would it be? You don't send LE the private key, and if the NSA was just going to forge TLS certs, they wouldn't need LE to do it.

schoen8• 8 years ago

What would you do with this power? Let's Encrypt certificates are public and don't involve any knowledge of subscribers' private keys.

trash_panda5• 8 years ago

If it's an NSA honeypot it will still be a positive thing for 99% of use cases.

Also, why would they do this? It's smarter to compromise the existing CAs.

2RTZZSro• 8 years ago

HTTPS security model is fundamentally broken to meet the needs of the junta. National Security Letters can be used to "legally" obtain root certificate keys of all Root CAs even remotely affiliated with the United States. You must be extremely naive to believe that the NSA has not already collected all Root CA keys relevant to operations within USA borders. NSL also tend to forbid disclosure of the existence of the NSL, so you will never know that the Root CA is compromised. If you as a Root CA disclose the existence of such a NSL, MS-13 might pay you a visit, and you might unfortunately show up on a obituary in a newspaper nobody reads.

parliament32• 8 years ago

It's a valid question, with two possible threat models:

1) the honeypot uses your private keys to MITM connections

Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key.

2) the honeypot issues fake certs

Let's Encrypt submits a log of every cert issued, see https://crt.sh/ . To verify, it'd be pretty trivial to create a browser extension (if one doesn't exist already) that checks whether certs you encounter appear in the certificate log.

zip1234• 8 years ago

Any CA could be a honeypot. I would say LE is less likely because so much of what they do is in the open.

3pt141596• 8 years ago

It is good, but it is annoying that it came out before we were able to properly lock down domains to cert authorities via DNS. It used to be that a malactor had to buy a new cert when they owned part of your backend if they weren't able to get your private keys.

Now they can just use Let's Encrypt.

schoen8• 8 years ago

Can you clarify what restrictions you'd like to see in place? I didn't quite follow this, but if you can describe what you want to see, I might be able to describe a way to do it or request that it be created.

SahAssar• 8 years ago

IIRC Let's Encrypt are more strict in their validation (HTTP, DNS and SNI) than the least onerous authorities before them. The difference is that they are automated and free, but I don't think that I can get any cert I couldn't get before (either for payment or free).

icebraining10• 8 years ago

StartSSL already existed.

Mikhail_Edoshin• 8 years ago

I went there to see why and the only subhead I understood without searching was "HTTPS is easy". I gather, only HTTPS is easy nowadays :)

Fnoord• 8 years ago

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?

berbec2• 8 years ago

I used to have a $75 netgear router at my house. I changed the local DHCP settings to give out a raspberry pi's internal as DNS. I run dnsmasq on the pi and resolve local hosts that way. Ever internal service in my house uses HTTPS and I have about a dozen.

logan12358• 8 years ago

Sorry this is a day late, but how do you get certificates for internal services? Do you manually trust them on each client? Or do you have a wildcard cert from a public server? Is there some cleaner way to manage internal HTTPS?

zaarn5• 8 years ago

There 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...

Avamander3• 8 years ago

You can buy a domain name and do DNS auth. Requires no open ports and you'll get a trusted cert for that one Pi. I did it for mine (but with SNI verification).

zaarn5• 8 years ago

Pi.hole, it's only local and there is a reason it doesn't open port 443 and only works on 80. On a local non-wireless LAN this is not a concern in my threatmodel.

zzzcpan• 8 years ago

Here'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.

bovermyer• 8 years ago

What are you talking about?

yjftsjthsd-h2• 8 years ago

How are those related? Letsencrypt doesn't try to identify anyone, and certainly doesn't run JavaScript on your site.

grosjona2• 8 years ago

I wonder what would happen if Let's Encrypt started charging for their service AFTER HTTPS became compulsory. Seems like a great (but evil) business strategy. All these CAs could just start increasing their prices and we'd all be forced to pay.

If you understand human behavior, then you know that this WILL happen eventually.

userbinator• 8 years ago

Don't forget the other elephant in the room: certificate revocation.

If your site isn't using HTTPS it will always be "not secure", but always accessible.

If it is, then it's accessible until someone decides to revoke your certificate for whatever reason.

The old quote is relevant again: "Those who give up freedom for security deserve neither."

hiccuphippo2• 8 years ago

How 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.

detaro• 8 years ago

Self-signed certificate (or own CA and certificate signed by that). Buying a certificate for an IP is more expensive than a domain.

hiccuphippo2• 8 years ago

I've tried self-signed certificate somewhere else but it seems Chrome doesn't add the certificate permanently so every few days they get the "scary" not secure window again.

I'll try with my own CA.

user9182031• 8 years ago

Trusted certification authorities are not issuing DV SSL certificates (with domain verification) for IP-addresses; because it creates certain security threats .

iamben3• 8 years ago

Two stories.

Firstly, I had a fair amount of websites with a now EIG owned company for about 10 years. It was just a shared host, but they're all low traffic, and I could easily add a domain name and spin up a blog/project. A few years back I needed https for an API I was working with - the cost was something like $40 a year for the domain, for a project that wasn't a money spinner. So I found another (read: free) way to access the API.

Earlier this year I asked again. It was something like $20-$100 per domain to put an https cert in place, even if I got it myself from LetsEncrypt. As the entire package was about about $100 a year (up 30%, with worse customer service since EIG took over) I finally took the step and moved all my sites elsewhere. The new host isn't much more expensive, but provides free LetsEncrypt with a click from the controlpanel. I now use https on most things.

Secondly, I have a few sites with a decent number of FB likes that have counted up as the result of some viral/social campaigns in the past. None have forms on, all are links to elsewhere. Currently those likes work as (not insignificant) social proofing. Move the site from http to https and I lose the count on the Like button.

The cost in the first point (or the effort/time/cost in moving everything) just hadn't been worth it for the smaller stuff. Facebook not sorting the counts hasn't made it worth it in the second. I suspect my reasons are 2 of many that stop people from upgrading - I guess I'm just saying that even with the best intentions, there are other factors at play that prevent John Everyman from making the move. Make it easy/default for him, more https everywhere.

zulln• 8 years ago

Currently those likes work as (not insignificant) social proofing. Move the site from http to https and I lose the count on the Like button

Surely there must be a alternative way of doing this?

thaniri• 8 years ago

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.

iamben3• 8 years ago

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.

EGreg3• 8 years ago

People here are bringing up the difficulty for a regular user to set up HTTPS.

I 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!

exolymph• 8 years ago

The only “downside” is the inability to type in a URL.

This is not tenable. You have to solve Zooko's Triangle or no one will use your thing. That's the existing problem with Dat, which otherwise works wonderfully.

EGreg3• 8 years ago

Why do you want to type in URLs? It’s like the command line before it was replaced by GUIs for the majority of people who are non technical.

Avamander3• 8 years ago

I 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?

Because there's no interest in that. Getting a domain name is already cheap and easy.

Storing chunks of encrypted data using Kademlia DHT or similar [...]

I've yet to see any P2P system have low latency, high speed and high reliability.

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.

Why?

The only “downside” is the inability to type in a URL.

Good luck saying to your friend the nice webstore you got your hoodie from is [insert non-readable non-pronounceable url].

and third party private ownership/stewardship of user-submitted content would be far less of a foregone conclusion

This is unacceptable for law enforcement

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!

Oh this is an ad...

fwip• 8 years ago

I'm not trying to advertise, but Beaker browser does a real good job of making p2p delivery transparent to the end user. It's probably slower than most sites in normal usage, but certainly acceptable speeds for static sites, and it performs better under the hug-of-death a site gets when posted on Hacker News. :)

Plus, it already has existing methods to map DNS records or servers to the p2p records, so I can access dat://beakerbrowser.com/ or dat://epa.hashbase.io/ and get it served across the p2p network or pull it up offline if I've viewed it before.

grosjona2• 8 years ago

I think that the argument that you can't trust ISPs is weak.. With HTTPS, you still need to trust certificate authorities. It is somewhat suspicious that Google suddenly decided to create their own Certificate Authority in 2017. Forcing every website to use HTTPS just reduces the pool of entities who are able to track and manipulate us and it gives a false sense of security.

There 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.

ackfoo• 8 years ago

The web was supposed to be open and free; it was supposed to democratize the exchange of information. We have lost control of it by allowing corporations to subvert that idea.

Frightening stupid people by exaggerating threats that they don't fully understand is what corporations do to sell their products and services.

Using a browser underwritten by a large corporation is a very bad idea. When it pops up a message saying that a static website is insecure, it's time to get another browser.

AgentME8• 8 years ago

Certificate authorities that participate in Certificate Transparency are forced to publish all certificates they issue, so site owners can tell if a fraudulent certificate for their own domain is ever generated. I think browsers are pushing for all CAs to adopt Certificate Transparency. This greatly reduces the power of malicious CAs.

Qub3d• 8 years ago

I'm going to sorta break the prime directive and link the n-gate rebuttal to these articles: http://archive.fo/xcQ5j

Its a bit heavy-handed, but it does bring up a good point: A lot of this argument for HTTPS-by-default is all on top of assumptions about who is responsible for data security. We're doing a lot and things are improving, but the general public still are all yelling at websites for misusing data that we willingly gave over in the first place [0].

[0] https://xkcd.com/743/

mo3gut• 8 years ago

assumptions about who is responsible for data security.

The chief assumption appears to be "anyone but the browser vendors". Let us consult the article:

  BeEF
  This, to me, was the most impactful demo

Quite the endorsement. So what's BeEF's angle?

"...examines exploitability within the context of the one open door: the web browser."

There could hardly be a clearer expression of contempt for the browser vendors' offerings. But remember, the "open door" is nothing to do with them, it's all your fault for not serving via HTTPS.

Welcome to Clown World.

pixl974• 8 years ago

Eh, there are two execution contexts here.

1. The web browser executing the injected data stream it receives from the remote computer.

2. Your brain interpreting 'non-executable' instructions as received from your browser.

Browser security has nothing to do with me going to 'xyz.com', which is the trusted website for xyz company, and being fed a MiTM telling me to go to a bad phone number for support.

msla• 8 years ago

The fact that site gets "erased" partway down, as if attacked by an evil MiTM, proves it's not serious and is, in fact, arguing for HTTPS.

casper345• 8 years ago

Not security related, but for SEO having HTTPS will treat your website with more mercy in the storm of google searches

bullen• 8 years ago

chrome://flags

Mark non-secure origins as non-secure

Disabled

patrickmcmanus2• 8 years ago

the post is good.. but also: confidentiality matters.

Think about a library. There are no secrets in the stacks that need to be kept from public disclosure. What is secret is the act of using the library - i.e. what they choose to read.

peterwwillis3• 8 years ago

If browsers supported a method to provide content securely without the need to encrypt everything, lots of uses of the web would not be hampered by the TLS-everything-that-moves movement. The limitations we have accepted in our browsers are what causes these conflicts. But we don't have to accept them. We could do with less propaganda and more compromise and innovation.

ezekg3• 8 years ago

I'm unsure on how you could do what you've said without encryption. Any ideas?

ChrisSD• 8 years ago

You could securely sign the data in a tamper resistant way. Although that would be at least as disruptive to http as https is. And it also can't obscure the specific pages you're visiting.

maxvu• 8 years ago

Cryptographic verification?

paulddraper• 8 years ago

Debian apt repos work this way. Everything has hashes or PGP signatures.

It doesn't have to be encrypted to be trusted. In fact, anyone can set up a separate mirror and clients can use it with no concern about safety.

It doesn't offer confidentiality, but it does offer integrity.

Sohcahtoa82• 8 years ago

I feel like this article has been posted a dozen times already, but the "past" link is showing this as the only submission.

EDIT: Nevermind, I'm confusing it with similar discussions:

https://news.ycombinator.com/item?id=17651652

https://news.ycombinator.com/item?id=17599022

https://news.ycombinator.com/item?id=17605973

nanoscopic• 8 years ago

I admin a number of different websites. The majority of them are static. I have forced https redirect on some of them. On others I do not.

The only benefit of https I perceive in the case of static public content is that ISPs cannot easily monitor which specific pages on my domains are being visited. With plain http they could.

I don't particularly care if people get MITM'ed when visiting my static sites. If they did so it generally is because they chose to use unsafe public access points ( wifi ). This extends to some degree to all forms of wifi since so many security forms in use on them can be easily broken.

My current understanding is that enterprise encryption using certs with wifi is still secure and cannot currently be broken.

The only other party would could do MITM against normal customers on their own home internet, while using wired connections, is, I believe, the ISP themselves. Random third parties cannot generally do so. If there is some plausible way they can do so I would like to hear it.

If your ISP is MITMing you, I think you have bigger problems then whether they change the content of my static site when you visit it. If they were, they could potentially target your initial download of your browser and downgrade to http to infect your browser so that you never realize after that that https is faked out...

I think there are caching benefits to using plain http. The primary one is so that your ISP can cache your static content and save internet bandwidth globally.

thsowers• 8 years ago

I don't particularly care if people get MITM'ed when visiting my static sites. If they did so it generally is because they chose to use unsafe public access points ( wifi ). This extends to some degree to all forms of wifi since so many security forms in use on them can be easily broken.

While wifi offers little "complete" security, some methods of security, (like implementing HTTPS) require very little work for a relatively large decrease in attack surface

bigiain• 8 years ago

Also, remember that people who get MITMed are not going to say "Oh, sucks to be me for using insecure public wifi and getting pwned when visiting nanoscopic.io, I'm such an idiot..." - they're going to say "The shit-weasel who runs nanoscopic.io installed a fucking cryptominer and configured porn ad dns servers on my laptop! Don't _ever_ visit that site!"

The "very little work" required to use https these days could one day be incredibly valuable in terms of not having your reputation trashed... Perhaps you _should_ care a little more about people getting MITMed...

stanmancan• 8 years ago

Rogers Cable is one of the few major ISPs in Canada and they used to (maybe still do? I moved away years ago) modify your page content to include data overage warnings or past due balance warnings at the top of pages you visited.

HTTPS everything please.

fmpwizard• 8 years ago

generally is because they chose to use unsafe public access points

It sounds like you are penalizing users for not using a vpn or some other method when out of their homes. Yes, people can do that, but in 2018 having https on the sites you manage is a lot easier than asking every possible visitor to use a vpn. I hope you would reconsider and enable https on all the sites you are an admin.

If your ISP is MITMing you, I think you have bigger problems then whether they change the content of my static site when you visit it. If they were, they could potentially target your initial download of your browser and downgrade to http to infect your browser so that you never realize after that that https is faked out...

They could, and maybe in countries other than the US you have plenty of ISP choices, but in many places in the US, you are stuck with just one ISP.

And so far, we know that ISPs are manipulating http traffic but so far they haven't gone all the way to give you an infected browser. Again, it is possible, but I think that a better approach is if we all do as much as we can to help each other, the internet could be a better place.

Jach• 8 years ago

It's all good to point this out, but it's a social argument, not a technical one. If the technical arguments have been eliminated (e.g. you have no technical use for encrypting the connection) then you're left with "Join us in giving the finger to ISPs/cafe routers that inject foreign JS!" Don't be upset when people say "Meh. Take it up with those ISPs directly, or with web browser vendors, I don't care and don't want to join your crusade." At some point web browsers will stop serving content over HTTP unless perhaps with a custom flag turned on, and even then, some people will still not use HTTPS.

gerdesj• 8 years ago

I don't particularly care if people get MITM'ed when visiting my static sites.

Ajedi324• 8 years ago

There are other threat vectors you aren't considering such as DNS cache poisoning, [BGP hijacking][1], and [rogue USB sticks][2].

But even ignoring that, why wouldn't you want to take basic steps to protect against rogue access points or ISPs? "I don't particularly care if people get MITM'ed when visiting my static sites" seems, at least to me, like a rather dismissive attitude towards the security of your site's users.

I'd also like to point out that with the ever-widening deployment of HTTPS the hypothetical attack you described where your ISP MITMS your browser install is becoming less and less feasible. Nearly all modern browsers include a [HSTS preload list][3] which ensures they will never attempt to connect to certain domains over an insecure connection. A browser download site (or even just the user's search engine, which would link directly to the HTTPS-protected download page) being on this list would make the downgrade attack you describe much more difficult.

[1] https://www.internetsociety.org/blog/2018/04/amazons-route-5...

[2] https://samy.pl/poisontap/

[3] https://scotthelme.co.uk/hsts-preloading/

drewmol• 8 years ago

I don't particularly care if people get MITM'ed when visiting my static sites.

I for one would be honored, and then irritated.

bodas• 8 years ago

One benefit of HTTPS is that ISPs can't insert their ads onto your website. Believe me, there are ISPs that do that.

If your ISP is MITMing you, I think you have bigger problems then whether they change the content of my static site when you visit it.

Perhaps. But in the UK ISPs are legally required to log every web page you visit. However, they are not going to serve you a fake version of Chrome (which is signed anyway).

unaaaa• 8 years ago

The only benefit of https I perceive in the case of static public content is that ISPs cannot easily monitor which specific pages on my domains are being visited

What about HTTP2?

ecesena• 8 years ago

Github pages supports TLS even for custom domains now, via Let's Encrypt. At this point, I don't think there's any excuse anymore for having a static website without TLS. Either use Github pages, or just use your favorite hosting provider and put a CDN in front of it.

Note: I'm not affiliated to Github, but I've used them multiple times, and just recently discovered they now support TLS. If you want to see an example: https://solokeys.com is hosted on Github pages.

mr_toad2• 8 years ago

As far as I know Github is the _only_ static site provider that will do this for you.

I’m scratching my head trying to figure out the best way to do automated certificate renewal for othe providers. It’s not like you can run certbot on a static page.

ValentineC• 8 years ago

As far as I know Github is the _only_ static site provider that will do this for you.

Netlify automatically does this [1], and Zeit's Now too, I think [2].

[1] https://www.netlify.com/docs/ssl/

[2] https://zeit.co/docs/examples/static

AnaniasAnanas• 8 years ago

All websites need onion/i2p addresses, not HTTPS.

alerighi• 8 years ago

The drawback to use https everywhere is that a big company can't cache locally things that gets downloaded again and again from the network like OS and application updates, videos on the web, and so on

I think that we need an alternative to https, a protocol that guarantees only authentication (sing the packets, basically) and doesn:t encrypt content, you can verify that what you get is what the website owner intended (no mitm) and you can have a cache.

Why Static Websites Need HTTPS

Related Stories