47 ms·

Why I no longer have an old-school cert on my HTTPS site

• moxli 1y ago
  https://archive.is/QPcLY https://archive.is/QPcLY
  • skrebbel 1y ago
    why? it isn't paywalled or something right?
    • qwertox 1y ago
      This site can’t be reached rachelbythebay.com took too long to respond.
      • luckman212 1y ago
        Site is working fine for me, East coast US.
        • rcarmo 1y ago
          Same. Europe.
    • deleted 1y ago
      [deleted]
    • neuroticnews25 1y ago
      Author blacklists some ISPs [0]: >I contacted Rachel and she said - and this is my poor paraphrasing from memory - that the IP ban was something she intentionally implemented but I got caught as a false positive [0] https://news.ycombinator.com/item?id=42599359 https://news.ycombinator.com/item?id=42599359
      • dan_hawkins 1y ago
        Yeah, I can't reach out their website from Denmark for some unknown reasons. On top of that the most recent update of their RSS feed server fxxxd up my news reader so I'm even less inclined to see whatever they do because it looks like they're not very competent technology-wise.
    • moxli 1y ago
      The page wasn't loading when I tried to open it. I thought it must be the Hacker News hug of death.
  • deleted 1y ago
    [deleted]
• neogodless 1y ago
  Oh parts of this remind me of having to write an HMAC signature for some API calls. I like to start in Postman, but the provider's supplied Postman collection was fundamentally broken. I tried and tried to write a pre-request script over a day or two, and ended up giving up. I want to get back to it, but it's frustrating because there's no feedback cycle. Every request fails with the same 401 Unauthorized error, so you are on your own for figuring out which piece of the script isn't doing quite the right thing.
• ndsipa_pomu 1y ago
  I was amazed by them having so much distrust of the various clients. Certbot is typically in the repositories for things like Debian/Ubuntu. My favourite client is probably https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh If you use a DNS service provider that supports it, you can use the DNS-01 challenge to get a certificate - that means that you can have the acme.sh running on a completely different server which should help if you're twitchy about running a complex script on it. It's also got the advantage of allowing you to get certificates for internal/non-routable addresses.
  • skywhopper 1y ago
    Certbot goes out of its way to be inscrutable about what it’s doing. It munges your web server config (temporarily) to handle http challenges, and for true sysadmins who are used to having to know all the details of what’s going on, that sort of script is a nightmare waiting to happen. I assume certbot is the client she’s alluding to that misinterprets one of the factors in the protocol as hex vs decimal and somehow things still work, which is incredibly worrisome.
    • jeroenhd 1y ago
      With the HTTP implementation that's true, but the DNS implementation of certbot's certificate request plugins don't touch your server config. As an added bonus, you can use that to also obtain wildcard certificates for your subdomains so different applications can share the same certificate (so you only need one single ACME client).
    • claudex 1y ago
      You can configure certbot to write in a directory directly and it won't touch your web server config.
    • castillar76 1y ago
      Having my ACME client munge my webserver configs to obtain a cert was one of the supreme annoyances about using them — it felt severely constraining on how I structured my configs, and even though it’s a blip, I hated the double restart required to fetch a cert (restart with new config, restart with new cert). Then I discovered the web-root approach people mention here and it made a huge difference. Now I have the HTTP snippet in my server set to serve up ACME challenges from a static directory and push everything else to HTTPS, and the ACME client just needs write permission to that directory. I can dynamically include that snippet in all of the sites my server handles and be done. If I really felt like it, I could even write a wrapper function so the ACME client doesn’t even need restart permissions on the web-server (for me, probably too much to bother with, but for someone like Rachel perhaps worthwhile).
• skywhopper 1y ago
  I identify with this so much because of my own revulsion for the ACME protocol and the available tooling for using it—and SSL tooling in general for that matter—and because this is also representative of my process for figuring out this sort of low priority technical issue that I have to understand before I can implement, in a way that clearly most folks in the industry don’t care about understanding.
• tux3 1y ago
  JOSE/JWK is indeed some galactically overengineered piece of spec, but the rest seems.. fine? There are private keys and hash functions involved. But base64url and json aren't the worst web crimes to have been inflicted upon us. It's not _that_ bad, is it?
  • oneplane 1y ago
    I personally don't see the overengineering in JOSE; as you mention, a JWK (and JWKs) is not much more than the RSA key data we already know and love but formatted for Web and HTTP. It doesn't get more reasonable than that. JWTs, same story, it's just JSON data with a standard signature. The spec (well, the RFC anyway) is indeed classically RFC-ish, but the same applies to HTTP or TCP/IP, and I haven't seen the same sort of complaints about those. Maybe it's just resistance to change? Most of the specs (JOSE, ACME etc) aren't really complex for the sake of complexity, but solve problems that aren't simple problems to solve simply in a simple fashion. I don't think that's bad at all, it's mostly indicative of the complexity of the problem we're solving.
    • lmz 1y ago
      Imagine coming from JWK and having to encode that public key into a CSR or something with that attitude.
      • oneplane 1y ago
        Imagine writing your own security software when there are proven systems that just take that problem out of your hands so you don't need to complain about it.
        • lmz 1y ago
          I'm agreeing with you that the author is complaining too much. Going the other way they would probably go "and then we have to somehow encode the numbers '1 2 840 113549 1 1' somehow to mark the key type".
