8 ms·

Let's Not Encrypt (2019)

111 points by todsacerdoti 1y ago

polaris421 1y ago
Funny how we're all securing our websites with time bombs that need defusing every 90 days.
- sschueller 1y ago
  It's going to be less very soon, they are talking about 14 days...
  - NoahZuniga 1y ago
    42 days
deleted 1y ago
[deleted]
jjgreen 1y ago
Heh, that page "Verified by Let's Encrypt"
- croes 1y ago
  > Update 2023-11-05 Yeah, I've got an LE cert now. And I don't want to talk about it.
  - dijit 1y ago
    The ironic observation about the page using an LE cert is fantastic; Browser mandates make the encryption discussion moot. If you don't use it, your argument literally won't load for a modern audience. It speaks to the problem of digital decay. We can still pull up a plain HTTP site from 1995, but a TLS site from five years ago is now often broken or flagged as "insecure" due to aggressive deprecation cycles. The internet is becoming less resilient. And this has real, painful operational consequences. For sysadmins, this is making iDRAC/iLO annoying again. (for those who don't know what iDRAC/iLO are, it's the out-of-band management controller that let you access a server's console (KVM) even when the OS is toast. The shift from requiring crappy, insecure Java Web Start (JWS) to using HTML5 was a massive win for security and usability - old school sysadmins might remember keeping some crappy insecure browser around (maybe on a bastion host) to interact with these things because they wouldn't load on modern browsers after 6mo) Now, the SSL/TLS push is undoing that. Since the firmware on these embedded controllers can't keep pace with Chrome's release schedule, the controllers' older, functional certificates are rejected. The practical outcome is that we are forced to maintain an old, insecure browser installation just to access critical server hardware again. We traded one form of operational insecurity (Java's runtime) for another (maintaining a stale browser) all because a universal security policy fails to account for specialised, slow-to-update infrastructure... I can already hear the thundering herd approaching me: "BUT YOU NEED FIRMWARE UPDATES" or "YOU NEED TO DEPRECATE YOUR FIRMWARES IF NOT SUPPORTED".. completely tone-deaf to the environments, objectives and realities where these things operate.
    - notatoad 1y ago
      >if you don't use it, your argument literally won't load for a modern audience this is just a flat-out lie. yes, modern browsers will stilll load websites over http. come on.
      - dijit 1y ago
        Like all things, it's complicated. Direct sites will load with a "Not Secure" warning, includes on the site might not load without chrome://settings/content/insecureContent And of course: you won't manage to be visible to Google itself, as you'll be down-ranked for not having TLS. If you happen to have a .dev domain: you're on the HSTS Preload list, so your site literally won't load.
        dragonwriter 1y ago
        > And of course: you won't manage to be visible to Google itself, as you'll be down-ranked for not having TLS. You’ll be visible to Google (otherwise there would be nothing to downrank), you will just be less visible on Google.
      - lanyard-textile 1y ago
        And your ISP will be happy to show pop-up advertisements all over your HTTP website. And you, the owner, will likely be to blame by the user.
        AntronX 1y ago
        What first world ISP does this?
        sambaumann 1y ago
        It's not worth it to them precisely because the vast majority of web traffic is served over HTTPS. You can bet they would these days if most traffic was HTTP
        1y ago
  - _def 1y ago
    That quote is the only thing you have to read of that article besides the headline.
moralestapia 1y ago
This reads like satire but ... it isn't?
- ocdtrekkie 1y ago
  The entire behavior of the PKI regime seems like satire, but here we are. A massive amount of fragility introduced to the Internet to basically protect a few edge cases while not addressing any real practical attacks. It's been six years, this author is still right, and now the idiots at the CA/B have decided to move the bomb to a 47 day timer for the whole Internet.
  - PaulHoule 1y ago
    You could tell many different stories for how we got from a world where people made their own web sites to one where people just post on Facebook, but the transition to https is part of that story.
  - akerl_ 1y ago
    MITM of unencrypted HTTP was so common that it was outright a business model for many ISPs. Anybody could look up a guide online on how to monitor who at their starbucks was logging into Facebook or whatever. We were having to train a generation of humans to be afraid of public wifi.
    - 1718627440 1y ago
      > it was outright a business model for many ISPs. I'm not sure if I would object to that if it would be used sparsely and you could opt out.
      - akerl_ 1y ago
        It was not and you could not.
  - colonial 1y ago
    My dude, before HTTPS, anyone could go to a Starbucks and skim every customer's Facebook session with a free Firefox extension. That's not an "edge case."
NegativeK 1y ago
This article feels like an opinion piece with an axiom of perfection or nothing.
- rini17 1y ago
  Sure let's eat crap without complaint, nothing is perfect anyway. /s
- llm_nerd 1y ago
  Indeed, their main grip seems to be with DV, and they seem to hold only EV certs as legitimate. They miss the entire value proposition and purpose of DVs. MITM is a user->service concern. If someone is between a service and LE, there are much bigger problems.
  - Joker_vD 1y ago
    EV certs seem to have basically the same verification policies that CAs had for ordinary certificates back in the early 2000s (i.e., really not that much at all), so I am intrigued as to what the DV has to offer except "it's basically self-signed but with extra steps and the rest of the world will trust it". > If someone is between a service and LE There is always someone there: my ISP, my government that monitors my ISP, the LE's ISP, and the US government that monitors the LE's ISP.
  - Ajedi32 1y ago
    Certainly a MITM between a website and LE is less likely than a MITM between a user on a random public Wi-Fi network and the website, but I've often wondered why more attention hasn't been given to securing the domain validation process itself. There are a lot of random internet routers between CAs and websites which effectively have the ability to get certificates for any domain they want. It just seems like such an obvious vulnerability I'm kinda shocked it hasn't been exploited yet. Perhaps the fact that it hasn't is a sign such an attack is more difficult than my intuition suggests. Still, I'd be a lot more comfortable if DNSSEC or an equivalent were enforced for domain validation. Or perhaps if we just cut out the middleman and built a PKI directly into the DNS protocol, similar to how DANE or Namecoin work.
zygentoma 1y ago
(2019)
DarkmSparks 1y ago
Tbh completely agree. But also, There is no choice now. Best we can do is encourage people to use web browsers that let people visit http sites, and afaik, that doesn't exist anymore.
- 1718627440 1y ago
  Which browser doesn't?
  - DarkmSparks 1y ago
    None of them do as far as I know, they all indicate/imply any http site is serving malware for the last few years.
    - 1718627440 1y ago
      I use Mozilla Firefox and have never experienced that. It's a bit seldom to find websites not automatically redirecting to https:// though. You can try http://repo.mysql.com/ http://repo.mysql.com/ . Sure, the browser has that icon in the URL bar saying that the connection is unsecure. It does also show a big warning, if something with the certificate is wrong and enforces HSTS (which I don't like). But an unencrypted connection works just fine. I'm not using other browsers often, so I my perception is maybe skewed, but I wouldn't have expected them to block http and if I would see that, I would perceive that as a bug.
- majewsky 1y ago
  So this page does not open for you? http://neverssl.com/ http://neverssl.com/
  - DarkmSparks 1y ago
    https://i.ibb.co/FC6pPK5/Screenshot-20251016-032648-Vivaldi.jpg https://i.ibb.co/FC6pPK5/Screenshot-20251016-032648-Vivaldi....
thenthenthen 1y ago
https://archive.is/yLVhD https://archive.is/yLVhD (Hugs)
- riffic 1y ago
  static hosting is the way to go in 2025 if anyone is looking to avoid sudden traffic spikes taking down a questionably configured WordPress.
  - perching_aix 1y ago
    If they have a funny bone available, they should host it using Cloudflare Pages, just to really dot the i and cross the t on the hilarity of their intentional or not hypocrisy of using TLS, and specifically Let's Encrypt as their CA, since.
VikRubenfeld 1y ago
This just can't be true. There's no way no one noticed this before. https can't be this dumb.
- nhumrich 1y ago
  It's not. Certs are designed to protect the average user from MitM, not to protect corporations from it.
  - 1718627440 1y ago
    They do protect corporations, because they can just let there certificate be actually validated of band.
- mikeocool 1y ago
  I think their critique is that to verify domain ownership, Let's Encrypt makes a request to your website over HTTP to the check the challenge -- which is true (because if you don't yet have an SSL certificate they can't make a request over HTTPS). I think they are implying that if someone can man in the middle your website, then they can also man in the middle this request, and issue a certificate for you domain. However, the threat model of man in the middle between a user and your web server is very different than man in the middle between let's encrypt and your web server. Before that widespread use of HTTPS it was trivial to connect to a coffeeshop's wifi network and sniff everyone else's traffic, and ISPs would man in the middle you to inject their own adds in websites you were looking at. On the other hand to man in the middle Let's Encrypt -> your web server, you likely need to be state level actor and/or be or have hacked a major telecom (assuming your web server is running in a reputable data center). Folks like that can almost certainly already issue a certificate for your domain without running a man in the middle on Let's Encrypt.
eduction 1y ago
Chesterton's Fence - why did everyone start encyrpting their websites? His critiques of why LE is flawed security wise are spot on and I suspect something like SSH keys as he suggests would be pretty much as good. But there's a reason we're encrypting everything, and the time when we started encrypting offers a clue as to why. Mass surveillance threat actors are not going to go to the trouble and visibility of MITMing every cert connection, but they will (and in the case of NSA did) happily go to the trouble of hoovering up network traffic en masse and watching how people surf. HTTPS provides some protection there because it at least hides the paths to the specific pages you are reading as you surf online, including things like search engine query terms. The idea that $3.6m is a lot of money to encrypt a huge chunk of web traffic, or that Google is eagerly guarding the money it makes (?) off web certs, which must be a tiny fraction of its actual income, is a clue that this is maybe not a greedy conspiracy.
- SoftTalker 1y ago
  > why did everyone start encyrpting their websites Because Google forced us to, by throwing up scary warnings if we didn't do it. Google doesn't care about $3.6mm. They do care about the additional control they have by this scheme. > [HTTPS] at least hides the paths to the specific pages you are reading as you surf online, including things like search engine query terms. This assumes there isn't a secret firehose feed from Google to the NSA, which I don't think is a safe assumption.
  - philistine 1y ago
    What control does it give them? I'm far more amenable to the idea that Google didn't want ISPs to start injecting ads on websites. If that is control for Google in your view, then my interests aligned with Google for once in a blue moon.
- grepps09 1y ago
  Very much agree on the last point. Controlling the de facto CA for all non-corporate web sites still gives Google a lot of control over who gets to be visible on the Internet, and that’s where the value in LE is. The direct income from SSL certs are completely insignificant.
