21 ms·

Why Static Websites Need HTTPS

328 points by edward 8y ago

alerighi 8y 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.
Mikhail_Edoshin 8y 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 :)
austincheney 8y 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 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.
- dvfjsdhgfv 8y 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.
- skuzye 8y 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.
  - austincheney 8y 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 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.
    - skuzye 8y ago
      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 application has been loaded before but I feel like it would be a half-baked HSTS implementation. Edit: it was too convoluted
      - austincheney 8y ago
        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 https://en.wikipedia.org/wiki/Transport_Layer_Security Simply modify the TCP connection in transit to return other TSL encrypted data than what the user asked for. Really, if you are already at the router you can essentially do anything to the user's traffic and modify it in any way except read encrypted data. Simply redirect the user to a spoofed domain with a spoofed page running malicious code sent as HTTPS. Then you can gather all the privacy data you want through HTTPS.
some_account 8y ago
Why wouldn't you? It took me 30 mins to read and set up a cert from let's encrypt.
- gt2 8y 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..
gt2 8y ago
A big reason is that Chrome (and others?) specifically show 'Not Secure' for all sites not using https.
- H1Supreme 8y 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.
  - AgentME 8y 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.
adwhit 8y 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.pdf https://www.nspw.org/2009/proceedings/2009/nspw2009-herley.p...
- MichaelApproved 8y 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.
  - ss2003 8y ago
    Not GoDaddy
  - schoen 8y ago
    This varies a lot from web host to web host.
- tudelo 8y ago
  Pretty sure you can use certbot and just run like... a few commands. Even easier than setting up Nginx.
  - deleted 8y ago
    [deleted]
  - adwhit 8y 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.
cm2187 8y 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 8y ago
And one reason it doesn't: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ 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 8y 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.
- pc86 8y 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 8y 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 8y 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).
tambourine_man 8y 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 8y ago
  Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...
  - deleted 8y ago
    [deleted]
  - jimktrains2 8y 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.
  - schoen 8y 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_panda 8y ago
      You don't need to have private keys to exploit this scenario. Let's say you own example.com, and you add a certificate by Let's Encrypt. If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. The value of a CA is that it's a trusted 3rd party that holds a private key used to sign public keys (certificates). Never a CA should get hold of your private keys.
      - schoen 8y ago
        > If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. I'm not sure if you're referring to CAs' ability to issue fake certificates, or if you're suggesting that the certificate issuer can directly MITM connections. CAs' ability to issue fake certificates is a very serious concern which has led to the Certificate Transparency system where all issued certificates must be publicly disclosed (in a system outside of the issuer's control) in order to be publicly trusted. A site doesn't have to use a certificate from a particular CA in order to be vulnerable to misissuance by that CA, as in the Iranian Comodo and DigiNotar attacks, where Gmail was briefly vulnerable to MITM attacked involving misissued certificates from these CAs even though it didn't normally use certificates from either of them at all. CAs don't have the ability to use their signing keys directly to MITM connections involving certificates that they issued, because the signing key isn't used for any cryptographic purpose other than validating that the certificate (which refers to the site's public key) was validly issued.
Fnoord 8y 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?
- berbec 8y 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 8y 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?
    - berbec 8y ago
      I resolve internal services as subdomains of a domain I own. I use a wildcard I get assigned on an EC2. I script an sftp upload of the a new cert every renewal to my main internal machine where it is shared via nfs. This is the simplest way I've found.
zaarn 8y 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...
- Avamander 8y 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).
  - zaarn 8y 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 8y 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 8y ago
  What are you talking about?