• 1a527dd5 1y ago
  I don't understand the tone of aggression against ACME and their plethora of clients. I know it isn't a skill issue because of who the author is. So I can only imagine it is some sort of personal opinion that they dislike ACME as a concept or the tooling around ACME in general. We've been using LE for a while (since 2019 I think) for handful of sites, and the best nonsense client _for us_ was https://github.com/do-know/Crypt-LE/releases https://github.com/do-know/Crypt-LE/releases. Then this year we've done another piece of work this time against the Sectigo ACME server and le64 wasn't quite good enough. So we ended up trying:- - https://github.com/certbot/certbot https://github.com/certbot/certbot on GitHub Actions, it was fine but didn't quite like the locked down environment - https://github.com/go-acme/lego https://github.com/go-acme/lego huge binary, cli was interestingly designed and the maintainer was quite rude when raising an issue - https://github.com/rmbolger/Posh-ACME https://github.com/rmbolger/Posh-ACME our favourite, but we ended up going with certbot on GHA once we fixed the weird issues around permissions Edit* Re-read it. The tone isn't aimed at the ACME or the clients. It's the spec itself. ACME idea good, ACME implementation bad.
  • immibis 1y ago
    Some people don't want to be forced to run a bunch of stuff they don't understand on the server, and I agree with them. Sadly, security is a cat and mouse game, which means it's always evolving and you're forced to keep up - and it's inherent by the nature of the field, so we can't really blame anyone (unlike, say, being forced to integrate with the latest Google services to be allowed on the Play Store). At least you get to write your own ACME client if you want to. You don't have to use certbot, and there's no TPM-like behaviour locking you out of your own stuff.
    • spockz 1y ago
      Given that keys probably need to be shared between multiple gateway/ingresses, how common is it to just use some HSM or another mechanism of exchanging the keys with all the instances? The acme client doesn’t have to run on the servers itself.
      • 1y ago
• jeroenhd 1y ago
  There's something to be said for implementing stuff like this manually for the experience of having done it yourself, but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work. Kind of makes me wonder what kind of stack her website is running on that something like a lightweight ACME library (https://github.com/jmccl/acme-lw https://github.com/jmccl/acme-lw comes to mind, but there's a C++ library for ESP32s that should be even more lightweight) loading in the certificates isn't doing the job.
  • mschuster91 1y ago
    > but the author's tone makes it sound like she hates the protocol and all the extra work she needs to do to make the Let's Encrypt setup work. The problem is, SSL is a fucking hot, ossified mess. Many of the noted core issues, especially the weirdnesses around encoding and bitfields, are due to historical baggage of ASN.1/X.509. It's not fun to deal with it, at all... the math alone is bad enough, but the old abstractions to store all the various things for the math are simply constrained by the technological capabilities of the late '80s. There would have been a chance to at least partially reduce the mess with the introduction of LetsEncrypt - basically, have the protocol transmit all of the required math values in a decent form and get an x.509 cert back - and HTTP/2, but that wasn't done because it would have required redeveloping a bunch of stuff from scratch whereas one can build an ACME CA with, essentially, a few lines of shell script, OpenSSL and six crates of high proof alcohol to drink away one's frustrations of dealing with OpenSSL, and integrate this with all software and libraries that exist there.
    • jeroenhd 1y ago
      There's no easy way to "just" transmit data in a foolproof manner. You practically need to support CSRs as a CA anyway, so you might as well use the existing ASN.1+X509 system to transmit data. ASN.1 and X509 aren't all that bad. It's a comprehensively documented binary format that's efficient and used everywhere, even if it's hidden away in binary protocols you don't look at every day. Unlike what most people seem to think, ACME isn't something invented just for Let's Encrypt. Let's Encrypt was certainly the first high-profile CA to implement the protocol, but various CAs (free and paid) have their own ACME servers and have had them for ages now. It's a generic protocol for certificate authorities to securely do domain validation and certificate provisioning that Let's Encrypt implemented first. The unnecessarily complex parts of the protocol when writing a from-the-ground-up client are complex because ACME didn't reinvent the wheel, and reused existing standard protocols instead. Unfortunately, that means having to deal with JWS, but on the other hand, it means most people don't need to write their own ACME-JWS-replacement-protocol parsers. All the other parts are complex because the problem ACME is solving is actually quite complex. The author wrote [another post](https://rachelbythebay.com/w/2023/01/03/ssl/ https://rachelbythebay.com/w/2023/01/03/ssl/) about the time they fell for the lies of a CA that promised an "easier" solution. That solution is pretty much ACME, but with more manual steps (like registering an account, entering domain names). I personally think that for this (and for many other protocols, to be honest) XML would've been a better fit as its parsers are more resilient against weird data, but these days talking about XML will make people look at you like you're proposing COBOL. Hell, I even exchanging raw, binary ASN.1 messages would probably have gone over pretty well, as you need ASN.1 to generate the CSR and request the certificate anyway. But, people chose "modern" JSON instead, so now we're base64 encoding values that JSON parsers will inevitably fuck up instead.
• z3t4 1y ago
  At some stage you need to update your TXT records, and if you register a wildcard domain you have to do it twice for the same request! And you have to propagate these TXT records twice to all your DNS servers, and wait for some third party like google dns to request the TXT record. And it all has to be done within a minute in order to not time out. DNS servers are not made to change records from one second to another and rely heavily on caching, so I'm lucky that I run my own DNS servers, but good luck doing this if you are using something like a anycast DNS service.
  • XorNot 1y ago
    Or just use the HTTP protocol, which works fine.
    • fpoling 1y ago
      For wildcard certificates DNS is the only option.
  • castillar76 1y ago
    Fortunately that’s only needed if you’re using the DNS validation method — necessary if you’re getting wildcards (but…eek, wildcards). For HTTP-01, no DNS changes are needed unless you want to add CAA records to block out other CAs.
    • elric 1y ago
      Wildcard Certificates are your friend if you don't want all of your hostnames becoming public knowledge.
      • 12_throw_away 1y ago
        Having tried it myself, I can highly recommend a security posture that doesn't depend on the secrecy of any particular URL :)
        • 1y ago