AntronX 1y ago
> Update 2023-11-05 Yeah, I've got an LE cert now. And I don't want to talk about it. Please do tell. I'm curious what forced him to join The Borg.
jrockway 1y ago
I think that if we didn't do TLS, every ISP would be injecting ads into websites these days. Making it difficult for middle-of-the-road interlopers is a good thing. ISPs don't want the customer service burden of proxy configurations and custom certs (god knows your IT department hates the support aspect of this tampering), so TLS keeps us free of excessive advertising. (Of course, they like do tampering with DNS which is why we have to do DNS-over-HTTPS. If you make it easy to tamper with your traffic, your ISP has a good business case to tamper with your traffic. Sad but true.) I'm not as convinced as the author is that nation states can easily tamper with certificates these days. I am not sure how much CT checking we do before each page load, but either nation states are compelling the issue of certs that aren't in the CT database, or they are and you can just get a list of who the nation states are spying on. Seems like less of a problem than it was a decade ago. The author seems to miss the one guarantee that certificates provide; "the same people that controlled this site on $ISSUANCE_DATE control the site right now". That can be a useful guarantee.
- pavel_lishin 1y ago
  We had this happen to us at work, once. We were working on some feature for a client's website, and suddenly things started breaking. We eventually tracked it down to some shoddy HTML + Javascript being on our page that we certainly didn't put there, and further investigation revealed that our ISP - whom we were paying for a business connection - was just slapping a fucking banner ad on most of the pages that were being served. This was around ... 2008? I wonder if they were injecting it into AJAX responses, too. My boss called them up and chewed them several new assholes, and the banner was gone by afternoon.
  - jabroni_salad 1y ago
    My ISP (Mediacom) appears to have a deal with certain websites to display service messages. The only two I've encountered it on is Amazon and Facebook but they are somehow able to insert a maintenance banner at the top of those two when downtime is anticipated or if I am near the end of my bandwidth quota. Haven't gotten any ads this way but they have the technology.
1718627440 1y ago
> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. In other words, Let's Encrypt certificates don't stop the one thing they're supposed to stop. But the certificate is signed with the key of Let's Encrypt and your own, both of which the private key never leave the server.
- Spivak 1y ago
  Also MITMing a user is much easier than MITMing Let's Encrypt themselves who perform multiple checks from different locations.
- bilekas 1y ago
  Yeah it reads as if the OP misunderstands the attack vectors of SSL. If there's a misconfiguration, or the server admin is not correctly authenticating the authority, then sure. But skips over what they mean. Being generous I would say they are referring to if the client has an invalid ssl approved on their local, in which case its a client problem. To ignore Encryption altogether is a silly idea. Maybe it shouldn't be so centralised to 1 company though.
- maratc 1y ago
  My IT department performs a man-in-the-middle attack against all my VPN traffic, and issues on-the-fly certificates for all the sites I visit. There is zero warning on my side, and the only way I know of it is because I'm a nerd who looks into certificate chains sometimes. My other nerd coworkers are blissfully unaware. EDIT: I understand how it works. This wasn’t my point.
  - akerl_ 1y ago
    This only works because you company's endpoints have been configured to trust the company's root CA. Which makes sense, because it's their device and their VPN.
  - keepamovin 1y ago
    Yes, but if you use HSTS a regular browser will flag that. Perhaps your browser is also "MITM"d via a management policy? hehe :S
woodruffw 1y ago
> Not this time. The technical problems are easy to solve. For decades, users of SSH have had a system (save the certificate permanently the first time you connect, and warn if it ever changes) that is optimal in a sense: it works at least as well as any other solution. It's trivial to implement, is completely free, involves no third parties, and lasts forever. To the surprise of absolutely no one, web browsers don't support it. This is completely backwards: TOFU schemes aren't acceptable for the public web because the average user (1) isn't equipped to compare certificate fingerprints for their bank, and (2) shouldn't be exposed to any MITM risk because they forget to. The entire point of a public key infrastructure like the Web PKI is to ensure that technical and non-technical people alike get transport security. (The author appears to unwittingly concede this point with the SSH comparison -- asking my grandparents to learn SSH's host pinning behavior to manage their bank accounts would be elder abuse. It works great for nerds, and terribly for everyone else.)
- ericbarrett 1y ago
  Does it even work great for nerds? I have seen a distressing amount of turning host key warnings off, or ignoring the warnings forever, or replacing a host key without any curiosity or investigation. Seems even worse in the cloud, where systems change a lot.
  - woodruffw 1y ago
    > Does it even work great for nerds? No, but I was extending a charitable amount of credulousness :-)
  - Spivak 1y ago
    I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Just scream if it ever changes. I get that they're expecting me to compare it to something out of band but nobody does that.
    - blenderob 1y ago
      > I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Why is it reasonable to trust the key on first use? What if the first use itself has a man-in-the-middle that presents you the middle-man's key? Why should I trust it on first use? How do I tell if the key belongs to the real website or to a middle-man website?
ozgrakkurt 1y ago
Super informative, always seemed like http is fine unless you are doing something security critical. But even blogs use https.
- gjsman-1000 1y ago
  ...because most people re-use the same password across all websites, despite decades of begging them not to. In which case, do you want a blog exposing their password in plaintext? Nobody does; so there's very little to lose by also encrypting.
  - topaz0 1y ago
    why would you need a password to view a blog
    - Avamander 1y ago
      To log in and create a new blogpost?
    - gjsman-1000 1y ago
      To leave a comment with a consistent identity
- codethief 1y ago
  > always seemed like http is fine But it's really not, as countless comments here in this thread have correctly pointed out.
1718627440 1y ago
> The official way to renew Let's Encrypt certificates is automatically, with a tool called certbot. It downloads a bunch of untrusted data from the web, and then feeds that data into your web server, all as root. Why would you run certbot as root? You don't do that with any other server.
- jval43 1y ago
  It used to be the case that you had to run certbot as root or it just wouldn't work. At least not officially, you could get it work without root but it wasn't supported. The official docs still recommend doing so: >Certbot is most useful when run with root privileges, because it is then able to automatically configure TLS/SSL for Apache and nginx.
  - 1718627440 1y ago
    I haven't experienced that, since I prefer acmetool.
  - Avamander 1y ago
    I think I've never ran it as root since it came out by using the `webroot` method, where certbot just writes the challenges to a specified path it has access to and that's it.
sigmar 1y ago
His points aren't bad, but it seems like a great example of "perfect is the enemy of good." Let's Encrypt does an incredible amount of good by adding SSL to sites that wouldn't have had it otherwise.
- nearbuy 1y ago
  Except his points are mostly straight up factually wrong.
  - sigmar 1y ago
    It does kind of suck that Let's Encrypt is entirely funded by donations from corporations like Google and Facebook. If they pulled support what would happen? Would 92% of websites we visit get downgraded to http?[1] Also his point that it "supplants better solutions" is inarguably true. The 2010s had lots of conversations about certificate transparency and CA changes that just don't happen today because the existence of Let's Encrypt made it so easy to put a cert-signed website online. [1] of US firefox users: https://letsencrypt.org/stats/ https://letsencrypt.org/stats/
- ghusto 1y ago
  His points against LetsEncrypt are that: - It introduces an exploitable attack vector - He sees it as a Trojan Horse, and fears for what will happen in the future There are a few static sites I run where there is no exchange of information. I'm locked into ensuring certificates exist for these sites, even though there's nothing to protect (unless you count the ensuring the content is really from me as protecting something).
eimrine 1y ago
Now I know I want my weblog to be HTTP-only, let's have the balls.
philipwhiuk 1y ago
Notable prior submission: https://news.ycombinator.com/item?id=37262457 https://news.ycombinator.com/item?id=37262457 Also by the author: https://michael.orlitzky.com/articles/in_defense_of_self-signed_certificates.xhtml https://michael.orlitzky.com/articles/in_defense_of_self-sig...
NoahZuniga 1y ago
> You can make the warning go away by paying a third-party—who then pays Google—to sign your website's SSL certificate This is just not true!!!! CAs don't pay google to be in their root store. > But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too The reasoning goes that most MITM (potential) attacks are between you and your ISP. Let's encrypt can connect to the backbone basically directly, so most MITM attacks won't reach them. Also, starting on September 15, 2025 (Let's encrypt has been doing this for a while already though) all domain validation requests have to be made from multiple perspectives, making MITM attacks harder.
- nicce 1y ago
  I don’t know whether they pay for Google but Google can dictate many things; otherwise they drop certificates from Chrome and this has happened.
  - akerl_ 1y ago
    You're thinking of the CAB, which dictates which CAs are trusted. Google is a participant in that. The things they dictate are public and have to do with security requirements, not whether or not they pay Google money.
    - NoahZuniga 1y ago
      This is not true! CAB is a place where CAs and browsers agree on what the rules for CAs should be. Google, Mozilla, Microsoft and Apple all administrate their own root stores which individually decide what CAs are trusted on their platforms. Individual root stores decide on the rules for inclusion in their stores themselves, but these rules are essentially: You follow CAB rules + a few extra things. Mozilla for example requires (besides CAB rules) that whenever a CA becomes aware of an issue, they post a bug to bugzilla and get their shit together pretty quickly and keep mozilla up to date on what they're doing.
      - akerl_ 1y ago
gmuslera 1y ago
https does 2 things: encrypt the communication (self-signed certificates are good enough for this), and verify that the site you are connecting to is what it seem to be, because a certification authority trusted by your browser signed the certificate that that site presents, and it should had validated somehow that the site belongs to its rightful owner. The second part is the important one in this context, because there are ways to trick your dns resolution or ip routing. The dns resolution part is mitigated with DoH (that it also uses https with certificate), but that doesn't covers everything. It might not be so fundamental for some just browsing sites, but for the ones you send data (not just credit card info) you may run into some risks.
- 1718627440 1y ago
  Maybe it would have been better if we had encrypted only form data instead and only signed websites not encrypted them like package managers do. This also would allow caching in the network.
  - Avamander 1y ago
    We have that with Signed Exchanges. Rarely used in practice though.
- BenjiWiebe 1y ago
  Self signed certificates really aren't good enough for encryption, unless you're doing TOFU before the MITM happens. Otherwise the evil MITM can decrypt the traffic, modify/inspect it, and re-encrypt it with their own self-signed certificate, and you're none the wiser.
  - gmuslera 1y ago
    The encryption is ok, but you are not talking with the right party.
drob518 1y ago
Site is getting crushed, so I can’t access it, but upvoted for the sheer contrarian headline.
riffic 1y ago
yeah I'm taking operational sysadmin advice from someone whose site can't stand 35 minutes of HN traffic hugging.
- 1718627440 1y ago
  Working fine here. Just a bit slow.
jchw 1y ago
ACME renewal feels less like a time bomb than traditional renewal, even though it happens more often. Showing manually-renewed certs expiring as evidence for why ACME is a bad idea is literally completely backwards! > My medical opinion: if it hurts, maybe you should stop doing it. Funny enough, that's the exact opposite of the common wisdom for deployment: > If it’s painful, do it often. The idea is that if you were to wait months between deployments and do enormous deployments, there is a very good chance that you will have problems every time. First of all, if it's infrequent, you can tolerate things like downtime windows for deployment, which are unideal. Second of all, it batches tons of changes at once, which increases the chances you'll need to roll it all back. Thirdly, it makes it harder to even figure out what went wrong, since the problem-causing change could've gone in months ago. By having ACME renewel happen very often, it should become apparent very quickly when they're not working, much closer to when you made the change that broke it. I believe this is an improvement full-stop. If you want it to work even better, add alerting when the certificate gets too old and monitoring/observability on the renewal processes. That gives you multiple layers of assurance that you probably wanted to have anyways. Finally, it seems like the importance of encrypting all Internet traffic is just missing from the calculus presented here; that's just silly. I'm not going to go into it. It isn't imperative that literally every website is always encrypted all of the time, but for a multitude of reasons it is ideal if 99% of them are 99% of the time. Let's Encrypt might allow for a MitM if you can pass HTTP-01 or DNS-01 momentarily, but you know what's even easier? Just being literally anywhere in the path of someone's HTTP connection and being able to perform a MitM with having compromised nothing about the CA system or the website itself. Even if we allow for some sites to sit back on HTTP, it matters that 99% of the Internet is on HTTPS because it makes MitM attacks like this highly unattractive. This is good when you're on untrusted or potentially adversarial networks... Which is increasingly many of them. The other thing missing here is just how clever the CA system has gotten. Mozilla and Google have together made this system work surprisingly well despite its flaws. The CT system makes issuing bad certificates very unattractive, as Google and Mozilla can fiercely enforce the rules, and CT makes it nearly impossible to hide when you go against them. With CT, CAA records, and other tools available, you can at least know with damn near certainty if someone did exploit the CA system or your infrastructure and pull certificates for your properties. With these improvements, relying on the CA system doesn't feel nearly as ugly. And also, you don't necessarily need to use LE. I think LE is the most competent of the ACME providers, but many paid services provide ACME support, and ZeroSSL provides another free ACME service. Shorter lived certificates also have other benefits that are not mentioned. For example, if certificates can last 5 entire years, a revoked certificate also has to be able to last that long. This makes CRLs pretty much untenable, and forces something like OCSP, which is bad for privacy. Shorter certificate lifespans were a big part of how Firefox was able to leave OCSP behind in favor of a more advanced version of the CRL scheme, a solid win for both privacy and TLS latency. All in all, the juice is clearly worth the squeeze.
peacebeard 1y ago
SSL benefits a user entering a password on a public network. A MITM attack against your renewal does not expose your private key. I don’t think that causes the harm the article suggests.
- 1718627440 1y ago
  It however does allow to intercept all future connections to your webserver until you recognize it and publish a revocation certificate.
  - Avamander 1y ago
    No. The private key does not leave the server, you can't use the certificate without it.
    - 1718627440 1y ago
      When you MITM a certificate request the attacker can provide it's own key.
      - Avamander 1y ago
        That's not what you described though, because then you wouldn't be able to revoke it once you notice it. You can't revoke a certificate without its private key. (Then it's only the CA who could if you convince them of the misissuance. Which probably means proving current access right now and asking the CA to revoke it.) In any case if someone can become the thing you're trying to validate, be it access to an IP address or some DNS zone, you're kinda out-of-luck anyways. Though WebPKI has CT, which will give you some insight into it, unlike everything else out there.
        1718627440 1y ago
        Yeah I thought you could issue an exclusive certificate that revokes all others, guess I am wrong. > In any case if someone can become the thing you're trying to validate That's kind of the thing that certificate validation is supposed to solve, an attacker posing as you. That's why the article says it's useless in theory. In practice MITM at validation is harder than in use, but it does have issues. That's why Let's Encrypt wasn't the default model.
