17 ms·

Let's Encrypt's New Root and Intermediate Certificates

448 points by arkadiyt 6y ago

theknocker 6y ago
Thank you for doing this important work that now forms a critical component of my ability to serve recipes over a fucking website.
invokestatic 6y ago
ECDSA is fantastic for all the reasons touched on in this article, but I’m sure the use of NIST curves will draw some criticism. As far as I know, no cryptographer seriously believes the curves to be backdoored, but nonetheless seems to be a hot topic of online discussion. DJB lists them as “unsafe”. Of course, other curve parameters like 25519 don’t have the same widespread deployment that the NIST curves enjoy, so this is a very sensible choice.
- schoen 6y ago
  Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm actually kind of confused about exactly what would be required and exactly what the state of it is, so maybe someone can chime in -- I just know it's not ready. Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. That is, can you interactively or offline attack ECDHE, ECDSA, or both? Can you derive the private key from the public key, by inspection and calculation, by observing random signatures, by obtaining chosen signatures, or something else?
  - coder543 6y ago
    > Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm not so sure about that. https://en.wikipedia.org/wiki/Curve25519#History https://en.wikipedia.org/wiki/Curve25519#History "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" I haven't confirmed this myself, but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) supports both curve25519 and curve448. > Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. Maybe this article can provide some insight into what people are concerned about: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG Obviously, no one has proof that the NIST curves are backdoored, so who knows what kind of backdoor they would have? No one really wants to find out the hard way, though.
    - nicoburns 6y ago
      > but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use.
      - coder543 6y ago
        Could a certificate authority not have several root certificates? I really don't see any reason they would have to have only one root certificate. They could let people choose what kind of certificate they want issued to them, and the default could be whichever is most widely supported or whatever.
        CydeWeys 6y ago
        Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.
        aaronmdjones 6y ago
        People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys. Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa). Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature. The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.
        tialaramex 6y ago
  - barkingcat 6y ago
    the very nature of a backdoor prevents you from knowing the answer to your threat model questions. If no-one knows what kind of backdoor it is, how does anyone know how the attack works? The only sane approach is to assume all of the above.
    - schoen 6y ago
      I disagree: DJB and others have researched how backdoors in elliptic-curve cryptography (and other algorithms) could work. In Dual_EC_DRBG we even know exactly how they would work. While I don't believe there's any publication that explains the exact mathematics of a backdoor that could have been used in the NIST curves, I think the likely algorithmic consequences for EC security assumptions probably are understood -- just not by me. :-)
- coder543 6y ago
  Even better than curve25519, I would prefer to see the related curve448 supported. I haven't heard any reason to prefer the NIST curves when open alternatives exist. From what I understand, curve25519 is significantly faster than the NIST curves, in addition to being better understood. And it isn't just DJB speaking against the NIST curves. There's a relevant quote from Bruce Schneier here: https://en.wikipedia.org/wiki/Curve25519#History https://en.wikipedia.org/wiki/Curve25519#History The only real advantage I know of with the NIST curves is that they might be more widely supported, which you mentioned, and which is all the more reason why it would be good for an organization like Let's Encrypt to push the industry forward with regards to curve448 support. I wouldn't mind if they offered options for what kind of certificate you would like them to issue, so people who favor NIST curves could get a certificate signed that way, and people who prefer curve25519 or curve448 could get a certificate signed that way, but I also realize that more maintenance burden is never fun. But, those are just my thoughts on the issue... maybe I'm completely wrong.
  - jopsen 6y ago
    Let's Encrypt started to make HTTPS available everywhere, and to make it free. That in its own was a revolution. I would rather seem them tread carefully, and build a reputation for reliability, than trying to push new standards. Sure LE has a place in standards discussions, as does Mozilla, but as a CA you can't just push stuff.. CAs have to be extraordinarily boring and slow. It's a trust business :)
- elmo2you 6y ago
  The reasons for using the NIST curve might have less to do with technical merits or security aspects, and more with regulations and certifications. Certifying something including cryptography already certified (NIST curve) is easier/cheaper than otherwise. As for backdoors, nobody really knows .. the nature of the algorithm itself makes it practically impossible to even detect a backdoor, even when there is one. So far, no evidence of that though. So if there is a backdoor, then whoever has knowledge of it is damned good in keeping it a secret. In my opinion a bit too good to be likely. That said, NIST has been caught before with their pants down. Rather awkward, since that's the organization supposed to certify such things. One can even wonder what worth or real meaning certifications still have, after they got caught with what they did. I'd personally consider it mostly a national US affair, but the reality is that the rest of the world is still dominated by US standards when it comes to the internet. All in all, the reasons for using the NIST curve might be more economical and people doing security by marking check boxes, rather than about actual security or efficiency.
  - slim 6y ago
    Why would they nées certification ?
    - michaelt 6y ago
      Stodgy, conservative organisations like banks and the military created the market for hardware security modules, FIPS-140 dongles, smartcards, TPMs and so on. And they couldn't care less about sticking it to the NSA by rejecting the NIST curves. Whereas if you say "government standards compliant military grade encryption" they like that a lot. If you aren't one of those organisations, but you'd still like to use a HSM/TPM/smartcard, no Curve25519 for you.
    - elmo2you 6y ago
      > Why would they nées certification ? Compliance with regulation .. things like ISO, PCI, etc.