• sam_lowry_ 1y ago
  I am running an HTTP-only blog and it's getting harder every year not to switch to HTTPS. For instance, Whatsapp can not open HTTP links anymore.
  • projektfu 1y ago
    You can proxy it, which for a small server might be the best way to avoid heavy traffic, through caching at the proxy.
  • g-b-r 1y ago
    For god's sake, however complex ACME might be it's better than not supporting TLS
    • sam_lowry_ 1y ago
      Why? The days of MITM boxes injecting content into HTTP traffic are basically over, and frankly they never were a thing in my part of the world. I see no other reason to serve content over HTTPS.
      • JoshTriplett 1y ago
        > Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without understanding that immense work happened behind the scenes to avert problems.)
        • sam_lowry_ 1y ago
          How do browsers distrust HTTP, exactly?
          • castillar76 1y ago
• ThePowerOfFuet 1y ago
  With the greatest respect to Rachel, ain't _nobody_ got time for that.
• breck 1y ago
  > This complexity must be job security for somebody. Maybe multiple somebodies. This. The 90 day certs of LE are terrible (I hit 1-2 sites a week broken b/c of expired LE certs) and unnecessary, and all part of a bigger trend by big business to control more of the web. LE could be a voice for the user, but the "non-profit" pays their team ~$250K/year so they tread carefully about doing things in the average user's interests.
• egorfine 1y ago
  > import JSON (something I use as little as possible) This makes me wonder what world of development she is in. Does she prefer SOAP?
  • codeduck 1y ago
    Given her experience and work history, it's much more likely that she views any text-based protocol as an unnecessary abstraction over simply processing raw TCP.
    • horsawlarway 1y ago
      Is this a joke? I don't even know where to begin with this comment... It reads like a joke, but I suspect it's not? TCP is just a bunch of bytes... You can't process a bunch of bytes without understanding what they are, and that requires signaling information at a different level (ex - in the bytes themselves as a defined protocol like SSH, SCP, HTTP, etc - or some other pre-shared information between server and client [the worst of protocols - custom bullshit]).
      • codeduck 1y ago
        parent mentioned SOAP as an alternative to JSON. I was being glib about the fact that the engineer who wrote this blog post is a highly-regarded sysadmin and SRE who tinkers on things ranging from writing her own build systems to playing with RF equipment.
        • horsawlarway 1y ago
          Sure. Between the two comments, I think the SOAP joke is a lot better.
      • lesuorac 1y ago
        > or some other pre-shared information between server and client [the worst of protocols - custom bullshit]) Why is this worse than JSON? "{'protected': {'protected': { 'protected': 'QABE' }}}" is just as custom as 66537 imo. It's easier to reverse engineer than 66537 but that's not less custom.
• liampulles 1y ago
  I appreciate the author calling this stuff out. The increasing complexity of the protocols that the web is built on is not a problem for developers who simply need to find a tool or client to use the protocol, but it is a kind of regulatory capture that ensures only established players will be the ones able to meet the spec required to run the internet. I know ACME alone is not insurmountably complex, but it is another brick in the wall.
  • charcircuit 1y ago
    These protocols all have open source implementations. And as AI gets stronger this barrier will get smaller and smaller.
    • chrisandchris 1y ago
      So instead of designing simpler protocols (like HTTP/1.1 is), we do not care and let AI figure it out? Sounds great to me... /s
• tialaramex 1y ago
  One of the things this gestures at might as well get a brief refresher here: Subject Alternative Name (SAN) is not an alternative in the sense that it's an alias, SANs exist because the X.509 certificate standard is, as its name might suggest, intended for the X.500 directory system, a system from the 20th century which was never actually deployed. Mozilla (back then the Netscape Corporation) didn't like re-inventing wheels and this standard for certificates already existed so they used it in their new "Secure Sockets" technology but it has no Internet names so at first they just put names in plain text. However, X.500 was intended to be infinitely extensible, so we can just invent an alternative naming scheme, and that's what the SANs are, which is why they're mandatory for certificates in the Web PKI today - these are the Internet's names for things, so they're mandatory when talking about the Internet, they're described in detail in PKIX, the IETF document standardising the use of X.500 for the Internet. There are several types of name we can express as SANs but in a certificate the two you'll commonly see are dnsName - the same ASCII names you'd see in URLs like "news.ycombinator.com" or "www.google.com" and ipAddress - a 32-bit integer typically spelled as four dotted decimals 10.20.30.40 [yes or an IPv6 128-bit integer will work here, don't worry] Because the SANs aren't just free text a machine can reliably parse them which would doubtless meet Rachel's approval. The browser can mindlessly compare the bytes in the certificate "news.ycombinator.com" with the bytes in the actual DNS name it looked up "news.ycombinator.com" and those match so this cert is for this site. With free text in a CN field like a 1990s SSL certificate (or, sadly, many certificates well into the 2010s because it was difficult to get issuers to comply properly with the rules and stop spewing nonsense into CN) it's entirely possible to see a certificate for " 10.200.300.400" which well, what's that for? Is that leading space significant? Is that an IP address? But those numbers don't even fit in one byte each I hope our parser copes!
  • p_ing 1y ago
    Did browsers ever strictly require a SAN; they certainly didn't even as of ~10 years ago? Yes, it is "required", but CN only has worked for quite some time. I find this tricks up some IT admins who are still used to only supplying a CN and don't know what a SAN is.
    • 1y ago