p0w3n3d 1y ago
Issued to: michael.orlitzky.com Issued by: - Common Name (CN) E7 - Organisation (O) Let's Encrypt By the way what is the alternative to let's encrypt nowadays for a humble blog creator?
- sigio 1y ago
  There is also ZeroSSL, buypass until recently (though they stopped this month), SSL.com Google, Actalis and others
- NoahZuniga 1y ago
  Google trust services LLC
hk1337 1y ago
I don't think anybody should go as all-in as the OP in the article but he might have some good points. Why does everything have to be https? Like, if I am writing a basic blog, with no forms, no CC payments, doesn't capture anything sensitive, why do I need an SSL certificate to appear as a valid site?
- perching_aix 1y ago
  Because I want to read your words, not whatever other person's or machine's standing between your and my machine. It's one of the key points the author takes an issue with. That PKI is not MITM resistant enough, in the ways they dream of. That they need to monitor the CT logs, and that not being a whole lot.
  - hk1337 1y ago
    That's a niche problem to have though. Most random bloggers are not going to be targets of MITM that rewrites their posts. If that becomes a problem, then sure, add HTTPS.
    - perching_aix 1y ago
      You can read about the history of the non-nicheness of this problem in other comments. It also doesn't need targeting.
- jeroenhd 1y ago
  Because your website will sell me Viagra and tell me to buy cryptocurrency when I visit it on some public wifis. Your words are also obscured by ISPs telling me that my router needs replacing and that I've nearly used up my data cap. You don't need TLS for your blog, though. Browsers will still connect to port 80 if you don't enable HTTPS.
- the_snooze 1y ago
  It's about integrity, not confidentiality. Without HTTPS, anyone between you and the server can mess with the content you're receiving. It could be injecting ads, or make the website upside-down [1], or replace downloads with malicious links. [1] https://pete.ex-parrot.com/upside-down-ternet.html https://pete.ex-parrot.com/upside-down-ternet.html
