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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

DigiCert: Threat of legal action to stifle Bugzilla discourse

610 点作者 DanAtC2 个月前

18 条评论

nneonneo2 个月前
In a nutshell:<p>DigiCert has delayed revocation beyond what&#x27;s allowed in the Baseline Requirements a few times; most recently, <a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1896053" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1896053</a> and <a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1910805" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1910805</a>. In the former case, it seems DigiCert chose to delay revocation to appease certain clients; in the latter case they were prohibited by a Temporary Restraining Order (TRO) from performing timely revocation.<p>Tim Callan from Sectigo has publicly lambasted DigiCert for these delays, since in both cases it seems DigiCert hasn&#x27;t pushed back hard enough on its clients. In the latter case, there&#x27;s concern that measures like TROs might be employed more often to stall revocation. Sectigo (and others in the WebPKI ecosystem) seem to want DigiCert to make the revocation policies very clear to clients and to ensure that clients can actually replace their certificates in a timely manner.<p>Sectigo is clearly the most vocal but they don&#x27;t seem to be the only ones telling DigiCert to get their delayed revocation under control. So the escalation to legal threats is really uncalled for, and DigiCert could face some very significant pushback for trying this tactic.
评论 #43169378 未加载
评论 #43173298 未加载
评论 #43168791 未加载
评论 #43169246 未加载
jchw2 个月前
Web PKI drama is always astonishing to me because it is one of the only areas of the entire world where a corporation&#x27;s &quot;fucking around&quot; is seldom ever <i>not</i> followed by a sobering &quot;finding out&quot; period. The various entities that decide what CAs to trust can effectively dismantle any CA business in the world, basically at the drop of a hat. If DigiCert decides to play this game and lose, it would make them the biggest such loser so far. DigiCert is, as far as I know, the largest CA on the Internet. It would certainly send a strong message, and cause a lot of chaos, if the biggest CA on the Internet found itself being removed from trust stores. Yet, there&#x27;s no particular reason it couldn&#x27;t happen. How exciting.<p>Of course, I think that is unlikely, but on the other hand, it&#x27;s just as cathartic to imagine whatever idiot at DigiCert thought it was a good idea to engage legal here to have the dressing down of a lifetime. I read the thread in question. It doesn&#x27;t make DigiCert look good, but this action definitely is more damning to them than anything Collan said in my opinion.
评论 #43168356 未加载
评论 #43173007 未加载
评论 #43168330 未加载
评论 #43174924 未加载
评论 #43168320 未加载
DarkmSparks2 个月前
From the bugzilla<p>&quot;The actual reason for the underscore is so that services which allow users to create DNS records at subdomains (e.g. dynamic DNS services) can block users from registering subdomains starting with an underscore and be safe from unwanted certificate issuance. It serves the same purpose that &#x2F;.well-known does for Agreed-Upon Change To Website, and that admin&#x2F;administrator&#x2F;webmaster&#x2F;hostmaster&#x2F;postmaster do for Constructed Email to Domain Contact. By using DNS records without underscores, DigiCert has violated a security-critical assumption that these services have made.<p>Therefore, this is truly a security-critical incident, &quot;<p>That is a pretty brutal f&#x27; up of epic proportions... not sure any digicert cert should be trusted after that.
评论 #43171811 未加载
评论 #43173421 未加载
webprofusion2 个月前
Always two sides to a story but the guy who caused the validation bug at DigiCert already <i>resigned</i> because of it (which is extreme), the Sectigo guy wanted to prevent the bug being closed so he could keep pushing them (in a subjectively prickly fashion) for more answers about their general responsiveness.<p>A bit of back and forth discourse is fine and expected, but if you keep pushing someone who has their own legal dept they&#x27;re eventually going to wander over to the coffee machine and have a chat about it with them, then they&#x27;re going to take a look and it becomes their problem.<p>So the number one rule would be don&#x27;t even breath the word &quot;legal&quot; unless you want to invoke them. This particular response is just a letter telling them to back off and it&#x27;s why you have a legal dept, so they can argue with each other. This one has just found it&#x27;s way into the open.<p>There is a understandable perspective that says CAs shouldn&#x27;t be burdened with legal risk in their discussions, but that&#x27;s contrary to the fact these guys are commercial entities protecting their interests, so you don&#x27;t get it both ways unless all your CAs are non-commercial, and even then that would only extend so far.
评论 #43173103 未加载
评论 #43168711 未加载
评论 #43192155 未加载
infogulch2 个月前
This is shocking to read. Even attempting to choke the legal speech of web PKI contributors with legalistic bullying is a gross inversion of the purpose and goals of the organization, and IMO warrants revoking everything to do with DigiCert on the spot.
评论 #43173309 未加载
xmodem2 个月前
Looking at the original report ( <a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1910322" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1910322</a> ) I can see a couple of questions that DigiCert appears to be avoiding:<p>&gt; The public record of Alegeus Technologies LLC v. DigiCert shows no attempt by DigiCert to contest the court’s order prior to the end of its preferred period of nearly 120 hours, even though such a motion could have freed DigiCert to revoke the certificates days earlier.<p>and<p>&gt; The other question in comment 28 was for the language establishing DigiCert’s right to revoke Alegeus Technologies certificates. DigiCert has waffled on this point, first implying that this language was to be found on its website but later refusing to confirm that the language on the site applied to Alegeus Technologies at the time.<p>SPECULATION: Digicert may have offered special terms to Alegeus, and possibly other customers. They may have chosen not to dispute the TRO in court because they did not have grounds to do so under those agreements. They may also have included confidentiality terms in those contracts that prevented them from speaking about it.<p>OPINION: I am surprised that the forum allowed the issue to be closed without the above quoted questions being satisfied, though it is possible they are addressed elsewhere, I have not done a complete reading of all the linked issues.<p>EDIT to add: DigiCert has a response in a different thread here: <a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1910805#c43" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1910805#c43</a> that would appear to contradict my speculation. Specifically<p>&gt; Even though DigiCert’s TOU and MSA prohibited Alegeus from taking the action it did, once it filed for a TRO and the court almost immediately granted it, DigiCert’s hands were tied
评论 #43180769 未加载
tbrownaw2 个月前
So what&#x27;s happened in the ... two months and a bit since the dates mentioned for the letters that this is apparently in reference to?
评论 #43176174 未加载
评论 #43174462 未加载
aaronmdjones2 个月前
Certificate authorities have enormous trust placed upon them by every Internet user (whether they know it or not). Commensurate with this trust, they have enormous responsibilities. As the name implies, the Baseline Requirements are the <i>minimum</i> standard they should achieve. If they can&#x27;t even do this (being unable or unwilling to revoke issued certificates within the required time-frame), then they do not deserve this trust, and it should be removed.<p>I understand that the TRO prevented them from revoking approximately 70 certificates, and there really is nothing they could have done differently in that case. Their other revocation failings are inexcusable.
ziddoap2 个月前
Bug has been updated with a DigiCert response.<p>Obviously draw your own conclusions, but I actually laughed out loud at the following statement from DigiCert:<p>&quot;<i>In reality, our letter to you was consistent with our desire to promote open and honest dialogue.</i>&quot;
Arnavion2 个月前
Even taking the (one-sided) depiction of the conversations in DigiCert&#x27;s letter at face value, maybe Sectigo&#x27;s guy was being a git at best and intentionally trolling at worst. (I don&#x27;t think he was, but let&#x27;s play devil&#x27;s advocate.) But even then, how did DigiCert think getting legal involved would possibly go well? Sectigo stands to gain publicity and lose nothing by going public with it to the CAB as they did here, and it&#x27;s not like the CAB is going to play marriage counselor and get the two companies to make up because one of them got their feefees hurt.<p>Besides, this kind of hyper-polite passive-aggressive &quot;erm akchually&quot; conversation happens in every CAB incident discussion. I don&#x27;t know why DigiCert got particularly upset about this one.
评论 #43168492 未加载
terom2 个月前
It&#x27;s fascinating that we&#x27;ve built a system that has expended perhaps several million dollars of engineering, legal and admin etc time over the issue of a single letter not being capitalized [1], without any demonstrable impact beyond a failure to meet ambiguous specifications.<p>I do hope that dealing with all of the underlying issues around revocation etc makes the time and effort spent useful, and the Web PKI doesn&#x27;t just mire itself in squabbling that blocks progress on actually meaningful issues.<p>[1] <a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1894560" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1894560</a>
评论 #43169584 未加载
评论 #43169425 未加载
评论 #43169488 未加载
naitgacem2 个月前
Can someone point to where i can read some context?
评论 #43168730 未加载
nightfly2 个月前
Can someone link to (or post copies of) the offending questions&#x2F;statements?
评论 #43168211 未加载
csense2 个月前
This is a really stupid situation all around.<p>To issue a cert for a client (say example.com), the CA sends a random number challenge to the client (say 12345678). The client then responds by making a DNS record for _12345678.example.com but due to a bug, DigiCert accepted 12345678.example.com instead.<p>Apparently there&#x27;s a rule that says any such certs must be considered mis-issued and must be revoked by the issuing CA within 24 hours.<p>The CA talked to some clients who said it would be too much trouble to replace their cert on such short notice. One of those clients filed a lawsuit with the court system, which responded by issuing a restraining order telling the CA not to revoke the cert.<p>First of all, this is a dumb reason to revoke certs. It&#x27;s difficult to imagine a situation where any of the mis-issued certificates correspond to an actual compromise of somebody&#x27;s website by a bad actor. But we can perhaps give the benefit of the doubt: I think the intent here is a fail-safe procedure is implemented so revocation is triggered by a broad class of circumstances, which is constructed so that it&#x27;s easy to check.<p>Second, this is a dumb thing for a website to file a lawsuit about. If you have to replace the cert on your website because your CA made a booboo, the engineer-hours needed to change out your new cert are far less than the lawyer-hours needed to try to work through the court system.<p>Third, it&#x27;s dumb for people to blame DigiCert for the TRO. The TRO was filed by a service provider called Alegeus. If DigiCert doesn&#x27;t follow the TRO, they&#x27;ll be in contempt of court. Theoretically, a DigiCert employee who presses the &quot;Revoke&quot; button at this point could be sent to jail for it!<p>Fourth, a certificate revocation is basically a signed message that says &quot;News Flash: I think this certificate might not correspond to this website.&quot; A court preventing the publication of such a message is equivalent to a court preventing a newspaper from publishing an article. This is called &quot;prior restraint&quot; and it has a high bar in the US. Prior restraint analysis was not performed by the court before the TRO was issued. I think the court violated DigiCert&#x27;s due process rights (by not analyzing whether prior restraint applies) and DigiCert&#x27;s free speech rights (by not denying the TRO as it would be prior restraint). (That browsers have a hair-trigger response to certain kinds of news flashes and will take drastic action isn&#x27;t the fault of the publisher of the news.)<p>Fifth, it&#x27;s obvious there ought to be some technical means to prevent this kind of situation in the future: What is the protocol to handle a case of a CA refusing (or court-ordered not to) revoke certs known to be compromised? I think you need to have a system that allows a quorum of CA&#x27;s <i>not including the issuing CA</i> to speedily revoke certificates, or an entire CA. (A public real-time quorum of a dynamic set of validators passing messages they want to reach consensus on: Perhaps this is a good use case for a blockchain?) Of course you also have to deal with the problem of, what if the next TRO targets the entire validator set? You&#x27;d need to be sure those participants are jurisdictionally diverse (or anonymous) so it would be difficult for a single entity to compromise the entire system at once.
评论 #43176905 未加载
评论 #43176098 未加载
kuon2 个月前
What is the actual impact on infrastructure? Is it just some old certificates being valid past expiration?
评论 #43173357 未加载
mightysashiman2 个月前
Streisand effect 101?
registeredcorn2 个月前
Fascinating. I think there was a fair amount of snark on both sides, but I do think some good points were raised by both, as well.<p>1) To DigiCert&#x27;s point: If certs need an emergency revocation <i>but</i> it will impact a service which say: provides life saving services, or keeps the electricity on for the majority of a country, would it not be wise to file them as a one-off &quot;exceptional circumstance&quot;. I think that common sense should prevail and everyone can agree that, &quot;Yes, computer security is absolutely essential. Essential services are <i>also</i> essential.&quot; I wish that that was the direction the debate had gone in.<p>For instance, What is considered an &#x27;exceptional circumstance&#x27;? What kind of services are covered, and what are not?<p>Personally, I would think that things like: health, heat, water, electricity, and physical security (prison and law enforcement) are all potentially essential areas. They are industries that ought be able to <i>request</i> an emergency, 48-hour exception if they know they can&#x27;t meet it within 24 hours and their services will go down as a result. I feel like two days should be enough time for just about any organization to work through a certificate issue, unless it&#x27;s a long holiday, or something very, very niche.<p>I think that, to a degree, Tim Callan (Setigo CEO) was being unreasonable in expecting DigiCert to not offer any kind of possibility for exceptions. Some services should not go down, just because it goes against the principals of computer security. It hate saying that, but it&#x27;s true. Keeping the ICU running matters more than whether the hospital is following best security practices during an emergency.<p>Could it cause more problems by ignoring best practices? Possibly! Will enforcing best practices possibly kill someone? If the answer is anything other than a firm &quot;No&quot;, then it is secondary to protecting that service.<p>2) To Sectigo&#x27;s point: We should not allow any CA to hide behind Policies or poorly written MSAs. If things went the way they did because they were <i>allowed</i> to go that way, then that means you should learn from those things in the post mortem! Take steps to shore it up! Try and prevent other companies from following suit, otherwise more <i>will</i> take action whenever it meets their own best interest. It is disappointing that this part seems to fell into snarky retorts too, because there were some legitimate means to discuss this.<p>For instance: Instead of barring from someone from being <i>allowed</i> to file a TRO, simply have an agreement in place that <i>before</i> any legal action like a TRO is filed, the customer will meet with the CA and a emergency mediator. Just take 30 minutes to one hour to see if you can work things out <i>before</i> the customer submits a TRO!<p>It seems logical, right? If a customer has the cycles to file for a TRO, they should have the time to spare talking to the company they are filing a TRO against. Explain a clear reasons to a mediator <i>why</i> the TRO is needed, and <i>why</i> they can&#x27;t get it done in time. Assuming that the customer can explain all of that in clear terms, it would then be obvious for DigiCert to <i>acknowledge</i> that level of criticality and &quot;exceptional need&quot;, and offer their customer an emergency, temporary exemption.<p>Neither side wants a TRO! It makes DigiCert look weak during an emergency, and it makes Alegeus (the company that filed the TRO) look incompetent, desperate, and underhanded.<p>The crux of what Tim Callan (Sectigo) was getting at, is that there needs to be a correction to DigiCert&#x27;s policies. It&#x27;s blaringly obvious. DigiCert were, in a way, &quot;legally attacked&quot; in a manner that should be prevented in the future, as best they can prevent it.<p>DigiCert lackadaisically shrugging their shoulders and saying &quot;B-But...that goes against Mozilla policy!&quot; is just deflection and meaningless. DigiCert can go to the trouble of sending legal council after Sectigo for comments on Bugzilla, but they <i>can&#x27;t</i> use legal council to protect DigiCert from surprise TRO&#x27;s? Really? Bugzilla feedback...<i>that</i> is the legal issue? Not DigiCert being sucker punched by their own customers?<p>The whole thing is just so aggravating. Both sides need to get over themselves and try to work together. They don&#x27;t need to like each other, but they should do what is best for the industry. Each side sending out daddy lawyer to fight for them completely misses the point, and kills the chance for constructive feedback.
评论 #43177533 未加载
评论 #43178665 未加载
DeepSeaTortoise2 个月前
Why do you all think DigiCert handled this badly?<p>1. Bugs happen. Critical ones, too. They didn&#x27;t try to brush this under the carpet, but admitted to it, acted to resolve it and were transparent about it.<p>2. They worked quickly to make it happen. Would 24h been nice? Sure, but 24h is not much shorter than 120h. In general, 24h is plenty of time for some exploits and 120h doesn&#x27;t open the window to many more. It would have been very different if it took them months or years to resolve it.<p>3. They genuinely engaged with the critics on bugzilla, even after Sectigo&#x27;s CCO went completely off the rails with trying to strip customers off legal recourse and demanding to blacklist those who try to make use of it.<p>4. They could have taken legal actions against Sectigo&#x27;s CCO directly but took the extra step to ask them to stop this nonsense. They didn&#x27;t demand anything more and even outlined steps Sectigo needed to take to prevent any legal problems down the line, like affirming that their CCO did not make these statements on behalf of Sectigo, an affirmation that they would notify their employees to not make any actions that would violate the laws mentioned in their letter, affirm that their CCO would be instructed not to violate any of the laws outlined in their letter and lastly confirm that, upon consulting with their CCO, they were able to conclude that his statements were not meant to harm DigiCert.<p>The only ick is the short timeframe they expect a reply within, but that&#x27;s sadly usual corporate US law practice...<p>Basically that letter is the result of asking an US law firm for help and telling them to be nice about it and helping their opponent through the process.
评论 #43172258 未加载
评论 #43172408 未加载
评论 #43172636 未加载
评论 #43172614 未加载
评论 #43171535 未加载