• amiga386 1y ago
  Things change over time. Part of not wanting to let go is the sunk cost fallacy. Part of it is being suspicious of being (more) dependent on someone else (than you are already dependent on a different someone else). (As an aside, the n-gate guy who ranted against HTTPS in general and thought static content should just be HTTP also thought like that. Unfortunately, as I'm at a sketchy cafe using their wifi, his page currently says I should click here to enter my bank details, and I should download new cursors, and oddly doesn't include any of his own content at all. Bit weird, but of course I can trust he didn't modify his page, and it's just a silly unnecessary imposition on him that I would like him to use HTTPS) Unfortunately for those rugged individuals, you're in a worldwide community of people who want themselves, and you, to be dependent on someone else. We're still going with "trust the CAs" as our security model. But with certificate transparency and mandatory stapling from multiple verifiers, we're going with "trust but verify the CAs". Maximum acceptable durations for certificates are coming down, down, down. You have to get new ones sooner, sooner, sooner. This is to limit the harm a rogue CA or a naive mis-issuing CA can do, as CRLs just don't work. The only way that can happen is with automation, and being required to prove you still own a domain and/or a web-server on that domain, to a CA, on a regular basis. No "deal with this once a year" anymore. That's gone and it's not coming back. It's good to know the whole protocol, and yes certbot can be overbearing, but Debian's python3-certbot + python3-certbot-apache integrates perfectly with how Debian has set up apache2. It shouldn't be a hardship. And if you don't like certbot, there are lots of other ACME clients. And if you don't like Let's Encrypt, there are other entities offering certificates via the ACME protocol (YMMV, do you trust them enough to vouch for you?)
  • pixl97 1y ago
    > thought static content should just be HTTP Yep, I've seen that argument so many times and it should never make sense to anyone that understands MITM. The only way it could possibly work is if the static content were signed somehow, but then you need another protocol the browser and you need a way to exchange keys securely, for example like signed RPMs. It would be less expensive as the encryption happens once, but is it worth having yet another implementation?
    • 1y ago
• JackSlateur 1y ago
  [flagged]
  • deleted 1y ago
    [deleted]
• orion138 1y ago
  Not the main point of the article, but the author’s comments on Gandi made me wonder: What registrar do people recommend in 2025?
  • 0xCMP 1y ago
    I use Cloudflare for everything I can and then currently use Namecheap for anything it doesn't support. I haven't tried Porkbun mostly because I'm okay with what I have already.
  • sloped 1y ago
    Pork bun is my favorite.
    • graemep 1y ago
      It seems to be what Rachel decided on. Must be other good ones? Somewhat prefer something in the UK (but have been using Gandi so its not essential).
      • mattl 1y ago
        Gandi prices went way way up. I've been using Porkbun too.
      • jsheard 1y ago
        I don't know about the UK, but if you want to keep things in Europe then I can vouch for Netim in France. INWX in Germany also seems well regarded but I haven't used them.
    • floren 1y ago
      I've been on Namecheap for years but I'm ready to move just because they refuse to support dynamic AAAA records. How's Porkbun on that front?
      • sloped 1y ago
        Not sure, I use dnsimple for dns and wrote my own little service to update my A record, no ip6 in my corner of the world so have not checked for AAAA record support.
• bananapub 1y ago
  tangentially, for anyone looking to make their lives easier, you can run `acme-dns` on a spared 53/udp somewhere, CNAME the _acme_challenge. from your real DNS hosting to that, then have `lego` or whatever do DNS challenges via acme-dns - no need to let inscrutable scripts touch your real DNS config, no need for anything to touch your HTTP config.
  • elric 1y ago
    I wish DNS providers offered more granular access control. Some offer an API key per zone, others have a single key which grants access to every single zone in your account. I haven't come across any that offer "acme-only" APIs. It's on my long list of potential side projects, but I don't think I'll ever gey around to it
  • Arnavion 1y ago
    You can also use an NS record directly instead of CNAME'ing to a different domain.
• eadmund 1y ago
  > So, yes, instead of saying that "e" equals "65537", you're saying that "e" equals "AQAB". Aren't you glad you did those extra steps? Oh JSON. For those unfamiliar with the reason here, it’s that JSON parsers cannot be relied upon to treat numbers properly. Is 4723476276172647362476274672164762476438 a valid JSON number? Yes, of course it is. What will a JSON parser due with it? Silently truncate it to a 64-bit or 63-bit integer, or a float, probably or if you’re very lucky emit an error (a good JSON decoder written in a sane language like Common Lisp would of course just return the number, but few of us are so lucky). So the only way to reliably get large integers into and out of JSON is to encode them as something else. Base64-encoded big-endian bytes is not a terrible choice. Silently doing the wrong thing is the root of many security errors, so it not wrong to treat every number in the protocol this way. Of course, then one loses the readability of JSON. JSON is better than XML, but it really isn’t great. Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way.
  • drob518 1y ago
    Seems like a large integer can always be communicated as a vector of byte values in some specific endian order, which is easier to deal with than Base64 since a JSON parser will at least convert the byte value from text to binary for you. But yea, as a Clojure guy sexprs or EDN would be much better.
  • matja 1y ago
    Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float? It's a shame JSON parsers usually default to performance rather than correctness, by using bignums for numbers.
    • q3k 1y ago
      Have a read through RFC7159 or 8259 and despair. > This specification allows implementations to set limits on the range and precision of numbers accepted JSON is a terrible interoperability standard.