AndrewStephens 1y ago
It is a shame that HTTPS is required for sites these days but that doesn't change the fact that it really is necessary, even for the smallest of blogs. HTTPS does three interrelated things: Encryption - the data cannot be read by an intermediary, which protects your readers' privacy. You don't want people to know what pages you read on BigBank.com or EmbarassingFetish.com. Tamper Proofing - the data cannot be changed by an intermediary, which protects your readers' (and your server) from someone messing with the data, say substituting one bank account number for another when setting up a payment, etc. Site Authentication - ensures that the browser is connected to the server it says it is, which also prevents proxying. Without this an intermediary can impersonate any site. Before the big push for encrypting everything it was not uncommon to hear of ISPs inspecting all traffic to sell to advertisers, or even injecting ads directly into pages. HTTPS makes this much more difficult.
- jeroenhd 1y ago
  HTTPS is hardly required for websites. Web applications may restrict sensitive actions to HTTPS, but websites over HTTP still work fine. I try to avoid them because they allow sketchy ISPs to inject ads and other weirdness into my browser, but normal browsers will still accept HTTP by default. If you don't want people to know you're visiting EmbarrassingFetish.com, EmbarrassingFetish.com also needs to implement ECH (eSNI's replacement) and your browser must have it enabled, otherwise anyone can on the line can still sniff out what domain you're connecting to. I don't think site authentication is practical, though. For some use cases it works (i.e. validating the origin before firing off a request to a U2F/FIDO2 authenticator), but for normal users, mybank.com and securemybank.com may as well be equivalent (and some shitty important services actually use fake sounding domains like that, like PayPal for instance). Unless you remember the country and state and town your bank is registered in, even EV certificates can't help you because there can be multiple companies with the name Apple Inc. that all deserve a certificate for their website.
  - AndrewStephens 1y ago
    Hey, I only read EmbarrassingFetish.com for the recipes section (I recommend their carrot cake.) I'm not into the rest of the stuff there and you can't prove it thanks to HTTPS. More seriously, you are not wrong. Site Authentication is still a problem and actually the weakest part of HTTPS but it is also more of a people problem than a technical one. Nothing stops somebody from registering MyB4nk.com but at least HTTPS stops crooks spoofing MyBank.com exactly.
noirscape 1y ago
In general a lot of the modern HTTPS approach "feels" broken. Looking at it purely from a usability perspective, HTTPS combines two things when it really should only be doing one of them: * Encryption is the first thing HTTPS does and the one I'd argue that actually matters the most. It prevents your ISP or other middle parties from snooping or modifying what packets end up being shown to the end user. This is something that fundamentally doesn't require a CA to work. A self signed certificate is just as secure as one issued by a certificate authority on the matter of encryption; you just run an openssl command and you have a certificate, no CA needed (although a CA could still be useful for ie. Trusting updated certificates in the same chain, there's little reason to demand this to be done through a third party from a security perspective.) * The second one is identification. Basically, the certificate is meant to give the idea that the site you're visiting is trusted and verified to belong to somebody. This is what CAs provided... except in practice, CA identification guarantees basically doesn't exist anymore. Finding the entity a certificate is issued to is hard to do in modern browsers, ever since a security researcher proved that it's relatively trivial to do a name collision attack, so browser developers (aka Chrome and Mozilla) hide it behind click through windows and don't show them anymore by default. Since browsers mandate HTTPS for as many APIs as they can get away with, everyone including garden variety scammers just gets an HTTPS certificate, which utterly defeats the entire purpose. CAs are essentially sitting in the middle and unless a third party suddenly demands you get an OV/EV certificate, the argument to not just use the CA that gives literally anyone who asks a certificate after the barest minimum effort to prove they own a domain is pretty questionable. Your bank might use an OV/EV certificate, but your average person seeing the bank website will not visually see any difference between that and a scam site. Both got perfectly legitimate certificates; one just got them from LetsEncrypt instead, where they had to give no details on the certificate. Only nerds look at the difference when visiting sites, and more people than nerds use banks. Since identification is utterly dead, the entire CA structure feels like it gives little security to a modern browser as opposed to just going with a TOFU scheme like we do for SSH. Functionally, a CA ran by a sysadmin has the exact same guarantee as a CA ran by LetsEncrypt on the open internet for encryption purposes, except LE gets to be in browser and OS root programs. They might as well have the same security standards once you bring in CAA records. Final note: there's something backwards about how a plain HTTP connection just gets a small label in the browser to complain about it, while a HTTPS certificate that's a single minute out of date will lead to giant full screen red pages that you have to click through. For consistency, the HTTP page should be getting the same scare pages from an encryption perspective, but they don't.
jillesvangurp 1y ago
Messing around with certificates is indeed a bit of dreary busywork that just is the way it is because nobody seems to be around anymore to fix things properly in terms of standards. I agree with much of this article. IMHO certificates signed by a certificate certbot are only marginally more secure than a self signed certificate. Basically you can prove your domain is yours with a certificate ... by proving your domain is yours to let's encrypt via a DNS check. That sounds a bit recursive. At this point there is not a lot being checked or verified by signing authorities. IMHO the current focus on shortening certificate validity periods just highlights how inadequate certificates are and helps exactly noone stay safe. This is 100% certified a website. With a domain. Owned by somebody random on the internet. That's all that the certificate guarantees. Any scammer learned years ago how to get certificates for their scam domains. Short of blocking those domains faster than they pop up (good luck), there's no way to derive any more meaning from those certificates than "this is a website". It would help for there to be more authorities. And also to have longer expiry periods. I don't need this busywork in my life whether it's worrying about automating, monitoring, etc. or just about paying off some gate keeper for some meaningless check + bureaucracy. Longer expiry enables more strict/expensive checks to happen and browsers should be checking specific certificates against blacklists. Rotating certificates frequently makes both those things less practical and devalues the whole notion of a certificate. Any scammer will just use the same services to get the same kind of certificates. Also, the reason we can't rely on the DNS yet, is that there is still a lot of legacy software relying on non secure ways to talk to the DNS. And that being a bit of infrastructure that predates the whole notion of having certificates also means that the biggest risk is a lot of legacy insecure DNS infrastructure that is easy to spoof and can't be trusted. Anyone see a problem with that and how certificates are issued? Otherwise, we could just stick our public keys in there and self sign our own certificates. But secure DNS is a prerequisite.
jesprenj 1y ago
I agree that HTTPS is not needed in most cases but ACME challenge to obtain a LE cert can be done securely: * domain has DNSSEC * domain has CAA records only allowing DNS challenge and disallowing insecure HTTP challenge but if we rely on DNSSEC we can just use DANE/TLSA and don't need the mess of CA/PKI
- Avamander 1y ago
  > but if we rely on DNSSEC we can just use DANE/TLSA and don't need the mess of CA/PKI DNSSEC is PKI. We don't want to rely on it because it's significantly worse than WebPKI.
  - jesprenj 1y ago
    I think it is orders of magnitude better.
lanyard-textile 1y ago
Let’s Encrypt has always been a saving grace in my eyes: When it first entered the scene, it solved a problem we all loathed dealing with. So I’ve always been fond of it and never really thought twice of it. While it’s rare for companies to support a shared resource together, this was a situation where it made sense. But this is a good reminder to be wary of even the most benevolent looking tools and processes.
tasuki 1y ago
> So we're spending $3,600,000 every year on certificates that aren't any better than self-signed Gimme self-signed certificates please. With the ability to verify that the certificate was signed by whoever controls the domain I'm accessing. Abolish all certificate authorities. That's all I ask.
deleted 1y ago
[deleted]
mohammadv184 1y ago
footer is awesome.
thayne 1y ago
There is a lot of misinformation in here. For one thing the verification doesn't just make a single http request, it makes several from many different nodes. There is a risk that your hosting provider MitMs the verification, but you need some level of trust in your hosting provider anyway, and in some cases that is actually a feature, as it allows your hosting provider to manage the certificates for you. And that is one way that traditional CAs verified domain ownership for DV certs. Is it perfect? Absolutely not. Is it better than nothing? Absolutely. I do wish that DANE, or something similar had caught on. Also, if you trust Let's Encrypt to be your CA it seems very strange to consider certificates provided by them as "untrusted". Also, certbot, or many of the other options don't necessarily need to be run as root. And many webservers support getting acme certs themselves. Also, there is nothing stopping you from verifying the certs are valid before using them. Also, with a short expiration time, automation is basically required, which means that you set up the automation, and some monitoring that the renewal happens correctly, and then just let it go. And your renewal process is continually tested. With manual renewal, you have to remember to renew it, and remember how to renew it, a long time after the last time you did it. It is much more likely that you forget.
charles_f 1y ago
I remember when you had to give verisign a few 100 or thousands every year, some random dev would download the thing to their machine and circulate it by email for update. None of the competitors were cheaper either. That day wasn't either better or more secure, less so. Ironically, the solution author is pushing forward (basically self signed) is much worse to prevent mitm attacks. I somewhat agree with the precept, it's not great that the web is controlled by Google, beyond just tls certs. Something that changed since this was written is precisely that you have alternatives like zerossl. Saying that letsencrypt doesn't bring any security is plain wrong though. The OWASP top ten doesn't list certificate theft or chain of trust mitm attack, but does have a category for cryptographic failures. My hotel has full control of the wifi, but it hardly has an opportunity to mitm my chain of trust. Same goes for ISP. When you have a cert corresponding to your dns record, it at least shows that you have some control over the infra that is behind that record.
1vuio0pswjnm7 1y ago
Not every criticism of TLS is a criticism of encryption per se nor is it a plea for use of plain HTTP or other unencrypted traffic. TLS as implemented on the internet is only one way to do encryption. The use of certificates is not perfect, and arguably has scaling problems, e.g., imagine trying to use client certificates for every internet user Not every online commentator that comments on TLS is a person who writes software to be used by others by which the person obtains a commercial benefit ("developer") Some may be computer users that choose software for themselves, read source code (where possible) and even their own write software when they cannot find what they are looking for, so-called "end users" Obviously the needs of each and their relationship with "TLS" may be different What follows is not commentary from a "developer"^FN1 The CA system on which TLS relies is fundamentally flawed in several ways. Two that come to mind are 1. It invariably delegates authority to third parties. A third party ultimately decides whether A is allowed to "trust" B. What if A and B already trust each other. TLS does not care. A and B must trust a third party. A third party decides whether A and B can trust each other. This is classic Silicon Valley-style third party intermediation ("middleman") as a "business model". To add insult to injury, third party "Certificate Authorities" (CAs) are themselves self-appointed. If A and B are both end users, they do not get to choose who may become the third party. The third paty CA's have selected themselves. This self-appointment and derivation of "authority" over TLS "trust" from thin air is reminiscent of ICANN 's mysterious "authority" over "the" DNS. As it happens this is the source of fundamental flaw #2 This is not to say that there are never cases where using a third party may be useful. But TLS does not anticipate that there are _ever_ cases where a third party is not needed. It does not recognise the autonomy of A and B to make their own decisions in those situations, for example to function as their own CAs. It effectively (not actually) denies A and B the _option_ of relying on each other instead of a third party. TLS as implemented on the internet effectively (not actually) makes use of third parties _mandatory_ for everyone in every situation Why would A or B ever want to manage trust themselves For one, because unfortunately third party-mediated encryption is not always in the best interests of both parties to the transmission. Every sender that a third party CA or leaf "trusts" is not necessarily a sender that the recipient "trusts", e.g., where the sender is an ad server Similarly every receiver that a third party CA or leaf "trusts" may not be a receiver that the sender "trusts" , e.g., where the receiver is a tracking server or a so-called "tech" company that performs telemetry, data collection and surveillance in order to offer targeted ad services As a result, corporations for example must terminate TLS and perform "TLS inspection" to monitor TLS traffic in real-time traversing their own networks 2. The "CA system", specifically basic "validation", relies on another third party middleman, ICANN. Specifically, it relies on ICANN DNS. As above, like Silicon Valley's CAs, ICANN is self-appointed and derives its "authority" over domainnames from thin air. As with CAs, ICANN obtains (large) commercial benefit from operating as a third party intermediary, in this case between end users and domainnames. The idea that contributing to ICANN and registering a domainname through an ICANN-approved domainname registrar creates a level of "trust" that no end user can _ever_ achieve for themselves is laughable For example https://www.csoonline.com/article/3516343/tls-security-subverted-due-to-ca-use-of-outdated-whois-servers.html https://www.csoonline.com/article/3516343/tls-security-subve... These third party middleman approaches may be popular with developers who themselves aspire to profit from intermediation. But consider that developers do not always understand how stuff works For example, some developers publishing unsolicited "advice" to others believe DNSSEC encrypts DNS queries https://www.xda-developers.com/reasons-host-your-own-dns-server-home/ https://www.xda-developers.com/reasons-host-your-own-dns-ser... NB. This comment is not about the existence or non-existence of workarounds, e.g., Let's Encrypt, or internet usage patterns, e.g., everyone uses X, no one uses Y, and so on. It is, like the OP, about flaws that exist in TLS It is also about the fact that TLS as implemented by developers generally makes no allowance for end users who want encrypt transmissions without using third party imtermediaries, e.g., no third party CA-signed certificates, no ICANN DNS domainnames. In some circumstances, A and B might wish to operate their own CAs only for themselves and use their own DNS nameservers only for themselves, serving their own domainnames from their own root zone files. TLS as implemented actively tries to prevent TLS usage without third parties Let's Encrypt seems to exist because some agree that use of TLS as implemented on the internet should be free. This comment is based on a similar belief: It should be both free to use (payment optional) _and_ not mediated by third parties unless the parties to the transmission actually want to use them (third parties optional) FN1. For example, the top comment is a developer perspective. It refers to "excessive advertising" as if to imply some amount of advertising is not "excessive". It points to potential competition between developers over inserting advertising into web pages as a justification for use of TLS, e.g., competition between ISPs versus so-called "tech" companies should be resolved in favour of the so-called "tech" companies. But it fails to account for end user perspectives, e.g., zero tolerance for advertising from any third party, be it ISP, so-called "tech" company or anyone else, including TLS-protected data collection, telemetry and surveillance by these third parties
deleted 1y ago
[deleted]
cptskippy 1y ago
TLS certs use to be about Identity as much as they were about encryption. There was a pay wall to being able to have encrypted communications with clients that was the equivalent of a colonoscopy over fax machine. Today that takes the form of EV Certs. Let's Encrypt democratized encryption but not identity. Going back back to HTTP would allow for communications to be monitored by any intermediary and would be a huge step backwards in terms of privacy. Advertisers or Adversaries wouldn't need to compromise the client or the server to track you. Just ask AT&T nicely or compell Cloudflare via secret warrant. Anonymous encryption is essential to the freedom of communication. Identity is a wholly different problem that should be solved without being tightly coupled to encryption. And at the end of the day it's still only as reliable as the host server.
zerof1l 1y ago
How do these articles keep getting to the front of HN... > The certificates provide no security: The way you verify your identity to Let's Encrypt... you place a file somewhere on your website, and they access > Automatic renewal is insecure: certbot ... downloads a bunch of untrusted data from the web, and then feeds that data into your web server, all as root... False, this is NOT the only way. You can do it by setting a TXT DNS record. No files involved. Your server communicates with the registrar through API over an encrypted connection. > Manual renewal isn't free... You're not supposed to manually review Let's Encrypt in the first place. The whole point is that you set up cron job once and forget about it. > HTTPS is a trap: Once you've moved your websites to HTTPS, there's no going back to plain HTTP... Not true. You can run HTTP version of your website in parallel if you so desire. > Let's Encrypt is founded on the benevolence of scoundrels: Let's Encrypt isn't free to run, either. Their 2019 operating budget is 3.6 million U.S. dollars. Most of that is donated by… guess who? _Your competitors_[1]. EFF and Mozilla foundation are not my competitors LOL. [1] https://www.abetterinternet.org/sponsors/ https://www.abetterinternet.org/sponsors/ >It's bad engineering: When you install a certificate with a three-month expiration... https://letsencrypt.org/2015/11/09/why-90-days https://letsencrypt.org/2015/11/09/why-90-days https://letsencrypt.org/2025/01/16/6-day-and-ip-certs https://letsencrypt.org/2025/01/16/6-day-and-ip-certs
- M95D 1y ago
  > You can do it by setting a TXT DNS record. You can, but there is no way to force a method. A MitM attacker will choose the file method to get itself a cert for your site - the main argument in the article. > The whole point is that you set up cron job once and forget about it. Exactly. (Italics by me.) >> HTTPS is a trap: Once you've moved your websites to HTTPS, there's no going back to plain HTTP... > Not true. You can run HTTP version of your website in parallel if you so desire. But never again HTTP-only. No visitors will load HTTP. Did you actually read the article and the arguments?? > [1] I'd like to see some numbers before I belive your argument. > https://letsencrypt.org/2025/01/16/6-day-and-ip-certs https://letsencrypt.org/2025/01/16/6-day-and-ip-certs So that absolutely no human ever checks the transparency log. I can't even find that log for LetsEncrypt, let alone how to search it for my website's certs.
mzajc 1y ago
> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. For anyone interested in robustly mitigating this, there's CAA records and RFC 8657: https://acme-lecaa.charlotte.edu/ https://acme-lecaa.charlotte.edu/

111 points by todsacerdoti 1y ago

polaris421 1y ago

Funny how we're all securing our websites with time bombs that need defusing every 90 days.

sschueller 1y ago
It's going to be less very soon, they are talking about 14 days...
- NoahZuniga 1y ago
  42 days

deleted 1y ago

[deleted]

jjgreen 1y ago

Heh, that page "Verified by Let's Encrypt"

croes 1y ago
> Update 2023-11-05 Yeah, I've got an LE cert now. And I don't want to talk about it.
- dijit 1y ago
  The ironic observation about the page using an LE cert is fantastic; Browser mandates make the encryption discussion moot. If you don't use it, your argument literally won't load for a modern audience. It speaks to the problem of digital decay. We can still pull up a plain HTTP site from 1995, but a TLS site from five years ago is now often broken or flagged as "insecure" due to aggressive deprecation cycles. The internet is becoming less resilient. And this has real, painful operational consequences. For sysadmins, this is making iDRAC/iLO annoying again. (for those who don't know what iDRAC/iLO are, it's the out-of-band management controller that let you access a server's console (KVM) even when the OS is toast. The shift from requiring crappy, insecure Java Web Start (JWS) to using HTML5 was a massive win for security and usability - old school sysadmins might remember keeping some crappy insecure browser around (maybe on a bastion host) to interact with these things because they wouldn't load on modern browsers after 6mo) Now, the SSL/TLS push is undoing that. Since the firmware on these embedded controllers can't keep pace with Chrome's release schedule, the controllers' older, functional certificates are rejected. The practical outcome is that we are forced to maintain an old, insecure browser installation just to access critical server hardware again. We traded one form of operational insecurity (Java's runtime) for another (maintaining a stale browser) all because a universal security policy fails to account for specialised, slow-to-update infrastructure... I can already hear the thundering herd approaching me: "BUT YOU NEED FIRMWARE UPDATES" or "YOU NEED TO DEPRECATE YOUR FIRMWARES IF NOT SUPPORTED".. completely tone-deaf to the environments, objectives and realities where these things operate.
  - notatoad 1y ago
    >if you don't use it, your argument literally won't load for a modern audience this is just a flat-out lie. yes, modern browsers will stilll load websites over http. come on.
    - dijit 1y ago
      Like all things, it's complicated. Direct sites will load with a "Not Secure" warning, includes on the site might not load without chrome://settings/content/insecureContent And of course: you won't manage to be visible to Google itself, as you'll be down-ranked for not having TLS. If you happen to have a .dev domain: you're on the HSTS Preload list, so your site literally won't load.
      - dragonwriter 1y ago
        > And of course: you won't manage to be visible to Google itself, as you'll be down-ranked for not having TLS. You’ll be visible to Google (otherwise there would be nothing to downrank), you will just be less visible on Google.
    - lanyard-textile 1y ago
      And your ISP will be happy to show pop-up advertisements all over your HTTP website. And you, the owner, will likely be to blame by the user.
      - AntronX 1y ago
        What first world ISP does this?
        sambaumann 1y ago
        It's not worth it to them precisely because the vast majority of web traffic is served over HTTPS. You can bet they would these days if most traffic was HTTP
        1y ago
- _def 1y ago
  That quote is the only thing you have to read of that article besides the headline.

moralestapia 1y ago

This reads like satire but ... it isn't?

ocdtrekkie 1y ago
The entire behavior of the PKI regime seems like satire, but here we are. A massive amount of fragility introduced to the Internet to basically protect a few edge cases while not addressing any real practical attacks. It's been six years, this author is still right, and now the idiots at the CA/B have decided to move the bomb to a 47 day timer for the whole Internet.
- PaulHoule 1y ago
  You could tell many different stories for how we got from a world where people made their own web sites to one where people just post on Facebook, but the transition to https is part of that story.
- akerl_ 1y ago
  MITM of unencrypted HTTP was so common that it was outright a business model for many ISPs. Anybody could look up a guide online on how to monitor who at their starbucks was logging into Facebook or whatever. We were having to train a generation of humans to be afraid of public wifi.
  - 1718627440 1y ago
    > it was outright a business model for many ISPs. I'm not sure if I would object to that if it would be used sparsely and you could opt out.
    - akerl_ 1y ago
      It was not and you could not.
- colonial 1y ago
  My dude, before HTTPS, anyone could go to a Starbucks and skim every customer's Facebook session with a free Firefox extension. That's not an "edge case."

NegativeK 1y ago

This article feels like an opinion piece with an axiom of perfection or nothing.

rini17 1y ago
Sure let's eat crap without complaint, nothing is perfect anyway. /s
llm_nerd 1y ago
Indeed, their main grip seems to be with DV, and they seem to hold only EV certs as legitimate. They miss the entire value proposition and purpose of DVs. MITM is a user->service concern. If someone is between a service and LE, there are much bigger problems.
- Joker_vD 1y ago
  EV certs seem to have basically the same verification policies that CAs had for ordinary certificates back in the early 2000s (i.e., really not that much at all), so I am intrigued as to what the DV has to offer except "it's basically self-signed but with extra steps and the rest of the world will trust it". > If someone is between a service and LE There is always someone there: my ISP, my government that monitors my ISP, the LE's ISP, and the US government that monitors the LE's ISP.
- Ajedi32 1y ago
  Certainly a MITM between a website and LE is less likely than a MITM between a user on a random public Wi-Fi network and the website, but I've often wondered why more attention hasn't been given to securing the domain validation process itself. There are a lot of random internet routers between CAs and websites which effectively have the ability to get certificates for any domain they want. It just seems like such an obvious vulnerability I'm kinda shocked it hasn't been exploited yet. Perhaps the fact that it hasn't is a sign such an attack is more difficult than my intuition suggests. Still, I'd be a lot more comfortable if DNSSEC or an equivalent were enforced for domain validation. Or perhaps if we just cut out the middleman and built a PKI directly into the DNS protocol, similar to how DANE or Namecoin work.

zygentoma 1y ago

(2019)

DarkmSparks 1y ago

Tbh completely agree. But also, There is no choice now. Best we can do is encourage people to use web browsers that let people visit http sites, and afaik, that doesn't exist anymore.

1718627440 1y ago
Which browser doesn't?
- DarkmSparks 1y ago
  None of them do as far as I know, they all indicate/imply any http site is serving malware for the last few years.
  - 1718627440 1y ago
    I use Mozilla Firefox and have never experienced that. It's a bit seldom to find websites not automatically redirecting to https:// though. You can try http://repo.mysql.com/ http://repo.mysql.com/ . Sure, the browser has that icon in the URL bar saying that the connection is unsecure. It does also show a big warning, if something with the certificate is wrong and enforces HSTS (which I don't like). But an unencrypted connection works just fine. I'm not using other browsers often, so I my perception is maybe skewed, but I wouldn't have expected them to block http and if I would see that, I would perceive that as a bug.
