8 ms·

Plaintext HTTP in a Modern World

40 points by memorable 4y ago

superkuh 4y ago
Everything in this article rings true. But there's more. HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. The more browsers refuse to show HTTP, the more people in LE, the greater prize it is for those that want to control what is seen. If you want the web to be free and open, and you run a personal website, please consider providing HTTP+HTTPS.
- aliraheem 4y ago
  I may be wrong, but as I understand it HTTPS connections typically use an ephemeral key with the certificate used to authenticate the servers identity. So simply having the certificate does not mean one can read the traffic without conducting a man-in-the-middle attack. This means that anyone who could read traffic from a HTTPS connection could read it from a HTTP connection just as easy. The arguement seems to boil down to, everyone uses a master lock, some people can open master locks, please consider leaving your locker unlocked... why?
  - jagged-chisel 4y ago
    Just to be complete: it’s not that the key is ephemeral, it’s the way it’s agreed upon. The symmetric key is never in the communication stream.
  - tialaramex 4y ago
    Not just typically. All the uses, even with older protocols, use ephemeral keys to secure the HTTP transaction. Even the most awful RSA kex (using the RSA algorithm to just encrypt a random key and send it to the other party, rather than doing a Diffie-Hellman key exchange of any kind) is still ephemeral keys and still cannot be decrypted by a CA. It's terrible because it has no Forward Secrecy, but it would not fall to this imaginary attack. With Forward Secrecy (always in TLS 1.3 and if you didn't deliberately choose insecure options in TLS 1.2 and earlier) even if your adversary kept a transcript of the encrypted transaction and they later obtain your actual private key, that's still no enough to decrypt the transaction because the transaction key was ephemeral. In fact the CA deliberately by policy must not have the private key needed to do more. If anybody has evidence of a present day Certificate Authority either asking for their private key [other than for a "Key compromise" type event where the certificate gets invalidated] or of them providing a mechanism by which they "randomly" choose your key and would have an opportunity to just remember it - tell m.d.s.policy https://groups.google.com/a/mozilla.org/g/dev-security-policy https://groups.google.com/a/mozilla.org/g/dev-security-polic... Your processes shouldn't open you to such an attack (private keys should ideally never leave the machines using them) but it's also policy that the CA shouldn't want to ever know these keys. Not least because this would make them a target.
  - afiori 4y ago
    > The arguement seems to boil down to, everyone uses a master lock, some people can open master locks, please consider leaving your locker unlocked... why? In fairness it should be more of "everyone uses a master lock, some people can open master locks, please consider not making master locks own 90% of the locks"
- Macha 4y ago
  I believe there's three or four well accepted ACME providers now, which is why a lot of tools now support or even default to alternative vendors, partly to mitigate this concern. e.g. acme.sh will try ZeroSSL first, Caddy will rotate between ZeroSSL and Let's Encrypt.
  - zhfliz 4y ago
    acme.sh moving to ZeroSSL has nothing to do with increasing variety. acme.sh moved to ZeroSSL as default due to being sponsored by them. my primary reason for avoiding ZeroSSL is the requirement of providing an email address to them that can be abused.
    - mholt 4y ago
      Caddy doesn't require an email address for ZeroSSL (but we still strongly recommend that for troubleshooting sake).
- KronisLV 4y ago
  > HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. Well where are all the other free SSL/TLS certificate providers, then? ZeroSSL sometimes gets mentioned, though they are also pretty keen to charge you, which is the exact reason why many go for Let's Encrypt: https://zerossl.com/pricing/ https://zerossl.com/pricing/ (admittedly, they're much cheaper than most alternatives, but you can't beat free) Most of the other paid providers out there do see like they're just running a racket in comparison: https://www.ssl.com/certificates/basicssl/ https://www.digicert.com/tls-ssl/basic-tls-ssl-certificates https://www.godaddy.com/en-uk/web-security/ssl-certificate It's an order of magnitude more expensive than just getting a domain, my expenses would be in the hundreds of dollars per year if I wanted to get the certificates from them, which I can't really afford while working in Latvia and having 30+ sites to manage across different domains. Let's Encrypt works and once it stops working (should that ever happen, which you kind of need to include in your risk analysis), I'm kind of screwed.
  - Lex-2008 4y ago
    well, to be fair, https://zerossl.com/pricing/ https://zerossl.com/pricing/ has a "free" column :) On the other page, https://zerossl.com/features/acme/ https://zerossl.com/features/acme/ it looks like free acme certificates can have a wildcard records (*.example.com). https://www.sslforfree.com/ https://www.sslforfree.com/ claims they use zerossl and support wildcard records. Also, one of others you mentioned also has a free acme option, but without mentioning wildcards: https://www.ssl.com/how-to/order-free-90-day-ssl-tls-certificates-with-acme/ https://www.ssl.com/how-to/order-free-90-day-ssl-tls-certifi...
    - KronisLV 4y ago
      Upon a closer look, it indeed seems that the certificate count limitations apply to the manually requisitioned certificates, not the ACME ones: > By using ZeroSSL's ACME feature, you will be able to generate an unlimited amount of 90-day SSL certificates at no charge, also supporting multi-domain certificates and wildcards. Each certificate you create will be stored in your ZeroSSL account. So I guess that's a viable option.