• matja 1y ago
  Lucky that 415031 is prime :) The steps described in the article sound familiar to the process done in the early 2000's, but I'm not sure why you'd want to make it hard for yourself now. I use certbot with "--preferred-challenges dns-01" and "--manual-auth-hook" / "--manual-cleanup-hook" to dynamically create DNS records, rather than needing to modify the webserver config (and the security/access risks that comes with). It just needs putting the cert/key in the right place and reloading the webserver/loadbalancer.
• deleted 1y ago
  [deleted]
• wolf550e 1y ago
  Implementing an ACME client in python using pyca/cryptography (or in Go) would be fine, but why do it in C++ ?
  • mr_toad 1y ago
    Not everyone wants to deal with maintaining Python and untold dependencies on their web server. A C++ binary often has no additional dependencies, and even if it does they’ll be dealt with by the OS package manager.
    • wolf550e 1y ago
      I think uv[1] basically solved this problem for python scripts. Go creates statically linked executables that are easy to deploy. 1 - https://docs.astral.sh/uv/guides/scripts/ https://docs.astral.sh/uv/guides/scripts/
    • fireflash38 1y ago
      Docker/podman?
      • dmitrygr 1y ago
        Not everyone wants to spin up a multi-GB container for when a 80KB C++ binary would do...
• dang 1y ago
  Related from before: Why I still have an old-school cert on my HTTPS site - https://news.ycombinator.com/item?id=34242028 https://news.ycombinator.com/item?id=34242028 - Jan 2023 (63 comments)
• Arnavion 1y ago
  If you want to actually implement an ACME client from first principles, reading the RFC (plus related RFCs for JOSE etc) is probably easier than you think. I did exactly that when I made a client for myself. I also wrote up a digested description of the issuance flow here: https://www.arnavion.dev/blog/2019-06-01-how-does-acme-v2-work/ https://www.arnavion.dev/blog/2019-06-01-how-does-acme-v2-wo... It's not a replacement for reading the RFCs, but it presents the information in the sequence that you would follow for issuance, so think of it like an index to the RFC sections.
  • distantsounds 1y ago
    [flagged]
    • tomhow 1y ago
      Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  • anishathalye 1y ago
    Implementing an ACME client is part of the final lab assignment for MIT’s security class: https://css.csail.mit.edu/6.858/2023/labs/lab5.html https://css.csail.mit.edu/6.858/2023/labs/lab5.html
    • Bluecobra 1y ago
      Nice thanks! I’ve been wanted to learn it as dealing with cert expirations every year is a pain. My guess is that we will have 24 hour certs at some point.
      • justusthane 1y ago
        I don’t know about 24 hours, but it will be 47 days in 2029.
• heraldgeezer 1y ago
  Devs need to be sysadmins also.
• donnachangstein 1y ago
  OpenBSD has a dead-simple lightweight ACME client (written in C) as part of the base OS. No need to roll your own. I understand it was created because existing alternatives ARE bloatware and against their Unixy philosophy. Perhaps the author wasn't looking hard enough. It could probably be ported with little effort.
  • zh3 1y ago
    Or uacme [0] - litle bit of C that's been running perfectly since endless battery failures with the LE python client made us look for something that would last longer. [0] https://github.com/ndilieto/uacme https://github.com/ndilieto/uacme
  • seanw444 1y ago
    Yeah, was looking for someone to comment this. I use it. Works great.
  • tialaramex 1y ago
    When I last checked this client is a classic example of OpenBSD philosophy not understanding why security is the way it is. This client really wants the easy case where the client lives on the machine which owns the name and is running the web server, and then it uses OpenBSD-specific partitioning so that elements of the client can't easily taint one another if they're defective But, the ACME protocol would allow actual air gapping - the protocol doesn't care whether the machine which needs a certificate, the machine running an ACME client, and the machine controlling the name are three separate machines, that's fine, which means if we do not use this OpenBSD all-in-one client we can have a web server which literally doesn't do ACME at all, an ACME client machine which has no permission to serve web pages or anything like that, and name servers which also know nothing about ACME and yet the whole system works. That's more effort than "I just install OpenBSD" but it's how this was designed to deliver security rather than putting all our trust in OpenBSD to be bug-free.
    • donnachangstein 1y ago
      I said it was dead-simple and you delivered a treatise describing the most complex use case possible. Then maybe it's not for you. Most software in the OpenBSD base system lacks features on purpose. Their dev team frequently rejects patches and feature requests without compelling reasons to exist. Less features means less places for things to go wrong means less chance of security bugs. It exists so their simple webserver (also in the base system) has ACME support working out of the box. No third party software to install, no bullshit to configure, everything just works as part of a super compact OS. Which to this day still fits on a single CD-ROM. Most of all no stupid Rust compiler needed so it works on i386 (Rust cannot self-host on i386 because it's so bloated it runs out of memory, which is why Rust tools are not included in i386). If your needs exceed this or you adore complexity then feel free to look elsewhere.
• stuart_real 1y ago
  [dead]
• Aachen 1y ago
  They thought it was too complex and therefore insecure so the natural solution was to roll your own implementation and now they feel comfortable running that version of it?! Edit: to be clear, I'd not be too surprised if their homegrown client survives an audit unscathed, I'm sure they're a great coder, but the odds just don't seem better than to the alternative of using an existing client that was already audited by professionals as well as other people