majewsky 1y ago
So this page does not open for you? http://neverssl.com/ http://neverssl.com/
- DarkmSparks 1y ago
  https://i.ibb.co/FC6pPK5/Screenshot-20251016-032648-Vivaldi.jpg https://i.ibb.co/FC6pPK5/Screenshot-20251016-032648-Vivaldi....

thenthenthen 1y ago

https://archive.is/yLVhD https://archive.is/yLVhD (Hugs)

riffic 1y ago
static hosting is the way to go in 2025 if anyone is looking to avoid sudden traffic spikes taking down a questionably configured WordPress.
- perching_aix 1y ago
  If they have a funny bone available, they should host it using Cloudflare Pages, just to really dot the i and cross the t on the hilarity of their intentional or not hypocrisy of using TLS, and specifically Let's Encrypt as their CA, since.

VikRubenfeld 1y ago

This just can't be true. There's no way no one noticed this before. https can't be this dumb.

nhumrich 1y ago
It's not. Certs are designed to protect the average user from MitM, not to protect corporations from it.
- 1718627440 1y ago
  They do protect corporations, because they can just let there certificate be actually validated of band.
mikeocool 1y ago
I think their critique is that to verify domain ownership, Let's Encrypt makes a request to your website over HTTP to the check the challenge -- which is true (because if you don't yet have an SSL certificate they can't make a request over HTTPS). I think they are implying that if someone can man in the middle your website, then they can also man in the middle this request, and issue a certificate for you domain. However, the threat model of man in the middle between a user and your web server is very different than man in the middle between let's encrypt and your web server. Before that widespread use of HTTPS it was trivial to connect to a coffeeshop's wifi network and sniff everyone else's traffic, and ISPs would man in the middle you to inject their own adds in websites you were looking at. On the other hand to man in the middle Let's Encrypt -> your web server, you likely need to be state level actor and/or be or have hacked a major telecom (assuming your web server is running in a reputable data center). Folks like that can almost certainly already issue a certificate for your domain without running a man in the middle on Let's Encrypt.

eduction 1y ago

Chesterton's Fence - why did everyone start encyrpting their websites? His critiques of why LE is flawed security wise are spot on and I suspect something like SSH keys as he suggests would be pretty much as good. But there's a reason we're encrypting everything, and the time when we started encrypting offers a clue as to why. Mass surveillance threat actors are not going to go to the trouble and visibility of MITMing every cert connection, but they will (and in the case of NSA did) happily go to the trouble of hoovering up network traffic en masse and watching how people surf. HTTPS provides some protection there because it at least hides the paths to the specific pages you are reading as you surf online, including things like search engine query terms. The idea that $3.6m is a lot of money to encrypt a huge chunk of web traffic, or that Google is eagerly guarding the money it makes (?) off web certs, which must be a tiny fraction of its actual income, is a clue that this is maybe not a greedy conspiracy.

SoftTalker 1y ago
> why did everyone start encyrpting their websites Because Google forced us to, by throwing up scary warnings if we didn't do it. Google doesn't care about $3.6mm. They do care about the additional control they have by this scheme. > [HTTPS] at least hides the paths to the specific pages you are reading as you surf online, including things like search engine query terms. This assumes there isn't a secret firehose feed from Google to the NSA, which I don't think is a safe assumption.
- philistine 1y ago
  What control does it give them? I'm far more amenable to the idea that Google didn't want ISPs to start injecting ads on websites. If that is control for Google in your view, then my interests aligned with Google for once in a blue moon.
grepps09 1y ago
Very much agree on the last point. Controlling the de facto CA for all non-corporate web sites still gives Google a lot of control over who gets to be visible on the Internet, and that’s where the value in LE is. The direct income from SSL certs are completely insignificant.

AntronX 1y ago

> Update 2023-11-05 Yeah, I've got an LE cert now. And I don't want to talk about it. Please do tell. I'm curious what forced him to join The Borg.

jrockway 1y ago