- GordonS 6y ago
  Would be interested to know if anyone here has had customers push back about the use of ECDSA, especially those in the defence sector?
  - rkeene2 6y ago
    I haven't, though RSA is much more common EcDSA is included in NIST SP 800-73 (PIV) but I've never seen cards with it
  - user5994461 6y ago
    Working in the finance sector, I haven't seen push back because I haven't seen anybody or anything use ECDSA. ^^ Usage and support is relatively low. Most people have no idea what ECDSA is or how to use it. There are some issues in java versions (7 or 8) if you try to use ECDSA. I personally don't find the elliptic curves and parameters easy to grasp and I have a math background (multiplying large numbers was much more palatable), I think a developer would quickly hit a roadblock if they tried to work with it. Long story short. There is no benefits to ECDSA (over RSA) so there is really no reason to push for it. The only place where DSA is somewhat used is SSH keys. SSH has its own crypto routines, they've added support and pushed DSA for some time. Keys are a bit shorter so it's nicer to copy paste to github or digital ocean.
    - ferdowsi 6y ago
      ECDSA is the standard format used for WebAuthn registration/auth. It's going to become more commonplace.
- nurettin 6y ago
  I'm sure this is about the mathematical soundness of the prime numbers used in elliptic curve cryptography, but wouldn't it be much easier to access half the internet's traffic if root certificates were compromised instead?
  - deleted 6y ago
    [deleted]
  - sjwright 6y ago
    When you say access, do you mean intercept and decrypt? I’m fairly sure root certificates are only affect the browser’s trust of a server’s public key and is not involved in the security of encryption—for that you’d still need the server’s individual private key. And even then I’m still not sure if the private key is sufficient given modern encryption protocols. Hopefully someone else can chime in to elaborate here.
    - aaronmdjones 6y ago
      Regarding your last point, even if you can monitor (but not alter) all traffic on the Internet, in real-time, all of the time, forever, that does not let you decrypt any traffic (now or in the future) if the parties are using forward-secret ciphersuites (those whose key exchange is performed with ephemeral private keys, instead of the key corresponding to the public key in the certificate). At the moment, these are the DHE- and ECDHE- ciphersuites in TLS1.2 and below, and are mandatory in TLS1.3 (RSA key exchange was removed). This only becomes a concern if your adversary can alter traffic in real-time (because they can use a compromised root to obtain their own certificate for the service you're talking to, and pretend to be them to you, and you will then negotiate your keying material with them instead, which naturally gives them the ability to decrypt the traffic before forwarding it along to its intended destination). Several technologies, such as HPKP, CAA, and CT, are designed to eliminate or mitigate this.
      - tialaramex 6y ago
        Fun TLS 1.2 (and earlier) caveat: If you can obtain the theoretically short-lived but certainly not truly ephemeral STEK (Session Ticket Encryption Key) from a server, then any sessions which enabled session tickets even if those tickets were never used can be decrypted using the STEK. This doesn't work in TLS 1.3
- ilaksh 6y ago
  (Not sure people realized this is sarcasm.) Right because if they believe something crazy like there being a backdoor in something recommended by the government then people will just say they are not a real cryptographer. Because of course no part of our government ever does anything tricky like backdoors and even if one part of the government did, it could never influence another part that made recommendations to the public for what security algorithms to use. And of course anyone suggesting that such a thing might be possible is just an insane conspiracy theorist.
- tyingq 6y ago
  "As far as I know, no cryptographer seriously believes the curves to be backdoored, but nonetheless seems to be a hot topic of online discussion. DJB lists them as “unsafe”." I'm not very well educated in this space. Is DJB historically prone to exaggeration?
  - toast0 6y ago
    the NIST curves are unsafe, regardless of if they are backdoored. In order to use them safely, you have to carefully prepare your private key, because some keys are unsuitable. for curve 25519, you just need a decent secure random, all keys in the keyspace are good.
    - zimmerfrei 6y ago
      It's the other way around. NIST P curves don't require any special preparation to their private key. Curve25519 on the other hand requires a bizarre "clamping" (https://neilmadden.blog/2020/05/28/whats-the-curve25519-clamping-all-about https://neilmadden.blog/2020/05/28/whats-the-curve25519-clam...), partially because the curve has cofactor 8. Apart from clamping not being fully and clearly justified in most of the earliest specs and papers (which led to a few broken and/or insecure implementations), it makes the whole narrative of the curve being "safe" quite arguable and leaving a flavor of marketing in the mouth (NIST P curves have cofactor 1 so they are "safer" in that respect).
  - rvnx 6y ago
    "NIST promotes U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic interests of U.S. companies" I don't think it's incompatible with a backdoor. Why would they NOT backdoor it ?
    - gilrain 6y ago
      Because it would destroy their credibility in this field forever. Like, it's not impossible, but it'd have to be "burn all this accumulated trust right down" important. They can advance the US' interests in more subtle ways by just being above board. Not that that's any guarantee with this administration, of course, but in general it's sound.
- throw0101a 6y ago
  FIPS 186-5 and SP 800-186 (currently in final draft) will have new curves: > NIST is proposing updates to its standards on digital signatures and elliptic curve cryptography to align with existing and emerging industry standards. As part of these updates, NIST is proposing to adopt two new elliptic curves, Ed25519 and Ed448, for use with EdDSA. EdDSA is a deterministic elliptic curve signature scheme currently specified in the Internet Research Task Force (IRTF) RFC 8032, Edwards-Curve Digital Signature Algorithm. NIST further proposes adopting a deterministic variant of ECDSA, which is currently specified in RFC 6979, Deterministic Usage of the Digital Signature Algorithm and Elliptic Curve Digital Signature Algorithm. Finally, based on feedback received on the adoption of the current elliptic curve standards, the draft standards deprecate curves over binary fields due to their limited use by industry. * https://csrc.nist.gov/news/2019/comment-on-draft-fips-186-5-draft-sp-800-186 https://csrc.nist.gov/news/2019/comment-on-draft-fips-186-5-... I'd be curious to see if the NSA will allow them for their 'Suite B' equivalent for classified stuff.
- tialaramex 6y ago
  The only permissible keys are: RSA keys of 2048 bits or some larger multiple of 8 bits or ECDSA keys from NIST P-256, NIST P-384 or NIST P-521 curves https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/ (See section 6.1.5) Other keys violate the Baseline Requirements which are common rules agreed between the major CAs and Browser vendors. Now, a CA could choose to just disregard the BRs, but then they're automatically in violation of the root trust programme rules for the major root trust programmes - at least Microsoft, Apple, Mozilla, Google, then arguably Oracle (because Java) and some other smaller outfits. So that's probably the end of that Certificate Authority, at least for the Web PKI. Individual root programmes also have their own rules, and so in this case Mozilla's rules are important because they further restrict keys to RSA or ECDSA P-256 or P-384 only. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ https://www.mozilla.org/en-US/about/governance/policies/secu... (section 5.1 this time) Now, those are just policies, you can change policies, but that's not up to Let's Encrypt. If you believe Mozilla needs to support Curve 25519 then that's a bunch of software development you can volunteer to do, followed by lobbying all their competitors because it's futile if only Firefox supports it anyway.
- colmmacc 6y ago
  In modern times, the keys on a SSL certificate don't directly encrypt the session key used to protect communications between your browser and web-server. Instead the key only signs the diffie-helman share that a web server uses. Web-server operators are free to use 25519 for their ECDH shares if they want to, the curve used there does not have to match the certificate's curve. Even if the NIST curves are backdoored, the backdoor wouldn't be able to passively decrypt TLS sessions. At best it might allow someone with knowledge of the backdoor to impersonate a web-server, but that's an active attack and it would be very risky for the attacker. They'd run a huge risk of disclosing their back door capability.
  - coder543 6y ago
    Can you link to a config example for nginx for what you’re describing in your first paragraph? Or a web framework in any language? I’ve never seen that done before, where the DH shares don’t match the certificate type. But, I’m definitely not an expert on the low level details of TLS.
    - wolf550e 6y ago
      All your DH shares don't match the certificate type already because you use ECDH with either NIST P-256 or X25519 and you likely use an RSA certificate. The two asymmetric systems (one for key exchange and one for authentication) have nothing to do with each other, you can mix and match them freely (e.g. post-quantum key exchange experiments ran by google and cloudflare). The nginx config to specify the curve (using its openssl name) is this: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ecdh_curve https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_...
  - tlb 6y ago
    Active attacks are effective and not that risky. For most web services, the attacker only needs to intercept a single transaction in order to get the session cookies and then you are pwned. Since they only need one, they can hit you with a DNS cache poisoning attack and simultaneous clickjacking attack while you're on a public WiFi. In general, I'm skeptical of any "this attack isn't really practical" arguments. They have a way of becoming practical enough for high-value targets, so it's not something I want to use.
hashamali 6y ago
> For the last five years, Let’s Encrypt has had one root: the ISRG Root X1, which has a 4096-bit RSA key and is valid until 2035. Somewhat tangential, but what happens to all active certificates when the root key expires?
- axaxs 6y ago
  They all become untrusted, if the verifier does their job. That said, a root doesn't issue site level certificates, so the intermediates and issued certs themselves would expire first.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- LeonM 6y ago
  CAs simply never sign a cert with an expiry longer than their own root cert. Thus, by the time the root cert expires, all client certs will already be expired.
- masklinn 6y ago
  > what happens to all active certificates when the root key expires? They expire, but normally the CA wouldn't issue certificates outliving their root. It can be a concern for legacy devices whose trust store doesn't get updated, but really no more so than any other cert expiration or revocation.
- deleted 6y ago
  [deleted]
- akadruid1 6y ago
  This actually happened recently and some older stuff stopped working. there's a write up here: https://www.namecheap.com/blog/sectigo-ssl-certificate-root-expiration-issue/ https://www.namecheap.com/blog/sectigo-ssl-certificate-root-...
GordonS 6y ago
From the article I can see that using ECDSA instead of RSA could save up to 400 bytes per connection - that's nice. Aside from certificate and key size, my understanding is that ECDSA is less computationally intense than RSA, but this gets only a brief mentioned in the article - does anyone know how CPU use compares for typical setup of a TLS connection for ECDSA vs RSA?
- arkadiyt 6y ago
  Here's a 2017 Cloudflare blog post that compares the performance of ECDSA sign and verify operations (using 256 bit keys) against RSA sign and verify operations (using 2048 and 3072 bit keys) on various CPU architectures: https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/
  - zepearl 6y ago
    Questions: - Do the graphs mean that the "sign" operation of OpenSSL when using ECDSA is many times faster and the "verify" operation is ~4 times slower (compared to RSA)? - I suppose that "sign" is linked to issuing certificates, while "verify" would be involved to checking certificates? (sorry, I'm not a pro with this stuff)
    - wbl 6y ago
      You are exactly correct on both points!
    - toast0 6y ago
      If it were just checking and issuing certificates, faster signing and slower verifying would be a bad tradeoff, since certificates are issued once and used many times; certificate size benefits notwithstanding. The really nice thing performance wise is that when sending a certificate via TLS, you need to sign the TLS exchange up to that point. Making that faster means you can support a lot more connection handshakes with the same server.
      - 6y ago
jng 6y ago
It would be nice if they included a TL;DR notice at the top saying: “1. If you are a user of let’s encrypt today, this announcement does not imply that you need to do anything at all, and, 2. The main thing is that new certificates are shorter and will take up less bandwidth, plus also safer.” In any case, thanks for the great, free service!
- colesantiago 6y ago
  I agree, I wish articles like this at the very least summarised their article first before going into a deep technical rabbit hole.
- edoceo 6y ago
  Side note: a TLDR at the top is called a BLUF = Bottom Line, Up Front. https://en.m.wikipedia.org/wiki/BLUF_(communication) https://en.m.wikipedia.org/wiki/BLUF_(communication)
  - pfundstein 6y ago
    A TLDR is traditionally at the bottom, but there's no rule against putting it at the top.
  - cortesoft 6y ago
    But no one knows what that means, so you would have to explain the whole thing every time you use it, defeating the purpose of a short acronym. Say tl;dr in the first sentence and everyone knows what it means.
    - NovemberWhiskey 6y ago
      >But no one knows what that means ... anyone with writing experience in the military knows what that means.
      - frogamic 6y ago
        So still relatively few people.
anderspitman 6y ago
I don't want to go too far OT, but had a question if someone wouldn't mind answering it or pointing me to some materials. I've been digging into DNS and TLS lately. Given the way ACME works (essentially using DNS to verify you own a domain before giving you a cert), what's the reason you can't just put your public key in a DNS record? I'm assuming it has something to do with security issues at the DNS level, but don't really know.
- jcrawfordor 6y ago
  This is basically the idea behind DANE. The problem is that DNS was historically unauthenticated and so just as vulnerable to on-path attacks as HTTP - perhaps more so due to the distributed, hierarchical nature which enables certain types of takeovers. DANE assumes that DNSSEC is in place, so that the DNS records are authenticated. This allows the DNS records to be used to deliver TLS trust information in a way that is still ultimately rooted in a certificate authority (whoever operates DNSSEC for the TLD). Adoption has been limited, mostly because adoption of DNSSEC itself has been limited, arguably because DNSSEC is overcomplicated and high-maintenance, but also just due to a lack of motivation. Similarly, users couldn't care less about how TLS trust is delivered and DANE has never really gotten a big corporate champion to push for it, so there just hasn't been the drive. Industry seems to have chosen DNS-over-HTTPS as the long-term solution to many of DNS's problems, and it clashes somewhat with DANE - I'm sure you could make them work together but it would definitely become awkward
  - AndyMcConachie 6y ago
    Where DANE has seen pickup is in the SMTP space. https://stats.dnssec-tools.org/ https://stats.dnssec-tools.org/
- J0_k3r 6y ago
  I'd also like an answer for this.
- wgetch 6y ago
  What happens if both DNS requests are hijacked? Could an attacker return both a different IP and a different public key that correspond to a malicious server? Edit: I should clarify, I think the issue stems from DNS being a potential attack vector itself. You can't blindly trust what DNS tells you. This is precisely the problem that certificate chains (issued by a trusted third party) purport to resolve-- one of trust.
slim 6y ago
Let's not forget that letsencrypt is an EFF project when the shit hits the fan
- jaas 6y ago
  EFF is a strong supporter but Let's Encrypt is not an EFF project. Let's Encrypt is owned and run by Internet Security Research Group: https://www.abetterinternet.org/ https://www.abetterinternet.org/
  - slim 6y ago
    the project is older than that organisation
egberts1 6y ago
I couldn’t do OCSP stapling with my Firefox 80 against my LetsEncrypt website. Had to turn off stapling.
octorian 6y ago
I really wish Let's Encrypt had a solution for those of us with lots of "internal" devices that neither need public access nor are capable of running an automated renewal job (routers, switches, IoT gizmos, etc). All of these things come with half-baked self-signed certs, and web browsers and mobile devices these days are making it increasingly difficult to actually stomach such certs for anything at all. I wish the "SSL All The Things!" crusaders would consider this use case once in a while, and actually offer a usable solution. (Some of us could go through the trouble of setting up a private CA to deal with this issue, but getting everything to trust your own personal CA root seems like almost as much of a hassle at times.)
- ricktdotorg 6y ago
  look into Cloudflare’s cfssl. it’s really great if you just want a simple internal CA.
- arkadiyt 6y ago
  I use mkcert [1] with great success - it's easy to setup locally trusted certs which I load onto my router and other devices. [1]: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
  - wtallis 6y ago
    That seems like a nifty tool, but it doesn't seem to do anything to address the difficulty of getting your private CA trusted on more than one of your devices. I'd like to be able to access my router and switch configuration interfaces from more than one client PC, and perhaps even from a smartphone.
    - nemosaltat 6y ago
      Same here. I run OpenWRT on my home routers, and your comment prompted me to do a quick web search. uacme looks promising for luci. I’d love to hear HN experiences with it.
    - cpach 6y ago
deleted 6y ago
[deleted]
maxekman 6y ago
What a pleasure to read this post! Very well written, informative, and accessible for readers of most technical levels.
ggm 6y ago
Remembering that *.domain cannot span dots in certificates, and the consequence for SNI if you dry to use FQDN as a dot-separated space beyond the "flat" model. The convergence of certificate issuance, domain names, domain matching logic, configs, port-binding, information leakage. Its a nightmare. 5 tuple be damned: the higher protocol layers are now deciding how to de-mux your service.

448 points by arkadiyt 6y ago

Thank you for doing this important work that now forms a critical component of my ability to serve recipes over a fucking website.

invokestatic 6y ago

ECDSA is fantastic for all the reasons touched on in this article, but I’m sure the use of NIST curves will draw some criticism. As far as I know, no cryptographer seriously believes the curves to be backdoored, but nonetheless seems to be a hot topic of online discussion. DJB lists them as “unsafe”. Of course, other curve parameters like 25519 don’t have the same widespread deployment that the NIST curves enjoy, so this is a very sensible choice.

schoen 6y ago
Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm actually kind of confused about exactly what would be required and exactly what the state of it is, so maybe someone can chime in -- I just know it's not ready. Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. That is, can you interactively or offline attack ECDHE, ECDSA, or both? Can you derive the private key from the public key, by inspection and calculation, by observing random signatures, by obtaining chosen signatures, or something else?
- coder543 6y ago
  > Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm not so sure about that. https://en.wikipedia.org/wiki/Curve25519#History https://en.wikipedia.org/wiki/Curve25519#History "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" I haven't confirmed this myself, but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) supports both curve25519 and curve448. > Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. Maybe this article can provide some insight into what people are concerned about: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG Obviously, no one has proof that the NIST curves are backdoored, so who knows what kind of backdoor they would have? No one really wants to find out the hard way, though.
  - nicoburns 6y ago
    > but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use.
    - coder543 6y ago
      Could a certificate authority not have several root certificates? I really don't see any reason they would have to have only one root certificate. They could let people choose what kind of certificate they want issued to them, and the default could be whichever is most widely supported or whatever.
      - CydeWeys 6y ago
        Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.
      - aaronmdjones 6y ago
        People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys. Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa). Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature. The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.
        tialaramex 6y ago
- barkingcat 6y ago
  the very nature of a backdoor prevents you from knowing the answer to your threat model questions. If no-one knows what kind of backdoor it is, how does anyone know how the attack works? The only sane approach is to assume all of the above.
  - schoen 6y ago
    I disagree: DJB and others have researched how backdoors in elliptic-curve cryptography (and other algorithms) could work. In Dual_EC_DRBG we even know exactly how they would work. While I don't believe there's any publication that explains the exact mathematics of a backdoor that could have been used in the NIST curves, I think the likely algorithmic consequences for EC security assumptions probably are understood -- just not by me. :-)
coder543 6y ago
Even better than curve25519, I would prefer to see the related curve448 supported. I haven't heard any reason to prefer the NIST curves when open alternatives exist. From what I understand, curve25519 is significantly faster than the NIST curves, in addition to being better understood. And it isn't just DJB speaking against the NIST curves. There's a relevant quote from Bruce Schneier here: https://en.wikipedia.org/wiki/Curve25519#History https://en.wikipedia.org/wiki/Curve25519#History The only real advantage I know of with the NIST curves is that they might be more widely supported, which you mentioned, and which is all the more reason why it would be good for an organization like Let's Encrypt to push the industry forward with regards to curve448 support. I wouldn't mind if they offered options for what kind of certificate you would like them to issue, so people who favor NIST curves could get a certificate signed that way, and people who prefer curve25519 or curve448 could get a certificate signed that way, but I also realize that more maintenance burden is never fun. But, those are just my thoughts on the issue... maybe I'm completely wrong.
- jopsen 6y ago
  Let's Encrypt started to make HTTPS available everywhere, and to make it free. That in its own was a revolution. I would rather seem them tread carefully, and build a reputation for reliability, than trying to push new standards. Sure LE has a place in standards discussions, as does Mozilla, but as a CA you can't just push stuff.. CAs have to be extraordinarily boring and slow. It's a trust business :)
elmo2you 6y ago
The reasons for using the NIST curve might have less to do with technical merits or security aspects, and more with regulations and certifications. Certifying something including cryptography already certified (NIST curve) is easier/cheaper than otherwise. As for backdoors, nobody really knows .. the nature of the algorithm itself makes it practically impossible to even detect a backdoor, even when there is one. So far, no evidence of that though. So if there is a backdoor, then whoever has knowledge of it is damned good in keeping it a secret. In my opinion a bit too good to be likely. That said, NIST has been caught before with their pants down. Rather awkward, since that's the organization supposed to certify such things. One can even wonder what worth or real meaning certifications still have, after they got caught with what they did. I'd personally consider it mostly a national US affair, but the reality is that the rest of the world is still dominated by US standards when it comes to the internet. All in all, the reasons for using the NIST curve might be more economical and people doing security by marking check boxes, rather than about actual security or efficiency.
- slim 6y ago
  Why would they nées certification ?
  - michaelt 6y ago
    Stodgy, conservative organisations like banks and the military created the market for hardware security modules, FIPS-140 dongles, smartcards, TPMs and so on. And they couldn't care less about sticking it to the NSA by rejecting the NIST curves. Whereas if you say "government standards compliant military grade encryption" they like that a lot. If you aren't one of those organisations, but you'd still like to use a HSM/TPM/smartcard, no Curve25519 for you.
  - elmo2you 6y ago
    > Why would they nées certification ? Compliance with regulation .. things like ISO, PCI, etc.
GordonS 6y ago
Would be interested to know if anyone here has had customers push back about the use of ECDSA, especially those in the defence sector?
- rkeene2 6y ago
  I haven't, though RSA is much more common EcDSA is included in NIST SP 800-73 (PIV) but I've never seen cards with it
- user5994461 6y ago
  Working in the finance sector, I haven't seen push back because I haven't seen anybody or anything use ECDSA. ^^ Usage and support is relatively low. Most people have no idea what ECDSA is or how to use it. There are some issues in java versions (7 or 8) if you try to use ECDSA. I personally don't find the elliptic curves and parameters easy to grasp and I have a math background (multiplying large numbers was much more palatable), I think a developer would quickly hit a roadblock if they tried to work with it. Long story short. There is no benefits to ECDSA (over RSA) so there is really no reason to push for it. The only place where DSA is somewhat used is SSH keys. SSH has its own crypto routines, they've added support and pushed DSA for some time. Keys are a bit shorter so it's nicer to copy paste to github or digital ocean.
  - ferdowsi 6y ago
    ECDSA is the standard format used for WebAuthn registration/auth. It's going to become more commonplace.
nurettin 6y ago
I'm sure this is about the mathematical soundness of the prime numbers used in elliptic curve cryptography, but wouldn't it be much easier to access half the internet's traffic if root certificates were compromised instead?
- deleted 6y ago
  [deleted]
- sjwright 6y ago
  When you say access, do you mean intercept and decrypt? I’m fairly sure root certificates are only affect the browser’s trust of a server’s public key and is not involved in the security of encryption—for that you’d still need the server’s individual private key. And even then I’m still not sure if the private key is sufficient given modern encryption protocols. Hopefully someone else can chime in to elaborate here.
  - aaronmdjones 6y ago
    Regarding your last point, even if you can monitor (but not alter) all traffic on the Internet, in real-time, all of the time, forever, that does not let you decrypt any traffic (now or in the future) if the parties are using forward-secret ciphersuites (those whose key exchange is performed with ephemeral private keys, instead of the key corresponding to the public key in the certificate). At the moment, these are the DHE- and ECDHE- ciphersuites in TLS1.2 and below, and are mandatory in TLS1.3 (RSA key exchange was removed). This only becomes a concern if your adversary can alter traffic in real-time (because they can use a compromised root to obtain their own certificate for the service you're talking to, and pretend to be them to you, and you will then negotiate your keying material with them instead, which naturally gives them the ability to decrypt the traffic before forwarding it along to its intended destination). Several technologies, such as HPKP, CAA, and CT, are designed to eliminate or mitigate this.
    - tialaramex 6y ago
      Fun TLS 1.2 (and earlier) caveat: If you can obtain the theoretically short-lived but certainly not truly ephemeral STEK (Session Ticket Encryption Key) from a server, then any sessions which enabled session tickets even if those tickets were never used can be decrypted using the STEK. This doesn't work in TLS 1.3
ilaksh 6y ago
(Not sure people realized this is sarcasm.) Right because if they believe something crazy like there being a backdoor in something recommended by the government then people will just say they are not a real cryptographer. Because of course no part of our government ever does anything tricky like backdoors and even if one part of the government did, it could never influence another part that made recommendations to the public for what security algorithms to use. And of course anyone suggesting that such a thing might be possible is just an insane conspiracy theorist.
tyingq 6y ago
"As far as I know, no cryptographer seriously believes the curves to be backdoored, but nonetheless seems to be a hot topic of online discussion. DJB lists them as “unsafe”." I'm not very well educated in this space. Is DJB historically prone to exaggeration?
- toast0 6y ago
  the NIST curves are unsafe, regardless of if they are backdoored. In order to use them safely, you have to carefully prepare your private key, because some keys are unsuitable. for curve 25519, you just need a decent secure random, all keys in the keyspace are good.
  - zimmerfrei 6y ago
    It's the other way around. NIST P curves don't require any special preparation to their private key. Curve25519 on the other hand requires a bizarre "clamping" (https://neilmadden.blog/2020/05/28/whats-the-curve25519-clamping-all-about https://neilmadden.blog/2020/05/28/whats-the-curve25519-clam...), partially because the curve has cofactor 8. Apart from clamping not being fully and clearly justified in most of the earliest specs and papers (which led to a few broken and/or insecure implementations), it makes the whole narrative of the curve being "safe" quite arguable and leaving a flavor of marketing in the mouth (NIST P curves have cofactor 1 so they are "safer" in that respect).
- rvnx 6y ago
  "NIST promotes U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic interests of U.S. companies" I don't think it's incompatible with a backdoor. Why would they NOT backdoor it ?
  - gilrain 6y ago
    Because it would destroy their credibility in this field forever. Like, it's not impossible, but it'd have to be "burn all this accumulated trust right down" important. They can advance the US' interests in more subtle ways by just being above board. Not that that's any guarantee with this administration, of course, but in general it's sound.
throw0101a 6y ago
FIPS 186-5 and SP 800-186 (currently in final draft) will have new curves: > NIST is proposing updates to its standards on digital signatures and elliptic curve cryptography to align with existing and emerging industry standards. As part of these updates, NIST is proposing to adopt two new elliptic curves, Ed25519 and Ed448, for use with EdDSA. EdDSA is a deterministic elliptic curve signature scheme currently specified in the Internet Research Task Force (IRTF) RFC 8032, Edwards-Curve Digital Signature Algorithm. NIST further proposes adopting a deterministic variant of ECDSA, which is currently specified in RFC 6979, Deterministic Usage of the Digital Signature Algorithm and Elliptic Curve Digital Signature Algorithm. Finally, based on feedback received on the adoption of the current elliptic curve standards, the draft standards deprecate curves over binary fields due to their limited use by industry. * https://csrc.nist.gov/news/2019/comment-on-draft-fips-186-5-draft-sp-800-186 https://csrc.nist.gov/news/2019/comment-on-draft-fips-186-5-... I'd be curious to see if the NSA will allow them for their 'Suite B' equivalent for classified stuff.
tialaramex 6y ago
The only permissible keys are: RSA keys of 2048 bits or some larger multiple of 8 bits or ECDSA keys from NIST P-256, NIST P-384 or NIST P-521 curves https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/ (See section 6.1.5) Other keys violate the Baseline Requirements which are common rules agreed between the major CAs and Browser vendors. Now, a CA could choose to just disregard the BRs, but then they're automatically in violation of the root trust programme rules for the major root trust programmes - at least Microsoft, Apple, Mozilla, Google, then arguably Oracle (because Java) and some other smaller outfits. So that's probably the end of that Certificate Authority, at least for the Web PKI. Individual root programmes also have their own rules, and so in this case Mozilla's rules are important because they further restrict keys to RSA or ECDSA P-256 or P-384 only. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ https://www.mozilla.org/en-US/about/governance/policies/secu... (section 5.1 this time) Now, those are just policies, you can change policies, but that's not up to Let's Encrypt. If you believe Mozilla needs to support Curve 25519 then that's a bunch of software development you can volunteer to do, followed by lobbying all their competitors because it's futile if only Firefox supports it anyway.
colmmacc 6y ago
In modern times, the keys on a SSL certificate don't directly encrypt the session key used to protect communications between your browser and web-server. Instead the key only signs the diffie-helman share that a web server uses. Web-server operators are free to use 25519 for their ECDH shares if they want to, the curve used there does not have to match the certificate's curve. Even if the NIST curves are backdoored, the backdoor wouldn't be able to passively decrypt TLS sessions. At best it might allow someone with knowledge of the backdoor to impersonate a web-server, but that's an active attack and it would be very risky for the attacker. They'd run a huge risk of disclosing their back door capability.
- coder543 6y ago
  Can you link to a config example for nginx for what you’re describing in your first paragraph? Or a web framework in any language? I’ve never seen that done before, where the DH shares don’t match the certificate type. But, I’m definitely not an expert on the low level details of TLS.
  - wolf550e 6y ago
    All your DH shares don't match the certificate type already because you use ECDH with either NIST P-256 or X25519 and you likely use an RSA certificate. The two asymmetric systems (one for key exchange and one for authentication) have nothing to do with each other, you can mix and match them freely (e.g. post-quantum key exchange experiments ran by google and cloudflare). The nginx config to specify the curve (using its openssl name) is this: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ecdh_curve https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_...
- tlb 6y ago
  Active attacks are effective and not that risky. For most web services, the attacker only needs to intercept a single transaction in order to get the session cookies and then you are pwned. Since they only need one, they can hit you with a DNS cache poisoning attack and simultaneous clickjacking attack while you're on a public WiFi. In general, I'm skeptical of any "this attack isn't really practical" arguments. They have a way of becoming practical enough for high-value targets, so it's not something I want to use.

hashamali 6y ago

> For the last five years, Let’s Encrypt has had one root: the ISRG Root X1, which has a 4096-bit RSA key and is valid until 2035. Somewhat tangential, but what happens to all active certificates when the root key expires?

axaxs 6y ago
They all become untrusted, if the verifier does their job. That said, a root doesn't issue site level certificates, so the intermediates and issued certs themselves would expire first.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
LeonM 6y ago
CAs simply never sign a cert with an expiry longer than their own root cert. Thus, by the time the root cert expires, all client certs will already be expired.
masklinn 6y ago
> what happens to all active certificates when the root key expires? They expire, but normally the CA wouldn't issue certificates outliving their root. It can be a concern for legacy devices whose trust store doesn't get updated, but really no more so than any other cert expiration or revocation.
deleted 6y ago
[deleted]
akadruid1 6y ago
This actually happened recently and some older stuff stopped working. there's a write up here: https://www.namecheap.com/blog/sectigo-ssl-certificate-root-expiration-issue/ https://www.namecheap.com/blog/sectigo-ssl-certificate-root-...

GordonS 6y ago

From the article I can see that using ECDSA instead of RSA could save up to 400 bytes per connection - that's nice. Aside from certificate and key size, my understanding is that ECDSA is less computationally intense than RSA, but this gets only a brief mentioned in the article - does anyone know how CPU use compares for typical setup of a TLS connection for ECDSA vs RSA?

arkadiyt 6y ago
Here's a 2017 Cloudflare blog post that compares the performance of ECDSA sign and verify operations (using 256 bit keys) against RSA sign and verify operations (using 2048 and 3072 bit keys) on various CPU architectures: https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/
- zepearl 6y ago
  Questions: - Do the graphs mean that the "sign" operation of OpenSSL when using ECDSA is many times faster and the "verify" operation is ~4 times slower (compared to RSA)? - I suppose that "sign" is linked to issuing certificates, while "verify" would be involved to checking certificates? (sorry, I'm not a pro with this stuff)
  - wbl 6y ago
    You are exactly correct on both points!
  - toast0 6y ago
    If it were just checking and issuing certificates, faster signing and slower verifying would be a bad tradeoff, since certificates are issued once and used many times; certificate size benefits notwithstanding. The really nice thing performance wise is that when sending a certificate via TLS, you need to sign the TLS exchange up to that point. Making that faster means you can support a lot more connection handshakes with the same server.
    - 6y ago

jng 6y ago

It would be nice if they included a TL;DR notice at the top saying: “1. If you are a user of let’s encrypt today, this announcement does not imply that you need to do anything at all, and, 2. The main thing is that new certificates are shorter and will take up less bandwidth, plus also safer.” In any case, thanks for the great, free service!

colesantiago 6y ago
I agree, I wish articles like this at the very least summarised their article first before going into a deep technical rabbit hole.
edoceo 6y ago
Side note: a TLDR at the top is called a BLUF = Bottom Line, Up Front. https://en.m.wikipedia.org/wiki/BLUF_(communication) https://en.m.wikipedia.org/wiki/BLUF_(communication)
- pfundstein 6y ago
  A TLDR is traditionally at the bottom, but there's no rule against putting it at the top.
- cortesoft 6y ago
  But no one knows what that means, so you would have to explain the whole thing every time you use it, defeating the purpose of a short acronym. Say tl;dr in the first sentence and everyone knows what it means.
  - NovemberWhiskey 6y ago
    >But no one knows what that means ... anyone with writing experience in the military knows what that means.
    - frogamic 6y ago
      So still relatively few people.

anderspitman 6y ago

I don't want to go too far OT, but had a question if someone wouldn't mind answering it or pointing me to some materials. I've been digging into DNS and TLS lately. Given the way ACME works (essentially using DNS to verify you own a domain before giving you a cert), what's the reason you can't just put your public key in a DNS record? I'm assuming it has something to do with security issues at the DNS level, but don't really know.

jcrawfordor 6y ago
This is basically the idea behind DANE. The problem is that DNS was historically unauthenticated and so just as vulnerable to on-path attacks as HTTP - perhaps more so due to the distributed, hierarchical nature which enables certain types of takeovers. DANE assumes that DNSSEC is in place, so that the DNS records are authenticated. This allows the DNS records to be used to deliver TLS trust information in a way that is still ultimately rooted in a certificate authority (whoever operates DNSSEC for the TLD). Adoption has been limited, mostly because adoption of DNSSEC itself has been limited, arguably because DNSSEC is overcomplicated and high-maintenance, but also just due to a lack of motivation. Similarly, users couldn't care less about how TLS trust is delivered and DANE has never really gotten a big corporate champion to push for it, so there just hasn't been the drive. Industry seems to have chosen DNS-over-HTTPS as the long-term solution to many of DNS's problems, and it clashes somewhat with DANE - I'm sure you could make them work together but it would definitely become awkward
- AndyMcConachie 6y ago
  Where DANE has seen pickup is in the SMTP space. https://stats.dnssec-tools.org/ https://stats.dnssec-tools.org/
J0_k3r 6y ago
I'd also like an answer for this.
wgetch 6y ago
What happens if both DNS requests are hijacked? Could an attacker return both a different IP and a different public key that correspond to a malicious server? Edit: I should clarify, I think the issue stems from DNS being a potential attack vector itself. You can't blindly trust what DNS tells you. This is precisely the problem that certificate chains (issued by a trusted third party) purport to resolve-- one of trust.

slim 6y ago

Let's not forget that letsencrypt is an EFF project when the shit hits the fan

jaas 6y ago
EFF is a strong supporter but Let's Encrypt is not an EFF project. Let's Encrypt is owned and run by Internet Security Research Group: https://www.abetterinternet.org/ https://www.abetterinternet.org/
- slim 6y ago
  the project is older than that organisation

egberts1 6y ago

I couldn’t do OCSP stapling with my Firefox 80 against my LetsEncrypt website. Had to turn off stapling.

octorian 6y ago

I really wish Let's Encrypt had a solution for those of us with lots of "internal" devices that neither need public access nor are capable of running an automated renewal job (routers, switches, IoT gizmos, etc). All of these things come with half-baked self-signed certs, and web browsers and mobile devices these days are making it increasingly difficult to actually stomach such certs for anything at all. I wish the "SSL All The Things!" crusaders would consider this use case once in a while, and actually offer a usable solution. (Some of us could go through the trouble of setting up a private CA to deal with this issue, but getting everything to trust your own personal CA root seems like almost as much of a hassle at times.)

ricktdotorg 6y ago
look into Cloudflare’s cfssl. it’s really great if you just want a simple internal CA.
arkadiyt 6y ago
I use mkcert [1] with great success - it's easy to setup locally trusted certs which I load onto my router and other devices. [1]: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
- wtallis 6y ago
  That seems like a nifty tool, but it doesn't seem to do anything to address the difficulty of getting your private CA trusted on more than one of your devices. I'd like to be able to access my router and switch configuration interfaces from more than one client PC, and perhaps even from a smartphone.
  - nemosaltat 6y ago
    Same here. I run OpenWRT on my home routers, and your comment prompted me to do a quick web search. uacme looks promising for luci. I’d love to hear HN experiences with it.
  - cpach 6y ago

deleted 6y ago

[deleted]

maxekman 6y ago

What a pleasure to read this post! Very well written, informative, and accessible for readers of most technical levels.

ggm 6y ago

Remembering that *.domain cannot span dots in certificates, and the consequence for SNI if you dry to use FQDN as a dot-separated space beyond the "flat" model. The convergence of certificate issuance, domain names, domain matching logic, configs, port-binding, information leakage. Its a nightmare. 5 tuple be damned: the higher protocol layers are now deciding how to de-mux your service.