TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Let's Encrypt's performance is currently degraded due to a DDoS attack

268 点作者 sorcix大约 4 年前

10 条评论

malikNF大约 4 年前
We used to run a game server for a small community of around 400-500 people and DDos attacks were something we had to face almost every week, whenever someone got upset with the admin team, the go to solution was was to DDos, you get scammed by another player? DDos. Got banned for saying racist things ingame? DDos. You figured out a new way to cheat in game and the admins fixed it? DDos.<p>We were kids back then and those were kids that were attacking us with just a 5-10usd budget. Yes they were relatively small (ranging from 10-60Gbps) attacks compared to the Tbps attacks that are happening to some companies, but good god it was so annoying when all it took was just 5 usd from some idiot to take down your server.<p>We moved to gcp got null routed (or reduced network bandwitch to the node under attack) every-time there was an attack. Bought azure&#x27;s 3000usd a month anti DDos protection, was worthless for a tcp&#x2F;udp service. Tried to have a network load balancer in the cloud that auto-scaled, still some players got effected when an attack came in.<p>Finally we moved over to OVH and placed a few really powerful servers in-front of the game server and applied some ipfilter rules to reduce common attacks. That ended up being the cheapest option out of all the options. When you have a very small community its not like you have the biggest budget to work with. But it was really fun and taught all of us a lot. Looking back its kinna sad we had to end things. But it was a lot fun.<p>DDos attacks are one of those things that really makes me worried about the future of the internet. The only way to win it is to throw money at it and cross your fingers that the attacker will run out of resources before you do.<p>Definitely companies like cloudflare does an incredibly good job of stopping some insanely big attacks when it comes to http&#x2F;https (I recently saw they were supporting udp and tcp based services now, never tried it).<p>But one thing that&#x27;s weird is having to rely on some 3rd party company. Yes cloudflare so far has been a company I can trust, but, I once loved and trusted a company that said &quot;Don&#x27;t be evil&quot;.<p>If you are a developer for some IOT device manufacturer please do your best to makesure someone wont turn your light bulb in to a part of a botnet. When you guys fuck-up the rest of us have to suffer.
评论 #26378153 未加载
评论 #26376379 未加载
评论 #26379513 未加载
评论 #26376190 未加载
评论 #26377438 未加载
评论 #26378773 未加载
评论 #26377872 未加载
评论 #26390430 未加载
评论 #26377637 未加载
评论 #26379276 未加载
评论 #26381230 未加载
评论 #26381001 未加载
评论 #26376166 未加载
mjthompson大约 4 年前
This had me scratching my head earlier today when I was debugging why renewal was taking so long. I&#x27;ve taken Let&#x27;s Encrypt&#x27;s reliability for granted. Didn&#x27;t even cross my mind that it might be a service issue.
manishsharan大约 4 年前
Here is something to think about. If you get ddos&#x27;d in middle of trial run by an enterprise customer and its the end of your startup. AZ , AWS , OVH almost all hosting providers will all start dropping your connections. And DDOS protection services are expensive. Pay as you go models are awful for this as when you do get ddos&#x27;d , you bill could be quite high.
评论 #26377724 未加载
评论 #26378068 未加载
benlivengood大约 4 年前
I wonder how well common acme tools implement exponential backoff on retries. With a ton of clients you can inadvertently make a DDoS longer&#x2F;worse.<p>Let&#x27;s Encrypt asks for max 1 request per day per certificate: <a href="https:&#x2F;&#x2F;letsencrypt.org&#x2F;docs&#x2F;integration-guide&#x2F;" rel="nofollow">https:&#x2F;&#x2F;letsencrypt.org&#x2F;docs&#x2F;integration-guide&#x2F;</a>
评论 #26379445 未加载
timvisee大约 4 年前
I wonder what their motivation is?
评论 #26374944 未加载
评论 #26375041 未加载
评论 #26375039 未加载
评论 #26375529 未加载
评论 #26376191 未加载
评论 #26374916 未加载
评论 #26374976 未加载
评论 #26375272 未加载
评论 #26376077 未加载
评论 #26375020 未加载
评论 #26375666 未加载
oconnor663大约 4 年前
About how expensive is it to rent a botnet and pull off an attack like this?
评论 #26380077 未加载
francislavoie大约 4 年前
Just a reminder that users of Caddy (v2.3.0 or higher) are not at risk when LE gets hit like this, because it will fallback to having a certificate issued from ZeroSSL. Both issuers would need to be down for the whole last 30 days of the certificate&#x27;s 90 day lifetime before Caddy would be stuck with expired certificates.<p><a href="https:&#x2F;&#x2F;caddyserver.com&#x2F;docs&#x2F;automatic-https#errors" rel="nofollow">https:&#x2F;&#x2F;caddyserver.com&#x2F;docs&#x2F;automatic-https#errors</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;caddyserver&#x2F;caddy&#x2F;releases&#x2F;tag&#x2F;v2.3.0" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;caddyserver&#x2F;caddy&#x2F;releases&#x2F;tag&#x2F;v2.3.0</a>
noncoml大约 4 年前
Why the duck would anyone DDoS Let’s Encrypt?
评论 #26378538 未加载
0xbadcafebee大约 4 年前
This is a very morbid thought, but I wonder if the people who run LE ever travel via the same means. If somebody took them out all at once, would the web&#x27;s security essentially crumble? This is the danger of centralized services, but moreso the crap design of web PKI.<p>All &quot;usable&quot; HTTPS depends on certs, right? And &quot;usable&quot; certs require a domain, right? And that cert for that domain needs to have been generated by a CA, right? But it&#x27;s tied to a domain, and IP space. You have to prove to a CA that you both control a domain record and some IP space it points to. Nobody has designed anything to straightforwardly prove that in an unhackable way. We have shitty hacks, like &quot;serve this unique file on this web server that this domain record is pointing to&quot;, or &quot;answer an e-mail on one of 20 addresses at this domain&quot;, etc.<p>But none of those address what we <i>actually want to do</i>, which is just to prove that we own&#x2F;control a domain record. That&#x27;s the only meaningful thing in having a cert: proving that you actually own the domain record this cert is assigned to. And we have no actual way to do this. Literally the only way to prove definitively that you own a domain is to talk to the registrar, and the only way to prove that you control a domain record is to talk to the nameserver that the registrar is pointing to. The former we don&#x27;t handle <i>at all</i>, and the latter is highly susceptible to various attacks.<p>You could remove the reliance on CAs entirely with a different model. You tie a private key to domain ownership, and a private key to a domain record. Then you only have to trust registrars&#x27; keys&#x2F;certs, and you can walk backward along a cryptographically-signed web of trust. Your browser trusts the registrar&#x27;s key X. The registrar signs your domain key Y. The domain key Y signs a domain record key Z. Your web server generates a cert using domain key Z.<p>For a client to verify the web server cert, they verify it was created by key Z, and verify that key Z was signed by key Y, and that key Y was signed by key X. Then any webserver can generate its own cert for any domain record, we don&#x27;t need CAs to generate certs, and we have a solid web of trust that goes back to the actual owner of the domain, but also allows split trust via the domain owner assigning keys to domain records.
评论 #26378623 未加载
评论 #26378911 未加载
Tenpenny99大约 4 年前
Heroes really, https and certificate centralization should end as soon as possible. Maybe along with DNS.
评论 #26376867 未加载