- Anunayj 4y ago
  Even better, maybe add TLSA records too! TLSA when combined with DNSSEC can replace the need for Certificate authorities. If you want to show independence from CAs, that's one way to do it.
  - tptacek 4y ago
    TLSA replaces certificate authorities like LetsEncrypt with DNS registrars, and, in the process, gives up certificate transparency and the rest of WebPKI surveillance; WebPKI surveillance has resulted in the termination of some of the largest certificate authorities, for misissuance; meanwhile, your browser can't terminate the TLD operators. It's not a good tradeoff.
- chrismorgan 4y ago
  Yes, there is a certain measure of trust going into parties like Let’s Encrypt, but I don’t think it’s as bad as you are saying. • A CA can’t intercept anything based on your using them. • A CA can refuse to issue a certificate for your site, but if this got out (which it would), it would significantly damage their reputation and I don’t think it will ever make sense for them to unless legally compelled. In that case, there are other providers, unless legal compulsion has removed them too, in which case the world wide web is dead anyway, so this is not worth worrying about. • A CA can issue a false certificate for your site. There is, however, a non-trivial risk of them being detected in doing this (much smaller for small sites, but the system is set up in such a way that almost anyone can check and detect most instances, and I think you can be reasonably sure Let’s Encrypt specifically is being monitored for suspicious patterns by multiple parties that have vested interests in the system running smoothly), and if it did get detected, they would certainly be subjected to extreme scrutiny, so that any more instances would be very likely to be detected, and if a good explanation was not provided in short order (and even then it wouldn’t be too easy to recover), they would be dead, though it would certainly be a period of great pain for the web. In other words, not only does the potential upside of cheating go up, but also the downside. I don’t think your conclusion that you should support HTTP is reasonable.
nibbleshifter 4y ago
If you run older machines (I do) and want them to access the modern web, instead if asking everyone else to degrade their security - just run an upstream proxy that can fix the SSL issues for you. Its like an hours work to set up.
- secondcoming 4y ago
  I agree. Having to support now-obsolete systems is a bane of software. HTTP itself sucks because there are so many standards-breaking systems out there. If you want to write a new custom HTTP server you need to understand all these potential quirks, reading the RFCs isn’t enough.
tmikaeld 4y ago
Ironically, the article redirects http to https
- Triave 4y ago
  The article recommends redirecting if the browser sends a Upgrade-Insecure-Requests header.
jbotdev 4y ago
Not sure I understand the concern about access from “modern embedded devices”. Something like a Raspberry Pi, or really anything with a decent ARM processor, can easily handle TLS.
- eternityforest 4y ago
  It is a potential point of failure though, you normally need persistent storage or ramdisk tricks to keep the certs up to date.
- shakna 4y ago
  TLS can be handled by much, much small devices, too! Most of the cheap Xtensa line of things, like the ESP can handle decoding TLS [0]. [0] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_tls.html https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...
  - 13security 4y ago
    The problem is in supplying the CA certificate(s) used to verify the web-of-trust. Web browsers are pre-loaded with a huge number of trusted CA certificates. Pre-loading and maintaining that list on an embedded microcontroller is non-trivial. Not to mention what happens when a CA root is compromised or goes rogue, you have to deal with the revocation process. Your link mentions global_ca_store but provides no guidance on how to effectively populate it. That's the problem. Interestingly, providing a non-Tivo-ized system, e.g. one that allows connection to an arbitrary cloud server, requires even more work than just hardcoding in "your" CA certificates. None of this is insurmountable, but it leaves devs pining for a pre-HTTPS world where you can just do a DNS lookup and send "GET / HTTP/1.0" and not have to worry about all the attack vectors that HTTPS protects against, as well as the ones that HTTPS opens you up to.
- astrobe_ 4y ago
  The word "modern" in the phrase is dumb -- as usual with the word modern; it's on of those word that convey no real meaning most of the times. It's not about modern, it's about power. Current 32bits SoCs prolly sale for the same price as 16bits systems of a decade ago, so yes, they probably can handle HTTP. However, 8 and 16 bits microcontrollers with only a few kb of RAM/Flash are still made ("modernly"), sold and used - and those cannot handle HTTPS.
kgeist 4y ago
>While this push for security is good for protecting modern communication, there is a whole web full of information and services that don’t need to be secured It's not only about security. I wonder if it happens in other countries too - here in Russia ISPs used to inject advertisements directly into HTTP traffic which was very annoying and now they inject propaganda justifying the war. Fortunately very few sites use HTTP nowadays compared to 10 years ago, so I haven't seen such ads in a while.
- bongobingo1 4y ago
  Comcast used to do this, Verizon too I think (as well as DNS hijacking).
  - zrail 4y ago
    Ugh DNS hijacking is the worst. One of the big residential ISPs for a time would trap NXDOMAIN and redirect to a damn search page with ads. So gross.