I think that if we didn't do TLS, every ISP would be injecting ads into websites these days. Making it difficult for middle-of-the-road interlopers is a good thing. ISPs don't want the customer service burden of proxy configurations and custom certs (god knows your IT department hates the support aspect of this tampering), so TLS keeps us free of excessive advertising. (Of course, they like do tampering with DNS which is why we have to do DNS-over-HTTPS. If you make it easy to tamper with your traffic, your ISP has a good business case to tamper with your traffic. Sad but true.) I'm not as convinced as the author is that nation states can easily tamper with certificates these days. I am not sure how much CT checking we do before each page load, but either nation states are compelling the issue of certs that aren't in the CT database, or they are and you can just get a list of who the nation states are spying on. Seems like less of a problem than it was a decade ago. The author seems to miss the one guarantee that certificates provide; "the same people that controlled this site on $ISSUANCE_DATE control the site right now". That can be a useful guarantee.

pavel_lishin 1y ago
We had this happen to us at work, once. We were working on some feature for a client's website, and suddenly things started breaking. We eventually tracked it down to some shoddy HTML + Javascript being on our page that we certainly didn't put there, and further investigation revealed that our ISP - whom we were paying for a business connection - was just slapping a fucking banner ad on most of the pages that were being served. This was around ... 2008? I wonder if they were injecting it into AJAX responses, too. My boss called them up and chewed them several new assholes, and the banner was gone by afternoon.
- jabroni_salad 1y ago
  My ISP (Mediacom) appears to have a deal with certain websites to display service messages. The only two I've encountered it on is Amazon and Facebook but they are somehow able to insert a maintenance banner at the top of those two when downtime is anticipated or if I am near the end of my bandwidth quota. Haven't gotten any ads this way but they have the technology.

1718627440 1y ago

> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. In other words, Let's Encrypt certificates don't stop the one thing they're supposed to stop. But the certificate is signed with the key of Let's Encrypt and your own, both of which the private key never leave the server.

Spivak 1y ago
Also MITMing a user is much easier than MITMing Let's Encrypt themselves who perform multiple checks from different locations.
bilekas 1y ago
Yeah it reads as if the OP misunderstands the attack vectors of SSL. If there's a misconfiguration, or the server admin is not correctly authenticating the authority, then sure. But skips over what they mean. Being generous I would say they are referring to if the client has an invalid ssl approved on their local, in which case its a client problem. To ignore Encryption altogether is a silly idea. Maybe it shouldn't be so centralised to 1 company though.
maratc 1y ago
My IT department performs a man-in-the-middle attack against all my VPN traffic, and issues on-the-fly certificates for all the sites I visit. There is zero warning on my side, and the only way I know of it is because I'm a nerd who looks into certificate chains sometimes. My other nerd coworkers are blissfully unaware. EDIT: I understand how it works. This wasn’t my point.
- akerl_ 1y ago
  This only works because you company's endpoints have been configured to trust the company's root CA. Which makes sense, because it's their device and their VPN.
- keepamovin 1y ago
  Yes, but if you use HSTS a regular browser will flag that. Perhaps your browser is also "MITM"d via a management policy? hehe :S

woodruffw 1y ago

> Not this time. The technical problems are easy to solve. For decades, users of SSH have had a system (save the certificate permanently the first time you connect, and warn if it ever changes) that is optimal in a sense: it works at least as well as any other solution. It's trivial to implement, is completely free, involves no third parties, and lasts forever. To the surprise of absolutely no one, web browsers don't support it. This is completely backwards: TOFU schemes aren't acceptable for the public web because the average user (1) isn't equipped to compare certificate fingerprints for their bank, and (2) shouldn't be exposed to any MITM risk because they forget to. The entire point of a public key infrastructure like the Web PKI is to ensure that technical and non-technical people alike get transport security. (The author appears to unwittingly concede this point with the SSH comparison -- asking my grandparents to learn SSH's host pinning behavior to manage their bank accounts would be elder abuse. It works great for nerds, and terribly for everyone else.)

ericbarrett 1y ago
Does it even work great for nerds? I have seen a distressing amount of turning host key warnings off, or ignoring the warnings forever, or replacing a host key without any curiosity or investigation. Seems even worse in the cloud, where systems change a lot.
- woodruffw 1y ago
  > Does it even work great for nerds? No, but I was extending a charitable amount of credulousness :-)
- Spivak 1y ago
  I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Just scream if it ever changes. I get that they're expecting me to compare it to something out of band but nobody does that.
  - blenderob 1y ago
    > I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Why is it reasonable to trust the key on first use? What if the first use itself has a man-in-the-middle that presents you the middle-man's key? Why should I trust it on first use? How do I tell if the key belongs to the real website or to a middle-man website?

ozgrakkurt 1y ago

Super informative, always seemed like http is fine unless you are doing something security critical. But even blogs use https.

gjsman-1000 1y ago
...because most people re-use the same password across all websites, despite decades of begging them not to. In which case, do you want a blog exposing their password in plaintext? Nobody does; so there's very little to lose by also encrypting.
- topaz0 1y ago
  why would you need a password to view a blog
  - Avamander 1y ago
    To log in and create a new blogpost?
  - gjsman-1000 1y ago
    To leave a comment with a consistent identity
codethief 1y ago
> always seemed like http is fine But it's really not, as countless comments here in this thread have correctly pointed out.

1718627440 1y ago

> The official way to renew Let's Encrypt certificates is automatically, with a tool called certbot. It downloads a bunch of untrusted data from the web, and then feeds that data into your web server, all as root. Why would you run certbot as root? You don't do that with any other server.

jval43 1y ago
It used to be the case that you had to run certbot as root or it just wouldn't work. At least not officially, you could get it work without root but it wasn't supported. The official docs still recommend doing so: >Certbot is most useful when run with root privileges, because it is then able to automatically configure TLS/SSL for Apache and nginx.
- 1718627440 1y ago
  I haven't experienced that, since I prefer acmetool.
- Avamander 1y ago
  I think I've never ran it as root since it came out by using the `webroot` method, where certbot just writes the challenges to a specified path it has access to and that's it.

sigmar 1y ago

His points aren't bad, but it seems like a great example of "perfect is the enemy of good." Let's Encrypt does an incredible amount of good by adding SSL to sites that wouldn't have had it otherwise.

nearbuy 1y ago
Except his points are mostly straight up factually wrong.
- sigmar 1y ago
  It does kind of suck that Let's Encrypt is entirely funded by donations from corporations like Google and Facebook. If they pulled support what would happen? Would 92% of websites we visit get downgraded to http?[1] Also his point that it "supplants better solutions" is inarguably true. The 2010s had lots of conversations about certificate transparency and CA changes that just don't happen today because the existence of Let's Encrypt made it so easy to put a cert-signed website online. [1] of US firefox users: https://letsencrypt.org/stats/ https://letsencrypt.org/stats/
ghusto 1y ago
His points against LetsEncrypt are that: - It introduces an exploitable attack vector - He sees it as a Trojan Horse, and fears for what will happen in the future There are a few static sites I run where there is no exchange of information. I'm locked into ensuring certificates exist for these sites, even though there's nothing to protect (unless you count the ensuring the content is really from me as protecting something).

eimrine 1y ago

Now I know I want my weblog to be HTTP-only, let's have the balls.

philipwhiuk 1y ago

Notable prior submission: https://news.ycombinator.com/item?id=37262457 https://news.ycombinator.com/item?id=37262457 Also by the author: https://michael.orlitzky.com/articles/in_defense_of_self-signed_certificates.xhtml https://michael.orlitzky.com/articles/in_defense_of_self-sig...

NoahZuniga 1y ago

> You can make the warning go away by paying a third-party—who then pays Google—to sign your website's SSL certificate This is just not true!!!! CAs don't pay google to be in their root store. > But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too The reasoning goes that most MITM (potential) attacks are between you and your ISP. Let's encrypt can connect to the backbone basically directly, so most MITM attacks won't reach them. Also, starting on September 15, 2025 (Let's encrypt has been doing this for a while already though) all domain validation requests have to be made from multiple perspectives, making MITM attacks harder.

nicce 1y ago
I don’t know whether they pay for Google but Google can dictate many things; otherwise they drop certificates from Chrome and this has happened.
- akerl_ 1y ago
  You're thinking of the CAB, which dictates which CAs are trusted. Google is a participant in that. The things they dictate are public and have to do with security requirements, not whether or not they pay Google money.
  - NoahZuniga 1y ago
    This is not true! CAB is a place where CAs and browsers agree on what the rules for CAs should be. Google, Mozilla, Microsoft and Apple all administrate their own root stores which individually decide what CAs are trusted on their platforms. Individual root stores decide on the rules for inclusion in their stores themselves, but these rules are essentially: You follow CAB rules + a few extra things. Mozilla for example requires (besides CAB rules) that whenever a CA becomes aware of an issue, they post a bug to bugzilla and get their shit together pretty quickly and keep mozilla up to date on what they're doing.
    - akerl_ 1y ago

gmuslera 1y ago

https does 2 things: encrypt the communication (self-signed certificates are good enough for this), and verify that the site you are connecting to is what it seem to be, because a certification authority trusted by your browser signed the certificate that that site presents, and it should had validated somehow that the site belongs to its rightful owner. The second part is the important one in this context, because there are ways to trick your dns resolution or ip routing. The dns resolution part is mitigated with DoH (that it also uses https with certificate), but that doesn't covers everything. It might not be so fundamental for some just browsing sites, but for the ones you send data (not just credit card info) you may run into some risks.

1718627440 1y ago
Maybe it would have been better if we had encrypted only form data instead and only signed websites not encrypted them like package managers do. This also would allow caching in the network.
- Avamander 1y ago
  We have that with Signed Exchanges. Rarely used in practice though.
BenjiWiebe 1y ago
Self signed certificates really aren't good enough for encryption, unless you're doing TOFU before the MITM happens. Otherwise the evil MITM can decrypt the traffic, modify/inspect it, and re-encrypt it with their own self-signed certificate, and you're none the wiser.
- gmuslera 1y ago
  The encryption is ok, but you are not talking with the right party.

drob518 1y ago

Site is getting crushed, so I can’t access it, but upvoted for the sheer contrarian headline.

riffic 1y ago

yeah I'm taking operational sysadmin advice from someone whose site can't stand 35 minutes of HN traffic hugging.

1718627440 1y ago
Working fine here. Just a bit slow.

jchw 1y ago

ACME renewal feels less like a time bomb than traditional renewal, even though it happens more often. Showing manually-renewed certs expiring as evidence for why ACME is a bad idea is literally completely backwards! > My medical opinion: if it hurts, maybe you should stop doing it. Funny enough, that's the exact opposite of the common wisdom for deployment: > If it’s painful, do it often. The idea is that if you were to wait months between deployments and do enormous deployments, there is a very good chance that you will have problems every time. First of all, if it's infrequent, you can tolerate things like downtime windows for deployment, which are unideal. Second of all, it batches tons of changes at once, which increases the chances you'll need to roll it all back. Thirdly, it makes it harder to even figure out what went wrong, since the problem-causing change could've gone in months ago. By having ACME renewel happen very often, it should become apparent very quickly when they're not working, much closer to when you made the change that broke it. I believe this is an improvement full-stop. If you want it to work even better, add alerting when the certificate gets too old and monitoring/observability on the renewal processes. That gives you multiple layers of assurance that you probably wanted to have anyways. Finally, it seems like the importance of encrypting all Internet traffic is just missing from the calculus presented here; that's just silly. I'm not going to go into it. It isn't imperative that literally every website is always encrypted all of the time, but for a multitude of reasons it is ideal if 99% of them are 99% of the time. Let's Encrypt might allow for a MitM if you can pass HTTP-01 or DNS-01 momentarily, but you know what's even easier? Just being literally anywhere in the path of someone's HTTP connection and being able to perform a MitM with having compromised nothing about the CA system or the website itself. Even if we allow for some sites to sit back on HTTP, it matters that 99% of the Internet is on HTTPS because it makes MitM attacks like this highly unattractive. This is good when you're on untrusted or potentially adversarial networks... Which is increasingly many of them. The other thing missing here is just how clever the CA system has gotten. Mozilla and Google have together made this system work surprisingly well despite its flaws. The CT system makes issuing bad certificates very unattractive, as Google and Mozilla can fiercely enforce the rules, and CT makes it nearly impossible to hide when you go against them. With CT, CAA records, and other tools available, you can at least know with damn near certainty if someone did exploit the CA system or your infrastructure and pull certificates for your properties. With these improvements, relying on the CA system doesn't feel nearly as ugly. And also, you don't necessarily need to use LE. I think LE is the most competent of the ACME providers, but many paid services provide ACME support, and ZeroSSL provides another free ACME service. Shorter lived certificates also have other benefits that are not mentioned. For example, if certificates can last 5 entire years, a revoked certificate also has to be able to last that long. This makes CRLs pretty much untenable, and forces something like OCSP, which is bad for privacy. Shorter certificate lifespans were a big part of how Firefox was able to leave OCSP behind in favor of a more advanced version of the CRL scheme, a solid win for both privacy and TLS latency. All in all, the juice is clearly worth the squeeze.

peacebeard 1y ago

SSL benefits a user entering a password on a public network. A MITM attack against your renewal does not expose your private key. I don’t think that causes the harm the article suggests.

1718627440 1y ago
It however does allow to intercept all future connections to your webserver until you recognize it and publish a revocation certificate.
- Avamander 1y ago
  No. The private key does not leave the server, you can't use the certificate without it.
  - 1718627440 1y ago
    When you MITM a certificate request the attacker can provide it's own key.
    - Avamander 1y ago
      That's not what you described though, because then you wouldn't be able to revoke it once you notice it. You can't revoke a certificate without its private key. (Then it's only the CA who could if you convince them of the misissuance. Which probably means proving current access right now and asking the CA to revoke it.) In any case if someone can become the thing you're trying to validate, be it access to an IP address or some DNS zone, you're kinda out-of-luck anyways. Though WebPKI has CT, which will give you some insight into it, unlike everything else out there.
      - 1718627440 1y ago
        Yeah I thought you could issue an exclusive certificate that revokes all others, guess I am wrong. > In any case if someone can become the thing you're trying to validate That's kind of the thing that certificate validation is supposed to solve, an attacker posing as you. That's why the article says it's useless in theory. In practice MITM at validation is harder than in use, but it does have issues. That's why Let's Encrypt wasn't the default model.

