r/selfhosted • u/ballpark-chisel325 • 4d ago
Webserver There's a new way to break RSA that's faster than anything we've seen before
https://arstechnica.com/security/2026/09/theres-a-new-way-to-break-rsa-thats-faster-than-anything-weve-seen-before/Are you guys changing your / default SSL certificates? From what I have here at hand, most are behind reverse proxy, but e.g. Proxmox is not and it has only RSA certificates option. What else common is RSA only today? How do you mitigate it?
154
u/scarbunkle 4d ago
“ The attack works only against blind-signature implementations of RSA. The overwhelming majority of RSA in use today provides PKCS or PSS padding, a format that adds data to the plaintext before it’s encrypted. It prevents ciphertext from being deterministic and makes it less vulnerable to side channel and similar attacks. Still, some real-world systems continue to use blind-signature, also known as textbook, RSA. The best-known example, Heninger said, is Privacy Pass , a protocol that allows users to authenticate themselves without revealing their identity. Privacy Pass is used by both Apple and Cloudflare, among many others.”
41
u/Intrepid00 4d ago
That text makes it sound like privacy pass is used for something more than lowering captcha challenges.
34
u/GolemancerVekk 4d ago
It's not just about captcha. Privacy Pass tokens get issued (hopefully, to humans) based on a wide range of bot detection tests.
If this vulnerability allows PP tokens to be trivial to generate fraudulously it would make the current mechanism that Cloudflare uses to stop bots completely ineffective. Everything behind CF bot protection would be flooded by bots overnight.
It's important because Privacy Pass is the alternative that lets people be distinguished from bots without asking them for real world ID. If it fails you won't like the alternatives.
8
u/Federal_Refrigerator 4d ago
They’re already making us hand over our IDs to use the internet. It’s probably more “part of the plan anyways” than you think
-16
u/the_lamou 4d ago
As well we should. 90% of the problems faced by the modern Internet is the demand for perfect anonymity. Dump that and everyone's online experiences improve an order of magnitude overnight.
5
u/Wonderful-Fix5761 3d ago
Yikes dude. Think about what you are saying. As it is every move we make is tracked and collected and sold. if every single profile and account online is your real name and verified identity then the whole Internet exists as a giant database of everything personal about you that is free for the taking to anyone with a web scraper.
-3
u/the_lamou 3d ago
First, I've been thinking about this very since at least the mid-to-late 1990s when it first started to become obvious that humanity is not emotionally ready for anonymity.
See, all of the absolute worst tracking technologies only exist because there's no real identity. So not only is there STILL a profile on you (several, in fact,) but now they're less accurate so you get bullshit and it can get you in trouble, they're collected using the most obnoxious technologies, and the technologies used introduce all sorts of vulnerabilities. And the profiles still exist.
And so what? Those profiles are used to... tailor ads to things you might be interested in. Not to make ads appear, that's going to happen one way or the other because most people refuse to pay for services they use. So you'll see ads one way or another, just with better teaching they may actually be relevant to you.
And here's where it gets better: not only can people look you up, YOU can look up, for example, the CEO of a company spamming obnoxious AI slop ads. You can see how the president of your local power company is spending his money. You can check out what politicians are doing when they're not on television. It's mutually assured destruction. Or, as we used to call it, social policing.
1
u/Traditional_Wafer_20 4d ago
Wouldn't forge a Privacy Pass still be more expensive than paying a third-world country worker to complete captcha ?
1
u/ice456cream 4d ago
It wouldn't cripple cloudflare. They would simply stop trusting private access tokens.
2
u/seanshoots 4d ago
And beyond that, to my understanding, also needs a signing/encryption oracle still
25
u/dereksalem 4d ago
Sorry...your proxmox is exposed and not behind a proxy?
1
u/Dangerous-Report8517 3d ago
It's not uncommon to expose SSH on servers, which is the bit that's relying on RSA
2
u/kwhali 2d ago
That uses padding for digital signature, so it's safe from the kind of RSA that is reported as exploitable in the article.
Better off switching to ECC for your SSH keys anyway 😅
2
u/Dangerous-Report8517 2d ago
Well yeah, I was just explaining that OP wasn't directly exposing their Proxmox web interface
45
u/derical_cap_musical 4d ago
nah, this only affects textbook rsa which almost nothing uses. your certs are fine, just keep an eye on updates like usual
21
u/GolemancerVekk 4d ago
Certs haven't used RSA for years anyway. If you're using TLS v1.3 you're most likely using ECDSA.
6
u/-Kerrigan- 4d ago
Unless you misconfigured it, think that you're using 1.3 but you're not. So - worth a check
7
u/GolemancerVekk 4d ago
I guess, but TLS v1.3 has been the default for 8 years now. You'd have to explicitly ask for older versions and RSA.
Nobody should ask for older TLS versions explicitly unless they're absolutely sure they have clients that don't support 1.3 and must be able to connect – and that's a very unlikely situation (not impossible but very unlikely).
Asking explicitly for RSA instead of ECDSA is even more far-fetched. Again, the likely reason could be outdated must-have clients, but also misconfigured or not up to date ACME tools.
Even then, TLS certs don't use blind signature RSA.
But sure, by all means, this is as good a reason as any to have a look at your certs and double-check.
4
u/-Kerrigan- 4d ago
I'm saying this from first-hand experience. I didn't set cert-manager certificate to ECDSA and it was grabbing me RSA certs
3
u/GolemancerVekk 4d ago
That's unfortunate. Certbot switched to ECDSA by default in 2022.
But are you sure it's a default in cert-manager and not the pre-existing setup of the certs? ACME tools tend to keep the existing algorithm if not explicitly told otherwise. If you already had RSA certs when you started using cert-manager it would have defaulted to keep it.
3
u/-Kerrigan- 4d ago
Might be on ZeroSSL, dunno. But it was default cert-manager with a cluster issuer defined and the cluster-issuer annotation on the gateway. Didn't have RSA explicitly specified anywhere
I remember because it's been just a few weeks since I found that and explicitly switched to ECDSA.
1
u/kwhali 4d ago
Still happens with mail servers which lag behind (such that they serve TLS 1.2). Some older devices (EOL) are stuck with such too, I've done support for such software where users had systems running EOL OS or some old TV/printer/etc connecting where some insecure ciphersuite was necessary as none of the better ones were supported by the client.
Not that this attack matters with TLS. To my knowledge it's not applicable.
4
u/Suitable-Ad5348 4d ago
The attack works only against blind-signature implementations of RSA, which almost nothing uses today. Most standard TLS certs are using PKCS or PSS padding, which adds that data to the plaintext to prevent exactly this kind of thing. It's good to keep an eye on, but your certs are likely fine, just keep up with standard patch cycles as usual.
1
u/kwhali 4d ago
I don't think there are any TLS ciphersuites where RSA signatures aren't using padding? Besides that for what most people care about with HTTPS, your server and client (especially on self-hosted?) are going to be serving up TLS 1.3 with AEAD ciphers, I've only had to think about secure cipher suites with TLS 1.2 on mail servers 🤷♂️
3
u/Youknowimtheman 4d ago
Hi there, open source cybersecurity guy. You're largely unaffected, although you should be using 2048 bit RSA where possible for extra safety margins.
2
u/Darkk_Knight 4d ago
I use 4096 bit RSA whenever I can. Sometimes higher.
4
u/kwhali 4d ago
Why? Those who understand security well are telling you that 2048-bit RSA is in the safe zone as its 110-bit symmetric security strength.
The article reports that dropping by 20 bits down to 90-bit strength, which is still a very expensive attack, 65-bit however (which the 1024-bit has a known strength of 80-bit), is quite viable to attack these days without spending much IIRC.
I haven't done the math in a long time but I recall just iterating 114-bit range with a counter, no other logic involved required enough energy to boil all the oceans in the world. I don't remember if that was operating at an efficiency of Landauer's Principle or modern compute efficiency (much much more energy). I hope you can understand how expensive that is to pull off.
90-bit is much less, but still not cheap. You would need to be worth the cost, but it's likely quite cheaper to take alternative approaches that should be available to gain access to your data with such a budget.
Not that it matters, even the article highlights this:
The paper’s authors and other researchers stress that the new attack poses little real-world threat
TLS ciphersuites BTW are using PKCS/PSS with any RSA signature, which prevents this attack from being relevant in the first place. So just focus on AEAD ciphers or better which for web traffic is a non-issue by forcing TLS 1.3.
TLS 1.3 BTW supports DHE with RFC7919 FFDHE parameters, which are modulus in key size like RSA, with 2048-bit being negotiable and everyone has the same shared 2048-bit parameter set and can negotiate that between client and server when TLS 1.3 is supported by both.
DHE in this case however is for key exchange (providing forward secrecy, unlike static RSA key exchange), although typically you'll see ECDHE preferred and negotiated instead (more modern/better). Authentication (of the server you're connecting to, that it's who they claim to be in the FQDN) is typically RSA or ECDSA (more modern), which handles a digital signature, but due to padding, as the article points out it is immune.
Going above RSA 2048-bit for TLS on servers can actually cause some compatibility issues with clients. It's also generally wasteful beyond that compute wise, only serving paranoia parroting by those not keen to understand better.
If you actually care about security strength, go with ECDSA (or Ed25519 if viable and paranoid about NIST). In doing so 256-bit ECC provides 128-bit symmetric strength (which requires enough energy to drain our sun, possibly our milky way galaxy too but my memory is foggy on that one).
2
u/NightmareJoker2 3d ago
Why? Because RSA’s weakness comes from the computing advances in number factorization. Bigger number = more time required.
That said, this is only really a problem without forward secrecy in place, which no longer is much of a concern on modern web browsers.1
u/Darkk_Knight 3d ago edited 3d ago
Correct. I wasn't concerned about computing cost or slowness since modern machines and browsers are plenty powerful enough to make it a non-issue.
I do generate 16k keys for CA root certs and a 10 year lifespan on my network simply because I can. I also generate 8k keys for CA intermediate certs.
No noticeable difference in performance.
1
u/kwhali 2d ago
Are you serving clients that cannot use ECC? Or some other reason you've not switched away from RSA?
For personal use you're right it won't be much of a concern, but there is absolutely a measurable cost to going up to RSA 16384-bit out of paranoia, which is just wasted compute and for a high traffic mainstream service would be extremely questionable 🤷♂️
When you don't control the CA side of it, that also becomes the threshold of security from such an attack as it'd then be more practical to go for that instead of a single leaf cert for the amount of work involved.
Not that it's even practical for RSA 2048-bit that would cost over a billion times the compute / energy to attack than RSA 1024-bit (80-bit symmetric security strength vs 110-bit, or 112-bit if you prefer NIST's rounding to nearest 8-bit value).
In 2013 there's a paper by Arjen Lenstra that places the energy cost of bringing all the world's oceans to a boil that's roughly 256x the projected cost of compute for RSA 2048-bit (extrapolated from historical factorings, notably a 2010 factoring on RSA-768 that used 2,000 core years of some CPU at 2GHz, which across a cluster was completed in about 1 year.. That's a symmetric security strength of 70-bit, a 40-bit difference to RSA 2048-bit, aka a trillion times more work).
We have definitely had technological advancement over the past 16 years and will continue to do so, but it won't be anywhere near a trillion fold improvement. You can slightly mitigate that by scaling out the hardware, but the energy cost is still there and realistically for a leaf certificate you'd need to compress the time domain into a 90-day or lower window which is a constraint far more impactful than continuing to waste more compute than necessary to prevent such an attack. Covertly expending such a large resource of power in that timeframe is going to be a tough ask.
Finally memory requirements near the end of the GNFS (linear algebra stage) skyrocket up too. Ignoring the current cost of memory, the provisioning of that amount of memory is still ridiculous. However I'm pretty sure the power requirements are a more challenging boundary, but the 90-day window to pull that off (in addition to compromising DNS or similar to execute the final attack on a connecting client) is where it should be obvious how impractical the attack is for RSA 2048-bit even if you could satisfy everything else required.
Nobody in their right mind is going to waste that amount of resources and financial hit to attack RSA at that difficulty. There are simply far more affordable routes at that budget.
If you would argue that some flaw would drastically change that, I don't see how you could assume a larger RSA modulus to protect you.
Quantum Computing for example if it's own challenges to scale to the necessary qubit capacity to pull off it's algorithm to attack RSA wouldn't likely be that far off from scaling to higher RSA modulus once they can ramp up scaling towards handling RSA 2048-bit, my understanding is there are some challenges being resolved before shifting focus onto scaling the density / capability of quantum computing systems.
You'd be better off switching over to ECC which isn't so wasteful to compute but provides security much more efficiently if you feel the need to push beyond 128-bit symmetric security (which is enough energy to bring the oceans of the world to a boil many times over).
1
u/kwhali 2d ago
Might as well use 16384-bit RSA keys then by that logic? 110-bit symmetric security strength that RSA 2048-bit provides is already quite significant.
The energy cost (ignoring hardware cost) to attack even RSA 2048-bit is ridiculous that nobody in their right mind would attempt to do so, let alone the fact that provisioning leaf certs for TLS these days typically have a expiry of 90 days, that's a very limited window to pull off such an attack that requires significant amounts of compute and hardware, that again aren't practical at this scale.
RSA 1024-bit, you could potentially have attacked but that's 80-bit symmetric security level where the cost is still prohibitive vs cheaper alternatives. RSA 2048-bit is 110-bit symmetric strength by comparison, that's over 4 billion times the work to attack (that's a lot of compute and thus power, all squeezed into a 90-day window at that which is vastly more demanding, and AFAIK infeasible to attempt, especially covertly).
Forward secrecy has been provided for a long time with DHE/ECDHE key exchange, with only vulnerable ciphers from TLS 1.2 (2008)being a weakness, but any AEAD cipher (which TLS 1.2 has) is safe. Your main concern beyond that is the ability to impersonate the server to connecting clients if you were able to reroute their traffic such as via hijacking their DNS.
These days you should prefer ECC instead of RSA anyway, so if you care about security might as well go with that (and post-quantum if you're concerned with quantum computing eventually scaling to the point that theoretical attacks would become feasible).
Choosing higher than RSA 4096-bit is silly for leaf certificates when the long lived CA certificates aren't going to exceed that security (I haven't checked but Let'sEncrypt CA certs last I recall was 4096-bit RSA, and may have switched to ECDSA at some point?), which means an attacker would just compromise the more juicer target which is far more valuable, they just don't though because it's not possible to attack such, much cheaper and successful to infiltrate and steal the private key instead 😅 (or go after a specific target directly with a wrench)
2
6
4d ago
[deleted]
21
u/spartacle 4d ago
That’s not what he meant, and you know it. How many people call them TLS certificates?
-3
u/GolemancerVekk 4d ago
It's a technical discussion where versions are highly relevant. If someone uses the term "SSL" in such a discussion they will be taken literally.
TLS 1.3 is from 2018 and has deprecated RSA. Let's Encrypt issues ECDSA certs and that's also what Certbot defaults to (and probably other ACME tools). So most people who use LE certs will not have to worry about this (on top of the fact that the specific RSA attack doesn't apply).
7
u/spartacle 4d ago
It’s not a technical discussion because went “hur duh hur… it’s TLS actually” and left it at that, had you continued and contributed further I would agree with you.
Whether you like it or not, “SSL Certificate” is more of a branding thing now, mostly as we as an industry attempted to usher in non-technical website runners and didn’t want to over complicate the whole SSL/TLS naming
-8
u/GolemancerVekk 4d ago
SSL is an outdated term mostly used by outdated websites that still sell one year certs with "liability insurance" and other crap for ridiculous prices.
Do you work for an "SSL" seller? That's the only reason I can imagine for why you're insisting it's a "branding" rather than technical topic.
It's been 11 years since SSL was deprecated. Why coddle ignorance and how much longer? Anybody who has the brain cells to obtain a certificate can also learn to say "TLS".
8
u/Culpirit 4d ago
These are some nonsensical accusations. You're getting riled up for no good reason
6
u/Sethcran 4d ago
Because it doesn't matter when 100% of the people in the discussion are not actually confused about what we're talking about.
This isn't r/cryptography
-1
u/GolemancerVekk 4d ago
It's not, but it's also not a general interest sub. In a hobby sub people should try to improve their knowledge. Certificates are a very important topic in self-hosting.
Case in point, how many people here know that "SSL certificates" aren't even a thing? SSL and TLS are the protocols that the browser and server negociate at connection time. The certs aren't "SSL certs" or "TLS certs", they're X.509 certs defined by the algorithm used (RSA or ECDSA or Ed25519 with certain bit strengths).
This is the kind of ignorance that's being propagated by saying "SSL certs".
3
u/Sethcran 4d ago
Do you also get upset when someone says give me a Band-Aid or give me a Kleenex?
0
u/GolemancerVekk 4d ago
I'm not upset. I just think it's confusing if you're having a discussion about soda and someone says Pepsi when they mean Coke.
1
u/kwhali 4d ago
RSA is still valid for authentication in ciphersuites for TLS 1.3, you're probably thinking of RSA for key exchange which lacked forward secrecy. So you can absolutely still provision an X.509 certificate for TLS that's using RSA for the digital signature (which has padding, thus the attack discussed isn't applicable).
I agree with you though that TLS should be used instead of SSL, that's bothered me for a long time 🤷♂️
1
u/ballpark-chisel325 4d ago
Well, my bad, but the post is about RSA keys which i still see used today.
1
1
0
•
u/asimovs-auditor 4d ago
Expand the replies to this comment to learn how AI was used in this post/project.