- nicoco 4y ago
  The author is aware of this. At the bottom of the article: > Please don’t contact me to “well ackchyually” me and explain MITM attacks and how your terrible ISP inserts ads into your unencrypted web pages
  - tadfisher 4y ago
    ... which in no way addresses the issue. Again, a proxy solves the problem for old devices without sacrificing security.
- tialaramex 4y ago
  > It's not only about security. That's still security, and such security is part of why HTTPS exists. TLS promises three things: * Integrity :: that the two participants (for HTTPS this will be a web server and user agent) move data without anybody else getting to alter it successfully. * Confidentiality :: that the two participants move data without anyone else learning what the data is [but they can learn when data is moved and a upper limit on how much data was moved] * Authenticity :: that the participants can, at their option, reveal some proof of identity to the other tied to this TLS session. For HTTPS typically only web servers provide such identity, as a Certificate. Injecting crap into your data is forbidden by the Integrity requirement.
codepoet80 4y ago
I love everything about this post, and the (short) discussion here. I worked out some complex PHP user-agent detection on my websites to serve HTTPS to newer machines, and HTTP to older ones. I instinctively knew Apache2/nginx should be able to do it, but all the documentation online is about redirecting everyone to HTTPS. I passionately believe older machines still have a place on the Internet, but everyone's in a hurry to donate all their data to big companies on the latest iPhone, so they don't care about that. I also run an upstream SSL-bump proxy for my own older devices, and a small community of others, allowing us to browse the modern web (or at least, those sites that will still render on older browsers). The LE service is so important for certain applications and users, but I'm saddened that the push for HTTPS seemed to require the death of HTTP. I appreciate the OP sharing his nginx config, and the few of you who replied with additional thoughts.
- nine_k 4y ago
  It's not just death of HTTP. It's the death of the "trust by default" model of Internet communication. When the Internet didn't matter much, everything was in the open. Now that real money and real control critically depend on the Internet, everything is going to be encrypted, digitally signed, firewalled, etc. I don't thunk there is a way back. For old machines one can run a TLS-terminating proxy inside the secured internal network.
oneplane 4y ago
This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world). https://www.troyhunt.com/heres-why-your-static-website-needs-https/ https://www.troyhunt.com/heres-why-your-static-website-needs... If your problem is some ancient device that cannot speak reasonably recent protocols, the solution is to not allow that device on the main internet directly. That might mean the device itself has to live behind a proxy, or it has to use a remote browser, or it might (as you might guess) simply be a matter of decommissioning the device or only using it on a local network. Any time the general security of a system is downgraded for some edge case, that same downgrade can be used to attack everyone else.
- shaicoleman 4y ago
  Visiting a single unencrypted website allows anyone who controls the connection (your government/ISP/WiFi provider) to cause your browser to silently execute malicious code and download malicious content. Compromising the security of 99.9% of users for the benefit of the 0.1% isn't even remotely worth it. Those 0.1% also have a simple workaround of using a proxy if needed.
  - marginalia_nu 4y ago
    Seems like a browser issue, not a website issue.
    - LunaSea 4y ago
      Browser's can't verify the integrity of website contents.
      - marginalia_nu 4y ago
        HTTPS can't verify that either, to be quite honest. It can ensure modest protection against a specific class of MITM attacks. If the traffic goes through a CDN like cloudflares it's decrypted, inspected, possibly manipulated and re-encrypted mid-flight. A well funded actor can also lean on the website owner, or just hack them.
Macha 4y ago
As an aside, if OP is the website owner: The font-size here is 10.5, it's really small and consequently hard to read.
- chrismorgan 4y ago
  Note that that’s 10.5pt, which is 14px, so it’s not so much smaller than 16px. Still smaller than advisable (I recommend 16–20px), but nowhere near as bad as 10.5px which is really tiny.