p0w3n3d 1y ago

Issued to: michael.orlitzky.com Issued by: - Common Name (CN) E7 - Organisation (O) Let's Encrypt By the way what is the alternative to let's encrypt nowadays for a humble blog creator?

sigio 1y ago
There is also ZeroSSL, buypass until recently (though they stopped this month), SSL.com Google, Actalis and others
NoahZuniga 1y ago
Google trust services LLC

hk1337 1y ago

I don't think anybody should go as all-in as the OP in the article but he might have some good points. Why does everything have to be https? Like, if I am writing a basic blog, with no forms, no CC payments, doesn't capture anything sensitive, why do I need an SSL certificate to appear as a valid site?

perching_aix 1y ago
Because I want to read your words, not whatever other person's or machine's standing between your and my machine. It's one of the key points the author takes an issue with. That PKI is not MITM resistant enough, in the ways they dream of. That they need to monitor the CT logs, and that not being a whole lot.
- hk1337 1y ago
  That's a niche problem to have though. Most random bloggers are not going to be targets of MITM that rewrites their posts. If that becomes a problem, then sure, add HTTPS.
  - perching_aix 1y ago
    You can read about the history of the non-nicheness of this problem in other comments. It also doesn't need targeting.
jeroenhd 1y ago
Because your website will sell me Viagra and tell me to buy cryptocurrency when I visit it on some public wifis. Your words are also obscured by ISPs telling me that my router needs replacing and that I've nearly used up my data cap. You don't need TLS for your blog, though. Browsers will still connect to port 80 if you don't enable HTTPS.
the_snooze 1y ago
It's about integrity, not confidentiality. Without HTTPS, anyone between you and the server can mess with the content you're receiving. It could be injecting ads, or make the website upside-down [1], or replace downloads with malicious links. [1] https://pete.ex-parrot.com/upside-down-ternet.html https://pete.ex-parrot.com/upside-down-ternet.html

AndrewStephens 1y ago

It is a shame that HTTPS is required for sites these days but that doesn't change the fact that it really is necessary, even for the smallest of blogs. HTTPS does three interrelated things: Encryption - the data cannot be read by an intermediary, which protects your readers' privacy. You don't want people to know what pages you read on BigBank.com or EmbarassingFetish.com. Tamper Proofing - the data cannot be changed by an intermediary, which protects your readers' (and your server) from someone messing with the data, say substituting one bank account number for another when setting up a payment, etc. Site Authentication - ensures that the browser is connected to the server it says it is, which also prevents proxying. Without this an intermediary can impersonate any site. Before the big push for encrypting everything it was not uncommon to hear of ISPs inspecting all traffic to sell to advertisers, or even injecting ads directly into pages. HTTPS makes this much more difficult.