- yjftsjthsd-h 8y ago
  How are those related? Letsencrypt doesn't try to identify anyone, and certainly doesn't run JavaScript on your site.
  - grosjona 8y 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.
    - yjftsjthsd-h 8y ago
      I would think that there are enough competing vendors, and they are sufficiently interchangeable, that one vendor having low prices will drag the whole market down. That is, I believe that CAs are actually a nearly efficient market.
    - tialaramex 8y ago
      This might even make sense as "a great (but evil) business strategy" except Let's Encrypt isn't a business, it's provided by a charity, ISRG, the Internet Security Research Group, set up for exactly this purpose by people from Mozilla (a charity) and the EFF (another charity) I suspect that the people behind ISRG weren't as paranoid as the Free Software Foundation about being corrupted by some hypothetical evildoers (the FSF has a whole mechanism to try to ensure that if you somehow take over the Foundation you can't use its resources to counter its original purpose) but you're going to need a bit more than a vague idea that people are capable of evil as an explanation for why good things are actually not good.
hiccuphippo 8y 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 8y ago
  Self-signed certificate (or own CA and certificate signed by that). Buying a certificate for an IP is more expensive than a domain.
  - hiccuphippo 8y 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.
    - breakingcups 8y ago
      Can I suggest registering a domain for $1, pointing that at the IP and using LetsEncrypt? Probably less effort in the long run.
- user9182031 8y ago
  Trusted certification authorities are not issuing DV SSL certificates (with domain verification) for IP-addresses; because it creates certain security threats .
iamben 8y 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 8y 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 8y 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:// http:// URL.
  - iamben 8y 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.
casper345 8y ago
Not security related, but for SEO having HTTPS will treat your website with more mercy in the storm of google searches
EGreg 8y 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!
grosjona 8y 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 8y 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.
- AgentME 8y 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 8y ago
I'm going to sorta break the prime directive and link the n-gate rebuttal to these articles: http://archive.fo/xcQ5j 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/ https://xkcd.com/743/
- mo3gut 8y 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.
  - pixl97 8y 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 8y 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.
bullen 8y ago
chrome://flags Mark non-secure origins as non-secure Disabled
- bullen 8y ago
  How come you have time to down vote that? And down vote and flag this? This site is creepy.
patrickmcmanus 8y 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.
peterwwillis 8y 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.
- ezekg 8y ago
  I'm unsure on how you could do what you've said without encryption. Any ideas?
  - ChrisSD 8y 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 8y ago
    Cryptographic verification?
    - ezekg 8y ago
      Sure, but that would still leave the data open to the world. Not an alternative to TLS.
      - peterwwillis 8y ago
        Most of the content on the web is intentionally open to the world.
        ezekg 8y ago
        But our personal data is not. So much data is potentially made available from an unencrypted HTTP request.
OnlyRepliesToBS 8y ago
lol removing options with one hand while masturbating to https with the other
Sohcahtoa82 8y 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=17651652 https://news.ycombinator.com/item?id=17599022 https://news.ycombinator.com/item?id=17599022 https://news.ycombinator.com/item?id=17605973 https://news.ycombinator.com/item?id=17605973
nanoscopic 8y 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 8y 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 8y 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...
ecesena 8y 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 https://solokeys.com is hosted on Github pages.
- mr_toad 8y 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 8y 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/ https://www.netlify.com/docs/ssl/ [2] https://zeit.co/docs/examples/static https://zeit.co/docs/examples/static
yobw 8y ago
People love to play the games on Roblox because of their quality and creativity. This has been serving the players for more than a decade. You can continue to play games on Roblox platform until you have the Robux cash with you. As you have learned the hacking methods, you might be able to play the games as much as you want. Enjoy Playing!! http://robuxcodes.ml http://robuxcodes.ml
khana 8y ago
so you don't get jacked
AnaniasAnanas 8y ago
All websites need onion/i2p addresses, not HTTPS.

328 points by edward 8y 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.

Mikhail_Edoshin 8y 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 :)

austincheney 8y 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 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.

dvfjsdhgfv 8y 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.
skuzye 8y 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.
- austincheney 8y 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 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.
  - skuzye 8y ago
    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 application has been loaded before but I feel like it would be a half-baked HSTS implementation. Edit: it was too convoluted
    - austincheney 8y ago
      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 https://en.wikipedia.org/wiki/Transport_Layer_Security Simply modify the TCP connection in transit to return other TSL encrypted data than what the user asked for. Really, if you are already at the router you can essentially do anything to the user's traffic and modify it in any way except read encrypted data. Simply redirect the user to a spoofed domain with a spoofed page running malicious code sent as HTTPS. Then you can gather all the privacy data you want through HTTPS.

some_account 8y ago

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

gt2 8y 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..

gt2 8y ago

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

H1Supreme 8y 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.
- AgentME 8y 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.

adwhit 8y 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.pdf https://www.nspw.org/2009/proceedings/2009/nspw2009-herley.p...

MichaelApproved 8y 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.
- ss2003 8y ago
  Not GoDaddy
- schoen 8y ago
  This varies a lot from web host to web host.
tudelo 8y ago
Pretty sure you can use certbot and just run like... a few commands. Even easier than setting up Nginx.
- deleted 8y ago
  [deleted]
- adwhit 8y 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.

cm2187 8y 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 8y ago

And one reason it doesn't: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ 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 8y 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.
pc86 8y 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 8y 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 8y 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).

tambourine_man 8y 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 8y ago
Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...
- deleted 8y ago
  [deleted]
- jimktrains2 8y 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.
- schoen 8y 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_panda 8y ago
    You don't need to have private keys to exploit this scenario. Let's say you own example.com, and you add a certificate by Let's Encrypt. If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. The value of a CA is that it's a trusted 3rd party that holds a private key used to sign public keys (certificates). Never a CA should get hold of your private keys.
    - schoen 8y ago
      > If Let's Encrypt is a malicious actor, they could MiTM a connection to your site, and present a VALID certificate to the target user, as they hold the private keys used to sign the public certificate. I'm not sure if you're referring to CAs' ability to issue fake certificates, or if you're suggesting that the certificate issuer can directly MITM connections. CAs' ability to issue fake certificates is a very serious concern which has led to the Certificate Transparency system where all issued certificates must be publicly disclosed (in a system outside of the issuer's control) in order to be publicly trusted. A site doesn't have to use a certificate from a particular CA in order to be vulnerable to misissuance by that CA, as in the Iranian Comodo and DigiNotar attacks, where Gmail was briefly vulnerable to MITM attacked involving misissued certificates from these CAs even though it didn't normally use certificates from either of them at all. CAs don't have the ability to use their signing keys directly to MITM connections involving certificates that they issued, because the signing key isn't used for any cryptographic purpose other than validating that the certificate (which refers to the site's public key) was validly issued.