indymike 4y ago
Maintaining support for unmaintained client software is a recipe for disaster. Insecure connections are by definition, insecure.
chrismorgan 4y ago
> [Gemini’s] document markup language is based on Markdown so it’s very lightweight and simple to parse without complex HTML/CSS parsers. I wouldn’t describe it in this way. Markdown is in no way simple to parse; HTML is actually easier to parse than Markdown, because it’s defined in terms of an actual parser, whereas the best source for Markdown parsing is CommonMark, which uses a more traditional descriptive spec, meaning you have to think a lot more about it to implement it, and run a test suite over it to be fairly confident you’ve got it right. Sure, HTML is heavier, but it’s much easier to implement and more dependable. The HTML spec is sufficiently large that there are some dark corners I expect very few humans to get right based on their own mental models (e.g. script double escaped state), and if you want to omit open or close tags or commit parse errors it requires more knowledge, but by and large, if you’re sticking to what I could imagine being the subject of a hypothetical book “HTML: the good parts”, it’s very easy to predict with only a little special knowledge required (mostly around which elements are void). But Markdown is generally much harder to predict, and becomes awfully unpredictable as soon as you start interleaving much HTML at all. Gemtext is a completely different beast that works in a completely different way, vastly simpler. Any resemblance to Markdown is superficial. Yes, it uses ``` as a preformatted code delimiter, * for list item lines, # for heading lines and > for blockquotes, but two of these are ancient conventions, and the other two (and slight variants) commonly found in other lightweight markup languages as well. As far as the semantics are concerned, Gemtext is radically different from Markdown, as it’s strictly line-based, and the first three characters are sufficient to determine a line’s type, and there’s no inline formatting. (There’s one more piece of syntax, => links, which is novel in syntax and semantics. And ``` has different semantics from CommonMark too, with alt text instead of an info string, though neither have particularly defined semantics for the use of that part.) Gemtext is not based on Markdown. Some elements of its (meagre) syntax were most likely inspired by Markdown, but it’s not based on Markdown.
enriquto 4y ago
HTTPS is great, of course, but there's still a place for plain HTTP. It is essential that HTTP continues to be universally supported (even behind the ridiculous warnings that browsers put these days). There are several, independent reasons for that: 1. You can build a complete http server and client from scratch with a manageable number of lines of assembly code, as has been demonstrated many times. The innocent "s" in the protocol would be the largest part of that implementation if it was required. Let's allow simple harmless things to stay around. 2. For static http pages with permanent content, encryption is not really necessary. These pages are just like posters hanging on the wall. Of course third parties can "mitm" them and write over them, but it doesn't really matter. It's nice that we can still hang random posters around. 3. Setting-up an https server requires involving another party (the CA) that now holds some power over your content. Since the CA can now effectively shut down your site, they may succumb for pressure to do so. This has already happened. The widely used "let's encrypt" has been made to hold responsibility for the certificates that they issue to sites with problematic content, and they have removed certificates to these sites, which is tantamount to shutting them down. So far, this has just happened for neonazi content, which is alright to censor in my view; but I'm worried that other people will be alright with censoring content which I find reasonable.
- couchand 4y ago
  > Let's allow simple harmless things to stay around. On private networks only, please. Otherwise, they will not be harmless for long. > For static http pages with permanent content, encryption is not really necessary. Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do. > now holds some power over your content. That's simply untrue. Complete FUD. > which is tantamount to shutting them down. No it is not. Stop whining and go home
  - enriquto 4y ago
    > Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do. Not always. My website is a sand castle in the beach. I take care of it and love it, but I don't mind if the wind takes it down, or if some kids destroy part of it, or if some idiot takes a photo of it and photoshops it in order to misrepresent my work. It is just a sand castle. However, I would feel really angry, frothing at the mouth angry, if I was forced to "register" my sand castle in some stupid place so that the passerby could be assured that it is mine, or otherwise not be allowed to build a sand castle at all. This is what I feel by being forced to use https just to store some irrelevant static files. Regarding CA and censorship, what I said is true and can be verified with a small amount of googling. I don't have the patience right now to do that for you, surely another HN reader can provide the relevant references if you are honestly interested.
molticrystal 4y ago
I was going to comment that they would probably enjoy learning about Gopher, the competitor to http, which is a simple enough protocol to browse without a client, but they beat me to it when they brought up Gemini at the end of the article. Gemini they describe as similar to Gopher but with Markdown, then berate it for requiring TLS. Perhaps they can fork it.
- tenebrisalietum 4y ago
  I like Lagrange: it supports both Gemini and Gopher. That's the way to do it IMHO.
Joel_Mckay 4y ago
In general, browsers default security policy force a valid “https” connection to allow access to even the most rudimentary functionality. Admittedly SSL doesn’t stop every issue, especially considering the number of times issuers were caught signing bogus content (Symantec, Microsoft, and so on…). However, it does narrow the number of variables when tracking down 3rd party issues like ISPs fiddling with content. 1. disable crossorigin on your server if you can manage without.. 2. hash sign static included javaScript and CSS files (for CDN services this is good practice): cat file.js | openssl dgst -sha384 -binary | openssl base64 -A In your html/script add content include tag check: ... script src="file.js" integrity="theHash" … 3. Force re-encode of media in a temporary VM instance: strips all user media files of non-media data/metadata to protect people from themselves, mitigates adversarial nuisances, and ensures format conforms to a known standard. 4. DNS over HTTPS (DoH) is an option now, and recommended in many cases 5. DNS Security Extensions (DNSSEC) can be a huge resource drain for high-traffic sites.. YMMV.. sometimes a necessary evil to turn it off.. 6. Should one ever allow users to upload compressed archives, unidentified binaries, webp, SVG, fonts, or TIFF? https://www.youtube.com/watch?v=pmePLg3hdCw https://www.youtube.com/watch?v=pmePLg3hdCw 7. Sanitize your input data with standard filters, and never trust the input content.. even your own (both client and server side checking of data). 8. Traffic shaping firewall to force dropping clients outside a "normal" traffic service range/session-time. 9. Interface transaction quota limit tripwire, and firewall service abuse breaker logic This is hardly an exhaustive list, but will often reduce common nuisances. ;-)