• anonymousiam 1y ago
  "Skip the first 00 for some inexplicable reason" is something that caught me a few months ago. I was comparing keys in a script and they did not match because of the leading 00. Does anyone know why they're there?
  • aaronmdjones 1y ago
    If the leading bit is set, it could be interpreted as a signed negative number. Prepending 00 guarantees that this doesn't happen.
    • anonymousiam 1y ago
      Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Is there some arbitrary precision library in use that forces large integers to be signed? Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the sign?
      • mras0 1y ago
        The standard format for RSA private keys is ASN.1 (https://www.rfc-editor.org/rfc/rfc8017#appendix-C https://www.rfc-editor.org/rfc/rfc8017#appendix-C) with the components encoded as INTEGERs. An INTEGER is always signed in ASN.1, so you need the leading 0 byte if the MSB of your positive number is set. OpenSSL is just dumping the raw bytes comprising the value. Tools that don't show a leading zero in this case are doing a bit more interpretation (or just treating it as an unsigned value) to show you the number you expect.
      • aaronmdjones 1y ago
        > Okay, so why isn't it done consistently? Some tools report the leading 00 and some don't. This is probably a bug (where an unsigned integer with its high bit set is not printed with a leading 00) and should be reported. Note that RSA key moduli generated by OpenSSL will always have the high bit set, and so will always have 00 prepended when you ask it to print them. The same is not necessarily true of other integers. This is trivial to demonstrate: $ while true ; do openssl genrsa 1024 2>/dev/null | openssl rsa -text 2>/dev/null | grep -A1 modulus | tail -n1 | egrep -v '^\s*00:[89abcdef]' ; done > I don't really buy this explanation. It's a very large unsigned number. Everyone knows this. Everyone knows that an RSA modulus is a very large unsigned number yes. Not everyone knows that every number is unsigned. > Is there some arbitrary precision library in use that forces large integers to be signed? OpenSSL's own BN (BigNum) library, which tests if the high bit is set in the input (line 482): https://github.com/openssl/openssl/blob/a0d1af6574ae6a0e3872d20ff302a78793c05a85/crypto/bn/bn_lib.c#L480-L502 https://github.com/openssl/openssl/blob/a0d1af6574ae6a0e3872... > Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the sign? Because the encoding doesn't care about the context. RFC 3279 specifies that the modulus and exponent are encoded as INTEGERs: https://datatracker.ietf.org/doc/html/rfc3279#section-2.3.1 https://datatracker.ietf.org/doc/html/rfc3279#section-2.3.1 ... and INTEGERs are signed (which means OpenSSL has to use signedness == SIGNED): https://learn.microsoft.com/en-us/windows/win32/seccertenroll/about-integer https://learn.microsoft.com/en-us/windows/win32/seccertenrol... Integer values are encoded into a TLV triplet that begins with a Tag value of 0x02. The Value field of the TLV triplet contains the encoded integer if it is positive, or its two's complement if it is negative. If the integer is positive but the high order bit is set to 1, a leading 0x00 is added to the content to indicate that the number is not negative. See also the canonical specification (page 15, section 8.3): https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-... This is exactly the same way that signed integers are represented in e.g. x86 (minus the leading tag and length fields) -- if the leading bit is set, the number is negative. You're right that it wouldn't change any of the key's bits, but it would change the math performed on them, in a manner that would break it.
• abujazar 1y ago
  Lost me at "make an RSA key". RSA is ancient.
  • wolf550e 1y ago
    They also support P-256 and P-384 ECDSA, but I think 4096 bit RSA is ok for account key. https://letsencrypt.org/docs/integration-guide/#supported-key-algorithms https://letsencrypt.org/docs/integration-guide/#supported-ke...
  • Slasher1337 1y ago
    yes, LetsEncrypt really should support ed25519. Sadly, they do not.
  • upofadown 1y ago
    The triangle theorem of Pythagoras is thousands of years old. Still valid. RSA ... still secure.
• jlundberg 1y ago
  acme_tiny.py is a good choice of client for anyone who don’t want to write a client from scratch — but still want to review the code.
• mcpherrinm 1y ago
  I’m the technical lead for the Let’s Encrypt SRE/infra team. So I spend a lot of time thinking about this. The salt here is deserved! JSON Web Signatures are a gnarly format, and the ACME API is pretty enthusiastic about being RESTful. It’s not what I’d design. I think a lot of that came via the IETF wanting to use other IETF standards, and a dash of design-by-committee. A few libraries (for JWS, JSON and HTTP) go a long way to making it more pleasant but those libraries themselves aren’t always that nice, especially in C. I’m working on an interactive client and accompanying documentation to help here too, because the RFC language is a bit dense and often refers to other documents too.
  • dwedge 1y ago
    What is she talking about that you have to pay for certs if you want more than 3? Am I about to get a bill for the past 5 years or did she just misunderstand?
    • deleted 1y ago
      [deleted]
    • belorn 1y ago
      to quote the article (or rather, the 2023 article which is the one mentioning the number 3). "Somehow, a couple of weeks ago, I found this other site which claimed to be better than LE and which used relatively simple HTTP requests without a bunch of funny data types." "This is when the fine print finally appeared. This service only lets you mint 90 day certificates on the free tier. Also, you can only do three of them. Then you're done. 270 days for one domain or 3 domains for 90 days, and then you're screwed. Isn't that great? " She don't mention what this "other site" is.
      • jchw 1y ago
        FWIW, it is ZeroSSL. I want there to be more major ACME providers than just LE, but I'm not sure about ZeroSSL, personally. It seems to have the same parent company as IdenTrust (HID Global Corporation). Probably a step up from Honest Achmed but recently I recall people complaining that their EV code signing certificates were not actually trusted by Windows which is... Interesting.
• dwedge 1y ago
  I really don't understand why this blog gets so much traction here. Ranting against rss scrapes, FUD about some atop vulnerability that turned out to be nothing, and thinking you have to pay for acme certs and caring about the way it's parsed?
  • AStonesThrow 1y ago
    Well, I will perhaps endure flak or downvotes for pointing a few things out, but Rachel: - Is female [TIL the term "wogrammer"] - Works for Facebook [formerly Rackspace and Google] so an undeniably Big MAMAA - Has been blogging prolifically for at least 14 years [let's call it 40 years: she admin'd a BBS at age 12] - Website is custom self-hosted; very old school and accessible; no ads or popup bullshit - Probably has more CSE/SWE experience+talent in her little pinky finger than 80% of HN commenters https://medium.com/wogrammer/rachel-kroll-7944eeb8c692 https://medium.com/wogrammer/rachel-kroll-7944eeb8c692 So I'd say that her position and experience command enough respect that we cannot judge her merely by peeking at a few trifling journal entries.
    • dwedge 1y ago
      And yet that's exactly what HN does
  • renewiltord 1y ago
    Community favourite. Once you hit a critical mass with a community you will always be read by them.
• patrickmay 1y ago
  ACME aside, I love the description of how the OP iterated to a solution via a combination of implementing simple functions and cussing. That is a beautiful demonstration of what it means to be an old school hacker.
• viraptor 1y ago
  I understand the issues listed, but some assumptions at the beginning are not really problems in practice. Or at least not of your alternative is a custom implementation. > They haven't earned the right to run with privileges for my private keys and/or ability to frob the web server (as root!) None of that is needed. You can setup the update system in isolation, redirect the required paths and copy the keys manually. None of that needs to run as root either if you can set the permissions correctly or delegate actions to other processes.
• benlivengood 1y ago
  Apache (is anyone else still using that?) now ships with an official ACME module, which is nice. Professionally it's been cert-manager. I haven't paid for a TLS certificate in almost a decade I guess.
  • wlonkly 1y ago
    The Caddy[1] webserver also has built-in ACME. It has all the problems Rachel mentioned, of course, because now it's an ACME client embedded in an even bigger piece of software, but it's handy for sure! I don't know much about Caddy scalability but it's worked great for my personal sites. [1] https://caddyserver.com/ https://caddyserver.com/
    • mholt 1y ago
      It scales to hundreds of thousands of sites.
• arkadiyt 1y ago
  > Make an RSA key of 4096 bits. Call it your personal key. This is bad advice - making a 4096 bit key slows down visitors of your website and only gives you 2048 bits of security (if someone can break a 2048 bit RSA key they'll break the LetsEncrypt intermediate cert and can MITM your site). You should use a 2048 bit leaf certificate here
  • nothrabannosir 1y ago
    Amateur question: does a 4096 not give you more security against passive capture and future decrypting? Or is the intermediate also a factor in such an async attack?
    • arkadiyt 1y ago
      > does a 4096 not give you more security against passive capture and future decrypting? If the server was using a key exchange that did not support forward secrecy then yes. But: % echo | openssl s_client -connect rachelbythebay.com:443 2>/dev/null | grep Cipher New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Cipher : ECDHE-RSA-AES256-GCM-SHA384 ^ they're using ECDHE (elliptic curve diffie hellman), which is providing forward secrecy.
      • nothrabannosir 1y ago
        I thought FS only protected other sessions from leak of your current session key. How does it protect against passive recording of the session and later attacking of the recorded session in the future?
        • arkadiyt 1y ago
          If using a non-FS key exchange (like RSA) then the value that the session key is derived from (the pre-master secret) is sent over the wire encrypted using the server's public key. If that session is recorded and in the future the server's private key is obtained, it can be used to decrypt the pre-master secret, derive the session key, and decrypt the entire session. If on the other hand you use a FS key exchange (like ECDHE), and the session is recorded, and the server's private key is obtained, the session key cannot be recovered (that's a property of ECDHE or any forward-secure key exchange), and none of the traffic is decryptable.
• jongjong 1y ago
  The whole DNS and TLS system is overcomplicated and was designed to allow a small number of orgs to dominate the internet. I've been thinking of using a Blockchain to register domain name-to-IP-address mappings in a cryptographically secure way and then writing a Chrome extension which connects to the Blockchain (to any known peer IP; it would start from a few hardcoded seed node IPs and discover more peers as is standard for most Blockchains and P2P protocols; or you could host your own blockchain node locally and use it as your personal DNS service) and then the extension can do DNS lookups on-chain. The Chrome extension could act as an alternative address bar; type the address in there and it would read the Blockchain to figure out the IP address, completely bypassing the whole mess of a DNS system and the current centralized mess of an internet... We could then store all the certs on-chain in a similar way, just make it support the bare minimum necessary to get the browser to shut up and accept the cert whilst maintaining the essential cryptographic security guarantees. It's kind of ridiculous how easy it would be, technically, to create an alternative internet and DNS system. I think there are already similar solutions like Brave browser supporting a parallel internet with .eth domains but they don't seem to get much attention. There needs to be search engines for these alternative internets to get things going. Surely once the current internet gets spammed into oblivion and becomes devoid of opportunities, there should be an incentive use create an alternative system from scratch. Surely there is a point when a network of scarce data is better than one of abundant spam data.
  • deleted 1y ago
    [deleted]
  • oasisaimlessly 1y ago
    See also: Namecoin [1], the first altcoin. [1]: https://en.wikipedia.org/wiki/Namecoin https://en.wikipedia.org/wiki/Namecoin
• mastazi 1y ago
  > About six months ago, I realized that it was probably time to get away from Gandi as a registrar and also SSL provider (reseller). I've recently heard similar takes about Gandi but I am out of the loop, can someone explain the controversy? Currently using it for one of my domains and I'd like to know more. EDIT: tried googling but results are about people whose name is either Gandi or Ghandi, could not find much about Gandi the company.
  • agarren 1y ago
    I’m seeing a lot about price hikes, new service charges, and bad customer service since the acquisition. I noticed the price hike with one of my domains through them, I paid it but was close to reconsidering. Thinking I’ll try transferring it now. https://techrights.org/n/2023/12/14/_Video_Lessons_to_be_Learned_From_Gandi_s_Death_Total_Webhostin.shtml https://techrights.org/n/2023/12/14/_Video_Lessons_to_be_Lea... https://blog.cogitactive.com/website/gandi-outrageous-price/ https://blog.cogitactive.com/website/gandi-outrageous-price/
    • mastazi 1y ago
      I see, I hadn't noticed because back when I got my domain I paid for a multi-year offer. Thanks for that, when my paid-for period ends I will look into alternatives.
• chrisweekly 1y ago
  > "So far, we have (at least): RSA keys, SHA256 digests, RSA signing, base64 but not really base64, string concatenation, JSON inside JSON, Location headers used as identities instead of a target with a 301 response, HEAD requests to get a single value buried as a header, making one request (nonce) to make ANY OTHER request, and there's more to come. We haven't even scratched the surface of creating an order, dealing with authorizations and challenges, the whole "key thumbprint" thing, what actually goes into those TXT records, and all of that other fun stuff." Yikes. It's almost unbelievable. What a colossal tangle of complexity. Thank you for sharing the fruits of your labors. Great writing style and content.
• red_admiral 1y ago
  It bugs me that we're still on RSA/4096. Ed25519 has fewer parameters to mess around with (no custom exponent or modulus), keys and signatures are shorter and have a well-defined forman (just binary data) and there's no network byte order confusion. Meanwhile, ECDSA is so complex to write that most people will get it wrong and end up with a security hole that makes the NSA happy.
• AndyMcConachie 1y ago
  My main gripe about certbot is that it requires a plugin to essentially send a SIGHUP to apache/nginx/etc. Openbsd acme-client got this right and left that functionality out of itself.
• pornel 1y ago
  The numbers are sent in this peculiar format, because that's how they are stored in the certificates (DER encoding in x509 uses big endian binary), and that's the number format that OpenSSL API uses too. It looks silly for a small value like 65537, but the protocol also needs to handle numbers that are thousands of bits long. It makes sense to consistently use the same format for all numbers instead of special-casing small values.
• greatgib 1y ago
  I was totally horrified at all the acme clients I saw that were a hell of complexity and dependencies, and installing random things from internet until I found the one acme.sh that is a breeze. You just need bash, no weird dependency, not that much complicated. Easy to manipulate.
• gr4vityWall 1y ago
  I loved how she explained it in a tutorial-like way at the end. But I didn't enjoy the disdain and the tone of the rest of the article.
• gethly 1y ago
  I too am not a fan of ACME and LE. I'd rather manually buy and activate the certificate once per year rather than deal with the "automation" that everyone is constantly overjoyed with. And that was the case for Gethly.com since the beginning. But the prices of certificates are not cheap and they provide ZERO advantage over the free LE certificates. Especially the wildcard certificates, which are the only types that make any sense whatsoever anyway. So a decisions was made to switch to LE with DNS challenge, which is the only type that supports wildcard certificates. Long story short, DNS provider had this built-in and so now it is a 50:50 automation and manual work. DNS provider sends a notification when certificate is going to expire and to get the new one and that is about it. A matter of two minutes of manual labour to sign into DNS provider's interface, copy the certificate and paste it into actively running application that then simply distributes it to all services. Longer story - doing the DNS challenge with DNS provider's API was doable, but ACME failed to detect updated records so luckily, instead of wasting time trying to get it working, DNS provider got us covered from the get-go.
• deleted 1y ago
  [deleted]
• ddtaylor 1y ago
  > Random side note: while looking at existing ACME clients, I found that at least one of them screws up their encoding of the publicExponent and ends up interpreting it as hex instead of decimal. That is, instead of 65537, aka 0x10001, it reads it as 0x65537, aka 415031! > > Somehow, this anomaly exists and apparently doesn't break anything? I haven't actually run the client in question, but I imagine people are using it since it's in apt.
• Tractor8626 1y ago
  Aren't all those complexeties come more from using c++ than acme? Is base64-encoded number really something to be mad about?
• codewiz 1y ago
  > I'm talking about wrapping jansson (a C library that handles JSON) so that it made sense in my C++ world and I could import JSON Why not just use JsonCpp then? https://github.com/open-source-parsers/jsoncpp https://github.com/open-source-parsers/jsoncpp It's a native C++ parser which is mature, actively maintained, and likely safer than a low-level C parser implementing its own string buffers.
• albina43 1y ago
  [dead]