Fnoord 8y 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?

berbec 8y 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 8y 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?
  - berbec 8y ago
    I resolve internal services as subdomains of a domain I own. I use a wildcard I get assigned on an EC2. I script an sftp upload of the a new cert every renewal to my main internal machine where it is shared via nfs. This is the simplest way I've found.

zaarn 8y 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...

Avamander 8y 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).
- zaarn 8y 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 8y 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 8y ago
What are you talking about?
yjftsjthsd-h 8y ago
How are those related? Letsencrypt doesn't try to identify anyone, and certainly doesn't run JavaScript on your site.
- grosjona 8y 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.
  - yjftsjthsd-h 8y ago
    I would think that there are enough competing vendors, and they are sufficiently interchangeable, that one vendor having low prices will drag the whole market down. That is, I believe that CAs are actually a nearly efficient market.
  - tialaramex 8y ago
    This might even make sense as "a great (but evil) business strategy" except Let's Encrypt isn't a business, it's provided by a charity, ISRG, the Internet Security Research Group, set up for exactly this purpose by people from Mozilla (a charity) and the EFF (another charity) I suspect that the people behind ISRG weren't as paranoid as the Free Software Foundation about being corrupted by some hypothetical evildoers (the FSF has a whole mechanism to try to ensure that if you somehow take over the Foundation you can't use its resources to counter its original purpose) but you're going to need a bit more than a vague idea that people are capable of evil as an explanation for why good things are actually not good.

hiccuphippo 8y 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 8y ago
Self-signed certificate (or own CA and certificate signed by that). Buying a certificate for an IP is more expensive than a domain.
- hiccuphippo 8y 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.
  - breakingcups 8y ago
    Can I suggest registering a domain for $1, pointing that at the IP and using LetsEncrypt? Probably less effort in the long run.
user9182031 8y ago
Trusted certification authorities are not issuing DV SSL certificates (with domain verification) for IP-addresses; because it creates certain security threats .

iamben 8y 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 8y 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 8y 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:// http:// URL.
- iamben 8y 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.

casper345 8y ago

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

EGreg 8y 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!

grosjona 8y 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 8y 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.
AgentME 8y 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 8y ago

I'm going to sorta break the prime directive and link the n-gate rebuttal to these articles: http://archive.fo/xcQ5j 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/ https://xkcd.com/743/

mo3gut 8y 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.
- pixl97 8y 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 8y 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.

bullen 8y ago

chrome://flags Mark non-secure origins as non-secure Disabled

bullen 8y ago
How come you have time to down vote that? And down vote and flag this? This site is creepy.

patrickmcmanus 8y 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.

peterwwillis 8y 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.

ezekg 8y ago
I'm unsure on how you could do what you've said without encryption. Any ideas?
- ChrisSD 8y 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 8y ago
  Cryptographic verification?
  - ezekg 8y ago
    Sure, but that would still leave the data open to the world. Not an alternative to TLS.
    - peterwwillis 8y ago
      Most of the content on the web is intentionally open to the world.
      - ezekg 8y ago
        But our personal data is not. So much data is potentially made available from an unencrypted HTTP request.

OnlyRepliesToBS 8y ago

lol removing options with one hand while masturbating to https with the other

Sohcahtoa82 8y 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=17651652 https://news.ycombinator.com/item?id=17599022 https://news.ycombinator.com/item?id=17599022 https://news.ycombinator.com/item?id=17605973 https://news.ycombinator.com/item?id=17605973

nanoscopic 8y 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 8y 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 8y 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...

ecesena 8y 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 https://solokeys.com is hosted on Github pages.

mr_toad 8y 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 8y 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/ https://www.netlify.com/docs/ssl/ [2] https://zeit.co/docs/examples/static https://zeit.co/docs/examples/static

yobw 8y ago

People love to play the games on Roblox because of their quality and creativity. This has been serving the players for more than a decade. You can continue to play games on Roblox platform until you have the Robux cash with you. As you have learned the hacking methods, you might be able to play the games as much as you want. Enjoy Playing!! http://robuxcodes.ml http://robuxcodes.ml

khana 8y ago

so you don't get jacked

AnaniasAnanas 8y ago

All websites need onion/i2p addresses, not HTTPS.