40 points by memorable 4y ago

Everything in this article rings true. But there's more. HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. The more browsers refuse to show HTTP, the more people in LE, the greater prize it is for those that want to control what is seen. If you want the web to be free and open, and you run a personal website, please consider providing HTTP+HTTPS.

aliraheem 4y ago
I may be wrong, but as I understand it HTTPS connections typically use an ephemeral key with the certificate used to authenticate the servers identity. So simply having the certificate does not mean one can read the traffic without conducting a man-in-the-middle attack. This means that anyone who could read traffic from a HTTPS connection could read it from a HTTP connection just as easy. The arguement seems to boil down to, everyone uses a master lock, some people can open master locks, please consider leaving your locker unlocked... why?
- jagged-chisel 4y ago
  Just to be complete: it’s not that the key is ephemeral, it’s the way it’s agreed upon. The symmetric key is never in the communication stream.
- tialaramex 4y ago
  Not just typically. All the uses, even with older protocols, use ephemeral keys to secure the HTTP transaction. Even the most awful RSA kex (using the RSA algorithm to just encrypt a random key and send it to the other party, rather than doing a Diffie-Hellman key exchange of any kind) is still ephemeral keys and still cannot be decrypted by a CA. It's terrible because it has no Forward Secrecy, but it would not fall to this imaginary attack. With Forward Secrecy (always in TLS 1.3 and if you didn't deliberately choose insecure options in TLS 1.2 and earlier) even if your adversary kept a transcript of the encrypted transaction and they later obtain your actual private key, that's still no enough to decrypt the transaction because the transaction key was ephemeral. In fact the CA deliberately by policy must not have the private key needed to do more. If anybody has evidence of a present day Certificate Authority either asking for their private key [other than for a "Key compromise" type event where the certificate gets invalidated] or of them providing a mechanism by which they "randomly" choose your key and would have an opportunity to just remember it - tell m.d.s.policy https://groups.google.com/a/mozilla.org/g/dev-security-policy https://groups.google.com/a/mozilla.org/g/dev-security-polic... Your processes shouldn't open you to such an attack (private keys should ideally never leave the machines using them) but it's also policy that the CA shouldn't want to ever know these keys. Not least because this would make them a target.
- afiori 4y ago
  > The arguement seems to boil down to, everyone uses a master lock, some people can open master locks, please consider leaving your locker unlocked... why? In fairness it should be more of "everyone uses a master lock, some people can open master locks, please consider not making master locks own 90% of the locks"
Macha 4y ago
I believe there's three or four well accepted ACME providers now, which is why a lot of tools now support or even default to alternative vendors, partly to mitigate this concern. e.g. acme.sh will try ZeroSSL first, Caddy will rotate between ZeroSSL and Let's Encrypt.
- zhfliz 4y ago
  acme.sh moving to ZeroSSL has nothing to do with increasing variety. acme.sh moved to ZeroSSL as default due to being sponsored by them. my primary reason for avoiding ZeroSSL is the requirement of providing an email address to them that can be abused.
  - mholt 4y ago
    Caddy doesn't require an email address for ZeroSSL (but we still strongly recommend that for troubleshooting sake).
KronisLV 4y ago
> HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. Well where are all the other free SSL/TLS certificate providers, then? ZeroSSL sometimes gets mentioned, though they are also pretty keen to charge you, which is the exact reason why many go for Let's Encrypt: https://zerossl.com/pricing/ https://zerossl.com/pricing/ (admittedly, they're much cheaper than most alternatives, but you can't beat free) Most of the other paid providers out there do see like they're just running a racket in comparison: https://www.ssl.com/certificates/basicssl/ https://www.digicert.com/tls-ssl/basic-tls-ssl-certificates https://www.godaddy.com/en-uk/web-security/ssl-certificate It's an order of magnitude more expensive than just getting a domain, my expenses would be in the hundreds of dollars per year if I wanted to get the certificates from them, which I can't really afford while working in Latvia and having 30+ sites to manage across different domains. Let's Encrypt works and once it stops working (should that ever happen, which you kind of need to include in your risk analysis), I'm kind of screwed.
- Lex-2008 4y ago
  well, to be fair, https://zerossl.com/pricing/ https://zerossl.com/pricing/ has a "free" column :) On the other page, https://zerossl.com/features/acme/ https://zerossl.com/features/acme/ it looks like free acme certificates can have a wildcard records (*.example.com). https://www.sslforfree.com/ https://www.sslforfree.com/ claims they use zerossl and support wildcard records. Also, one of others you mentioned also has a free acme option, but without mentioning wildcards: https://www.ssl.com/how-to/order-free-90-day-ssl-tls-certificates-with-acme/ https://www.ssl.com/how-to/order-free-90-day-ssl-tls-certifi...
  - KronisLV 4y ago
    Upon a closer look, it indeed seems that the certificate count limitations apply to the manually requisitioned certificates, not the ACME ones: > By using ZeroSSL's ACME feature, you will be able to generate an unlimited amount of 90-day SSL certificates at no charge, also supporting multi-domain certificates and wildcards. Each certificate you create will be stored in your ZeroSSL account. So I guess that's a viable option.