jeroenhd 1y ago
HTTPS is hardly required for websites. Web applications may restrict sensitive actions to HTTPS, but websites over HTTP still work fine. I try to avoid them because they allow sketchy ISPs to inject ads and other weirdness into my browser, but normal browsers will still accept HTTP by default. If you don't want people to know you're visiting EmbarrassingFetish.com, EmbarrassingFetish.com also needs to implement ECH (eSNI's replacement) and your browser must have it enabled, otherwise anyone can on the line can still sniff out what domain you're connecting to. I don't think site authentication is practical, though. For some use cases it works (i.e. validating the origin before firing off a request to a U2F/FIDO2 authenticator), but for normal users, mybank.com and securemybank.com may as well be equivalent (and some shitty important services actually use fake sounding domains like that, like PayPal for instance). Unless you remember the country and state and town your bank is registered in, even EV certificates can't help you because there can be multiple companies with the name Apple Inc. that all deserve a certificate for their website.
- AndrewStephens 1y ago
  Hey, I only read EmbarrassingFetish.com for the recipes section (I recommend their carrot cake.) I'm not into the rest of the stuff there and you can't prove it thanks to HTTPS. More seriously, you are not wrong. Site Authentication is still a problem and actually the weakest part of HTTPS but it is also more of a people problem than a technical one. Nothing stops somebody from registering MyB4nk.com but at least HTTPS stops crooks spoofing MyBank.com exactly.

noirscape 1y ago

In general a lot of the modern HTTPS approach "feels" broken. Looking at it purely from a usability perspective, HTTPS combines two things when it really should only be doing one of them: * Encryption is the first thing HTTPS does and the one I'd argue that actually matters the most. It prevents your ISP or other middle parties from snooping or modifying what packets end up being shown to the end user. This is something that fundamentally doesn't require a CA to work. A self signed certificate is just as secure as one issued by a certificate authority on the matter of encryption; you just run an openssl command and you have a certificate, no CA needed (although a CA could still be useful for ie. Trusting updated certificates in the same chain, there's little reason to demand this to be done through a third party from a security perspective.) * The second one is identification. Basically, the certificate is meant to give the idea that the site you're visiting is trusted and verified to belong to somebody. This is what CAs provided... except in practice, CA identification guarantees basically doesn't exist anymore. Finding the entity a certificate is issued to is hard to do in modern browsers, ever since a security researcher proved that it's relatively trivial to do a name collision attack, so browser developers (aka Chrome and Mozilla) hide it behind click through windows and don't show them anymore by default. Since browsers mandate HTTPS for as many APIs as they can get away with, everyone including garden variety scammers just gets an HTTPS certificate, which utterly defeats the entire purpose. CAs are essentially sitting in the middle and unless a third party suddenly demands you get an OV/EV certificate, the argument to not just use the CA that gives literally anyone who asks a certificate after the barest minimum effort to prove they own a domain is pretty questionable. Your bank might use an OV/EV certificate, but your average person seeing the bank website will not visually see any difference between that and a scam site. Both got perfectly legitimate certificates; one just got them from LetsEncrypt instead, where they had to give no details on the certificate. Only nerds look at the difference when visiting sites, and more people than nerds use banks. Since identification is utterly dead, the entire CA structure feels like it gives little security to a modern browser as opposed to just going with a TOFU scheme like we do for SSH. Functionally, a CA ran by a sysadmin has the exact same guarantee as a CA ran by LetsEncrypt on the open internet for encryption purposes, except LE gets to be in browser and OS root programs. They might as well have the same security standards once you bring in CAA records. Final note: there's something backwards about how a plain HTTP connection just gets a small label in the browser to complain about it, while a HTTPS certificate that's a single minute out of date will lead to giant full screen red pages that you have to click through. For consistency, the HTTP page should be getting the same scare pages from an encryption perspective, but they don't.

jillesvangurp 1y ago

Messing around with certificates is indeed a bit of dreary busywork that just is the way it is because nobody seems to be around anymore to fix things properly in terms of standards. I agree with much of this article. IMHO certificates signed by a certificate certbot are only marginally more secure than a self signed certificate. Basically you can prove your domain is yours with a certificate ... by proving your domain is yours to let's encrypt via a DNS check. That sounds a bit recursive. At this point there is not a lot being checked or verified by signing authorities. IMHO the current focus on shortening certificate validity periods just highlights how inadequate certificates are and helps exactly noone stay safe. This is 100% certified a website. With a domain. Owned by somebody random on the internet. That's all that the certificate guarantees. Any scammer learned years ago how to get certificates for their scam domains. Short of blocking those domains faster than they pop up (good luck), there's no way to derive any more meaning from those certificates than "this is a website". It would help for there to be more authorities. And also to have longer expiry periods. I don't need this busywork in my life whether it's worrying about automating, monitoring, etc. or just about paying off some gate keeper for some meaningless check + bureaucracy. Longer expiry enables more strict/expensive checks to happen and browsers should be checking specific certificates against blacklists. Rotating certificates frequently makes both those things less practical and devalues the whole notion of a certificate. Any scammer will just use the same services to get the same kind of certificates. Also, the reason we can't rely on the DNS yet, is that there is still a lot of legacy software relying on non secure ways to talk to the DNS. And that being a bit of infrastructure that predates the whole notion of having certificates also means that the biggest risk is a lot of legacy insecure DNS infrastructure that is easy to spoof and can't be trusted. Anyone see a problem with that and how certificates are issued? Otherwise, we could just stick our public keys in there and self sign our own certificates. But secure DNS is a prerequisite.

jesprenj 1y ago

I agree that HTTPS is not needed in most cases but ACME challenge to obtain a LE cert can be done securely: * domain has DNSSEC * domain has CAA records only allowing DNS challenge and disallowing insecure HTTP challenge but if we rely on DNSSEC we can just use DANE/TLSA and don't need the mess of CA/PKI

Avamander 1y ago
> but if we rely on DNSSEC we can just use DANE/TLSA and don't need the mess of CA/PKI DNSSEC is PKI. We don't want to rely on it because it's significantly worse than WebPKI.
- jesprenj 1y ago
  I think it is orders of magnitude better.

lanyard-textile 1y ago

Let’s Encrypt has always been a saving grace in my eyes: When it first entered the scene, it solved a problem we all loathed dealing with. So I’ve always been fond of it and never really thought twice of it. While it’s rare for companies to support a shared resource together, this was a situation where it made sense. But this is a good reminder to be wary of even the most benevolent looking tools and processes.

tasuki 1y ago

> So we're spending $3,600,000 every year on certificates that aren't any better than self-signed Gimme self-signed certificates please. With the ability to verify that the certificate was signed by whoever controls the domain I'm accessing. Abolish all certificate authorities. That's all I ask.

deleted 1y ago

[deleted]

mohammadv184 1y ago

footer is awesome.

thayne 1y ago

There is a lot of misinformation in here. For one thing the verification doesn't just make a single http request, it makes several from many different nodes. There is a risk that your hosting provider MitMs the verification, but you need some level of trust in your hosting provider anyway, and in some cases that is actually a feature, as it allows your hosting provider to manage the certificates for you. And that is one way that traditional CAs verified domain ownership for DV certs. Is it perfect? Absolutely not. Is it better than nothing? Absolutely. I do wish that DANE, or something similar had caught on. Also, if you trust Let's Encrypt to be your CA it seems very strange to consider certificates provided by them as "untrusted". Also, certbot, or many of the other options don't necessarily need to be run as root. And many webservers support getting acme certs themselves. Also, there is nothing stopping you from verifying the certs are valid before using them. Also, with a short expiration time, automation is basically required, which means that you set up the automation, and some monitoring that the renewal happens correctly, and then just let it go. And your renewal process is continually tested. With manual renewal, you have to remember to renew it, and remember how to renew it, a long time after the last time you did it. It is much more likely that you forget.

charles_f 1y ago

I remember when you had to give verisign a few 100 or thousands every year, some random dev would download the thing to their machine and circulate it by email for update. None of the competitors were cheaper either. That day wasn't either better or more secure, less so. Ironically, the solution author is pushing forward (basically self signed) is much worse to prevent mitm attacks. I somewhat agree with the precept, it's not great that the web is controlled by Google, beyond just tls certs. Something that changed since this was written is precisely that you have alternatives like zerossl. Saying that letsencrypt doesn't bring any security is plain wrong though. The OWASP top ten doesn't list certificate theft or chain of trust mitm attack, but does have a category for cryptographic failures. My hotel has full control of the wifi, but it hardly has an opportunity to mitm my chain of trust. Same goes for ISP. When you have a cert corresponding to your dns record, it at least shows that you have some control over the infra that is behind that record.

1vuio0pswjnm7 1y ago

Not every criticism of TLS is a criticism of encryption per se nor is it a plea for use of plain HTTP or other unencrypted traffic. TLS as implemented on the internet is only one way to do encryption. The use of certificates is not perfect, and arguably has scaling problems, e.g., imagine trying to use client certificates for every internet user Not every online commentator that comments on TLS is a person who writes software to be used by others by which the person obtains a commercial benefit ("developer") Some may be computer users that choose software for themselves, read source code (where possible) and even their own write software when they cannot find what they are looking for, so-called "end users" Obviously the needs of each and their relationship with "TLS" may be different What follows is not commentary from a "developer"^FN1 The CA system on which TLS relies is fundamentally flawed in several ways. Two that come to mind are 1. It invariably delegates authority to third parties. A third party ultimately decides whether A is allowed to "trust" B. What if A and B already trust each other. TLS does not care. A and B must trust a third party. A third party decides whether A and B can trust each other. This is classic Silicon Valley-style third party intermediation ("middleman") as a "business model". To add insult to injury, third party "Certificate Authorities" (CAs) are themselves self-appointed. If A and B are both end users, they do not get to choose who may become the third party. The third paty CA's have selected themselves. This self-appointment and derivation of "authority" over TLS "trust" from thin air is reminiscent of ICANN 's mysterious "authority" over "the" DNS. As it happens this is the source of fundamental flaw #2 This is not to say that there are never cases where using a third party may be useful. But TLS does not anticipate that there are _ever_ cases where a third party is not needed. It does not recognise the autonomy of A and B to make their own decisions in those situations, for example to function as their own CAs. It effectively (not actually) denies A and B the _option_ of relying on each other instead of a third party. TLS as implemented on the internet effectively (not actually) makes use of third parties _mandatory_ for everyone in every situation Why would A or B ever want to manage trust themselves For one, because unfortunately third party-mediated encryption is not always in the best interests of both parties to the transmission. Every sender that a third party CA or leaf "trusts" is not necessarily a sender that the recipient "trusts", e.g., where the sender is an ad server Similarly every receiver that a third party CA or leaf "trusts" may not be a receiver that the sender "trusts" , e.g., where the receiver is a tracking server or a so-called "tech" company that performs telemetry, data collection and surveillance in order to offer targeted ad services As a result, corporations for example must terminate TLS and perform "TLS inspection" to monitor TLS traffic in real-time traversing their own networks 2. The "CA system", specifically basic "validation", relies on another third party middleman, ICANN. Specifically, it relies on ICANN DNS. As above, like Silicon Valley's CAs, ICANN is self-appointed and derives its "authority" over domainnames from thin air. As with CAs, ICANN obtains (large) commercial benefit from operating as a third party intermediary, in this case between end users and domainnames. The idea that contributing to ICANN and registering a domainname through an ICANN-approved domainname registrar creates a level of "trust" that no end user can _ever_ achieve for themselves is laughable For example https://www.csoonline.com/article/3516343/tls-security-subverted-due-to-ca-use-of-outdated-whois-servers.html https://www.csoonline.com/article/3516343/tls-security-subve... These third party middleman approaches may be popular with developers who themselves aspire to profit from intermediation. But consider that developers do not always understand how stuff works For example, some developers publishing unsolicited "advice" to others believe DNSSEC encrypts DNS queries https://www.xda-developers.com/reasons-host-your-own-dns-server-home/ https://www.xda-developers.com/reasons-host-your-own-dns-ser... NB. This comment is not about the existence or non-existence of workarounds, e.g., Let's Encrypt, or internet usage patterns, e.g., everyone uses X, no one uses Y, and so on. It is, like the OP, about flaws that exist in TLS It is also about the fact that TLS as implemented by developers generally makes no allowance for end users who want encrypt transmissions without using third party imtermediaries, e.g., no third party CA-signed certificates, no ICANN DNS domainnames. In some circumstances, A and B might wish to operate their own CAs only for themselves and use their own DNS nameservers only for themselves, serving their own domainnames from their own root zone files. TLS as implemented actively tries to prevent TLS usage without third parties Let's Encrypt seems to exist because some agree that use of TLS as implemented on the internet should be free. This comment is based on a similar belief: It should be both free to use (payment optional) _and_ not mediated by third parties unless the parties to the transmission actually want to use them (third parties optional) FN1. For example, the top comment is a developer perspective. It refers to "excessive advertising" as if to imply some amount of advertising is not "excessive". It points to potential competition between developers over inserting advertising into web pages as a justification for use of TLS, e.g., competition between ISPs versus so-called "tech" companies should be resolved in favour of the so-called "tech" companies. But it fails to account for end user perspectives, e.g., zero tolerance for advertising from any third party, be it ISP, so-called "tech" company or anyone else, including TLS-protected data collection, telemetry and surveillance by these third parties

deleted 1y ago

[deleted]

cptskippy 1y ago

TLS certs use to be about Identity as much as they were about encryption. There was a pay wall to being able to have encrypted communications with clients that was the equivalent of a colonoscopy over fax machine. Today that takes the form of EV Certs. Let's Encrypt democratized encryption but not identity. Going back back to HTTP would allow for communications to be monitored by any intermediary and would be a huge step backwards in terms of privacy. Advertisers or Adversaries wouldn't need to compromise the client or the server to track you. Just ask AT&T nicely or compell Cloudflare via secret warrant. Anonymous encryption is essential to the freedom of communication. Identity is a wholly different problem that should be solved without being tightly coupled to encryption. And at the end of the day it's still only as reliable as the host server.

zerof1l 1y ago

How do these articles keep getting to the front of HN... > The certificates provide no security: The way you verify your identity to Let's Encrypt... you place a file somewhere on your website, and they access > Automatic renewal is insecure: certbot ... downloads a bunch of untrusted data from the web, and then feeds that data into your web server, all as root... False, this is NOT the only way. You can do it by setting a TXT DNS record. No files involved. Your server communicates with the registrar through API over an encrypted connection. > Manual renewal isn't free... You're not supposed to manually review Let's Encrypt in the first place. The whole point is that you set up cron job once and forget about it. > HTTPS is a trap: Once you've moved your websites to HTTPS, there's no going back to plain HTTP... Not true. You can run HTTP version of your website in parallel if you so desire. > Let's Encrypt is founded on the benevolence of scoundrels: Let's Encrypt isn't free to run, either. Their 2019 operating budget is 3.6 million U.S. dollars. Most of that is donated by… guess who? _Your competitors_[1]. EFF and Mozilla foundation are not my competitors LOL. [1] https://www.abetterinternet.org/sponsors/ https://www.abetterinternet.org/sponsors/ >It's bad engineering: When you install a certificate with a three-month expiration... https://letsencrypt.org/2015/11/09/why-90-days https://letsencrypt.org/2015/11/09/why-90-days https://letsencrypt.org/2025/01/16/6-day-and-ip-certs https://letsencrypt.org/2025/01/16/6-day-and-ip-certs

M95D 1y ago
> You can do it by setting a TXT DNS record. You can, but there is no way to force a method. A MitM attacker will choose the file method to get itself a cert for your site - the main argument in the article. > The whole point is that you set up cron job once and forget about it. Exactly. (Italics by me.) >> HTTPS is a trap: Once you've moved your websites to HTTPS, there's no going back to plain HTTP... > Not true. You can run HTTP version of your website in parallel if you so desire. But never again HTTP-only. No visitors will load HTTP. Did you actually read the article and the arguments?? > [1] I'd like to see some numbers before I belive your argument. > https://letsencrypt.org/2025/01/16/6-day-and-ip-certs https://letsencrypt.org/2025/01/16/6-day-and-ip-certs So that absolutely no human ever checks the transparency log. I can't even find that log for LetsEncrypt, let alone how to search it for my website's certs.

mzajc 1y ago

> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. For anyone interested in robustly mitigating this, there's CAA records and RFC 8657: https://acme-lecaa.charlotte.edu/ https://acme-lecaa.charlotte.edu/