Anunayj 4y ago
Even better, maybe add TLSA records too! TLSA when combined with DNSSEC can replace the need for Certificate authorities. If you want to show independence from CAs, that's one way to do it.
- tptacek 4y ago
  TLSA replaces certificate authorities like LetsEncrypt with DNS registrars, and, in the process, gives up certificate transparency and the rest of WebPKI surveillance; WebPKI surveillance has resulted in the termination of some of the largest certificate authorities, for misissuance; meanwhile, your browser can't terminate the TLD operators. It's not a good tradeoff.
chrismorgan 4y ago
Yes, there is a certain measure of trust going into parties like Let’s Encrypt, but I don’t think it’s as bad as you are saying. • A CA can’t intercept anything based on your using them. • A CA can refuse to issue a certificate for your site, but if this got out (which it would), it would significantly damage their reputation and I don’t think it will ever make sense for them to unless legally compelled. In that case, there are other providers, unless legal compulsion has removed them too, in which case the world wide web is dead anyway, so this is not worth worrying about. • A CA can issue a false certificate for your site. There is, however, a non-trivial risk of them being detected in doing this (much smaller for small sites, but the system is set up in such a way that almost anyone can check and detect most instances, and I think you can be reasonably sure Let’s Encrypt specifically is being monitored for suspicious patterns by multiple parties that have vested interests in the system running smoothly), and if it did get detected, they would certainly be subjected to extreme scrutiny, so that any more instances would be very likely to be detected, and if a good explanation was not provided in short order (and even then it wouldn’t be too easy to recover), they would be dead, though it would certainly be a period of great pain for the web. In other words, not only does the potential upside of cheating go up, but also the downside. I don’t think your conclusion that you should support HTTP is reasonable.

nibbleshifter 4y ago

If you run older machines (I do) and want them to access the modern web, instead if asking everyone else to degrade their security - just run an upstream proxy that can fix the SSL issues for you. Its like an hours work to set up.

secondcoming 4y ago
I agree. Having to support now-obsolete systems is a bane of software. HTTP itself sucks because there are so many standards-breaking systems out there. If you want to write a new custom HTTP server you need to understand all these potential quirks, reading the RFCs isn’t enough.

tmikaeld 4y ago

Ironically, the article redirects http to https

Triave 4y ago
The article recommends redirecting if the browser sends a Upgrade-Insecure-Requests header.

jbotdev 4y ago

Not sure I understand the concern about access from “modern embedded devices”. Something like a Raspberry Pi, or really anything with a decent ARM processor, can easily handle TLS.

eternityforest 4y ago
It is a potential point of failure though, you normally need persistent storage or ramdisk tricks to keep the certs up to date.
shakna 4y ago
TLS can be handled by much, much small devices, too! Most of the cheap Xtensa line of things, like the ESP can handle decoding TLS [0]. [0] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_tls.html https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...
- 13security 4y ago
  The problem is in supplying the CA certificate(s) used to verify the web-of-trust. Web browsers are pre-loaded with a huge number of trusted CA certificates. Pre-loading and maintaining that list on an embedded microcontroller is non-trivial. Not to mention what happens when a CA root is compromised or goes rogue, you have to deal with the revocation process. Your link mentions global_ca_store but provides no guidance on how to effectively populate it. That's the problem. Interestingly, providing a non-Tivo-ized system, e.g. one that allows connection to an arbitrary cloud server, requires even more work than just hardcoding in "your" CA certificates. None of this is insurmountable, but it leaves devs pining for a pre-HTTPS world where you can just do a DNS lookup and send "GET / HTTP/1.0" and not have to worry about all the attack vectors that HTTPS protects against, as well as the ones that HTTPS opens you up to.
astrobe_ 4y ago
The word "modern" in the phrase is dumb -- as usual with the word modern; it's on of those word that convey no real meaning most of the times. It's not about modern, it's about power. Current 32bits SoCs prolly sale for the same price as 16bits systems of a decade ago, so yes, they probably can handle HTTP. However, 8 and 16 bits microcontrollers with only a few kb of RAM/Flash are still made ("modernly"), sold and used - and those cannot handle HTTPS.

kgeist 4y ago

>While this push for security is good for protecting modern communication, there is a whole web full of information and services that don’t need to be secured It's not only about security. I wonder if it happens in other countries too - here in Russia ISPs used to inject advertisements directly into HTTP traffic which was very annoying and now they inject propaganda justifying the war. Fortunately very few sites use HTTP nowadays compared to 10 years ago, so I haven't seen such ads in a while.

bongobingo1 4y ago
Comcast used to do this, Verizon too I think (as well as DNS hijacking).
- zrail 4y ago
  Ugh DNS hijacking is the worst. One of the big residential ISPs for a time would trap NXDOMAIN and redirect to a damn search page with ads. So gross.
nicoco 4y ago
The author is aware of this. At the bottom of the article: > Please don’t contact me to “well ackchyually” me and explain MITM attacks and how your terrible ISP inserts ads into your unencrypted web pages
- tadfisher 4y ago
  ... which in no way addresses the issue. Again, a proxy solves the problem for old devices without sacrificing security.
tialaramex 4y ago
> It's not only about security. That's still security, and such security is part of why HTTPS exists. TLS promises three things: * Integrity :: that the two participants (for HTTPS this will be a web server and user agent) move data without anybody else getting to alter it successfully. * Confidentiality :: that the two participants move data without anyone else learning what the data is [but they can learn when data is moved and a upper limit on how much data was moved] * Authenticity :: that the participants can, at their option, reveal some proof of identity to the other tied to this TLS session. For HTTPS typically only web servers provide such identity, as a Certificate. Injecting crap into your data is forbidden by the Integrity requirement.

codepoet80 4y ago

I love everything about this post, and the (short) discussion here. I worked out some complex PHP user-agent detection on my websites to serve HTTPS to newer machines, and HTTP to older ones. I instinctively knew Apache2/nginx should be able to do it, but all the documentation online is about redirecting everyone to HTTPS. I passionately believe older machines still have a place on the Internet, but everyone's in a hurry to donate all their data to big companies on the latest iPhone, so they don't care about that. I also run an upstream SSL-bump proxy for my own older devices, and a small community of others, allowing us to browse the modern web (or at least, those sites that will still render on older browsers). The LE service is so important for certain applications and users, but I'm saddened that the push for HTTPS seemed to require the death of HTTP. I appreciate the OP sharing his nginx config, and the few of you who replied with additional thoughts.

nine_k 4y ago
It's not just death of HTTP. It's the death of the "trust by default" model of Internet communication. When the Internet didn't matter much, everything was in the open. Now that real money and real control critically depend on the Internet, everything is going to be encrypted, digitally signed, firewalled, etc. I don't thunk there is a way back. For old machines one can run a TLS-terminating proxy inside the secured internal network.

oneplane 4y ago

This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world). https://www.troyhunt.com/heres-why-your-static-website-needs-https/ https://www.troyhunt.com/heres-why-your-static-website-needs... If your problem is some ancient device that cannot speak reasonably recent protocols, the solution is to not allow that device on the main internet directly. That might mean the device itself has to live behind a proxy, or it has to use a remote browser, or it might (as you might guess) simply be a matter of decommissioning the device or only using it on a local network. Any time the general security of a system is downgraded for some edge case, that same downgrade can be used to attack everyone else.

shaicoleman 4y ago
Visiting a single unencrypted website allows anyone who controls the connection (your government/ISP/WiFi provider) to cause your browser to silently execute malicious code and download malicious content. Compromising the security of 99.9% of users for the benefit of the 0.1% isn't even remotely worth it. Those 0.1% also have a simple workaround of using a proxy if needed.
- marginalia_nu 4y ago
  Seems like a browser issue, not a website issue.
  - LunaSea 4y ago
    Browser's can't verify the integrity of website contents.
    - marginalia_nu 4y ago
      HTTPS can't verify that either, to be quite honest. It can ensure modest protection against a specific class of MITM attacks. If the traffic goes through a CDN like cloudflares it's decrypted, inspected, possibly manipulated and re-encrypted mid-flight. A well funded actor can also lean on the website owner, or just hack them.

Macha 4y ago

As an aside, if OP is the website owner: The font-size here is 10.5, it's really small and consequently hard to read.

chrismorgan 4y ago
Note that that’s 10.5pt, which is 14px, so it’s not so much smaller than 16px. Still smaller than advisable (I recommend 16–20px), but nowhere near as bad as 10.5px which is really tiny.

indymike 4y ago

Maintaining support for unmaintained client software is a recipe for disaster. Insecure connections are by definition, insecure.

chrismorgan 4y ago

> [Gemini’s] document markup language is based on Markdown so it’s very lightweight and simple to parse without complex HTML/CSS parsers. I wouldn’t describe it in this way. Markdown is in no way simple to parse; HTML is actually easier to parse than Markdown, because it’s defined in terms of an actual parser, whereas the best source for Markdown parsing is CommonMark, which uses a more traditional descriptive spec, meaning you have to think a lot more about it to implement it, and run a test suite over it to be fairly confident you’ve got it right. Sure, HTML is heavier, but it’s much easier to implement and more dependable. The HTML spec is sufficiently large that there are some dark corners I expect very few humans to get right based on their own mental models (e.g. script double escaped state), and if you want to omit open or close tags or commit parse errors it requires more knowledge, but by and large, if you’re sticking to what I could imagine being the subject of a hypothetical book “HTML: the good parts”, it’s very easy to predict with only a little special knowledge required (mostly around which elements are void). But Markdown is generally much harder to predict, and becomes awfully unpredictable as soon as you start interleaving much HTML at all. Gemtext is a completely different beast that works in a completely different way, vastly simpler. Any resemblance to Markdown is superficial. Yes, it uses ``` as a preformatted code delimiter, * for list item lines, # for heading lines and > for blockquotes, but two of these are ancient conventions, and the other two (and slight variants) commonly found in other lightweight markup languages as well. As far as the semantics are concerned, Gemtext is radically different from Markdown, as it’s strictly line-based, and the first three characters are sufficient to determine a line’s type, and there’s no inline formatting. (There’s one more piece of syntax, => links, which is novel in syntax and semantics. And ``` has different semantics from CommonMark too, with alt text instead of an info string, though neither have particularly defined semantics for the use of that part.) Gemtext is not based on Markdown. Some elements of its (meagre) syntax were most likely inspired by Markdown, but it’s not based on Markdown.

enriquto 4y ago

HTTPS is great, of course, but there's still a place for plain HTTP. It is essential that HTTP continues to be universally supported (even behind the ridiculous warnings that browsers put these days). There are several, independent reasons for that: 1. You can build a complete http server and client from scratch with a manageable number of lines of assembly code, as has been demonstrated many times. The innocent "s" in the protocol would be the largest part of that implementation if it was required. Let's allow simple harmless things to stay around. 2. For static http pages with permanent content, encryption is not really necessary. These pages are just like posters hanging on the wall. Of course third parties can "mitm" them and write over them, but it doesn't really matter. It's nice that we can still hang random posters around. 3. Setting-up an https server requires involving another party (the CA) that now holds some power over your content. Since the CA can now effectively shut down your site, they may succumb for pressure to do so. This has already happened. The widely used "let's encrypt" has been made to hold responsibility for the certificates that they issue to sites with problematic content, and they have removed certificates to these sites, which is tantamount to shutting them down. So far, this has just happened for neonazi content, which is alright to censor in my view; but I'm worried that other people will be alright with censoring content which I find reasonable.

couchand 4y ago
> Let's allow simple harmless things to stay around. On private networks only, please. Otherwise, they will not be harmless for long. > For static http pages with permanent content, encryption is not really necessary. Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do. > now holds some power over your content. That's simply untrue. Complete FUD. > which is tantamount to shutting them down. No it is not. Stop whining and go home
- enriquto 4y ago
  > Unless you actually care about receiving the true content. Which, if you intend to reach that site, you probably do. Not always. My website is a sand castle in the beach. I take care of it and love it, but I don't mind if the wind takes it down, or if some kids destroy part of it, or if some idiot takes a photo of it and photoshops it in order to misrepresent my work. It is just a sand castle. However, I would feel really angry, frothing at the mouth angry, if I was forced to "register" my sand castle in some stupid place so that the passerby could be assured that it is mine, or otherwise not be allowed to build a sand castle at all. This is what I feel by being forced to use https just to store some irrelevant static files. Regarding CA and censorship, what I said is true and can be verified with a small amount of googling. I don't have the patience right now to do that for you, surely another HN reader can provide the relevant references if you are honestly interested.

molticrystal 4y ago

I was going to comment that they would probably enjoy learning about Gopher, the competitor to http, which is a simple enough protocol to browse without a client, but they beat me to it when they brought up Gemini at the end of the article. Gemini they describe as similar to Gopher but with Markdown, then berate it for requiring TLS. Perhaps they can fork it.

tenebrisalietum 4y ago
I like Lagrange: it supports both Gemini and Gopher. That's the way to do it IMHO.

Joel_Mckay 4y ago

In general, browsers default security policy force a valid “https” connection to allow access to even the most rudimentary functionality. Admittedly SSL doesn’t stop every issue, especially considering the number of times issuers were caught signing bogus content (Symantec, Microsoft, and so on…). However, it does narrow the number of variables when tracking down 3rd party issues like ISPs fiddling with content. 1. disable crossorigin on your server if you can manage without.. 2. hash sign static included javaScript and CSS files (for CDN services this is good practice): cat file.js | openssl dgst -sha384 -binary | openssl base64 -A In your html/script add content include tag check: ... script src="file.js" integrity="theHash" … 3. Force re-encode of media in a temporary VM instance: strips all user media files of non-media data/metadata to protect people from themselves, mitigates adversarial nuisances, and ensures format conforms to a known standard. 4. DNS over HTTPS (DoH) is an option now, and recommended in many cases 5. DNS Security Extensions (DNSSEC) can be a huge resource drain for high-traffic sites.. YMMV.. sometimes a necessary evil to turn it off.. 6. Should one ever allow users to upload compressed archives, unidentified binaries, webp, SVG, fonts, or TIFF? https://www.youtube.com/watch?v=pmePLg3hdCw https://www.youtube.com/watch?v=pmePLg3hdCw 7. Sanitize your input data with standard filters, and never trust the input content.. even your own (both client and server side checking of data). 8. Traffic shaping firewall to force dropping clients outside a "normal" traffic service range/session-time. 9. Interface transaction quota limit tripwire, and firewall service abuse breaker logic This is hardly an exhaustive list, but will often reduce common nuisances. ;-)