Looking at crt.sh | 14427905758 it appears the FBI is now using Cloudflare to issue certificates to seized websites in order to avoid browser warnings or errors related to the site no longer being secure.
Cloudflare may use various Certificate Authorities in its CDN edges. Sometimes they even use Let's Encrypt. That is just how Cloudflare works.
Is there some point unique to Let's Encrypt that you want to point out?
7 Likes
I believe in this case Cloudflare is the subscriber, not the FBI. And Cloudflare hasn't seized anything, as I understand it they're just providing services to the FBI. So from my perspective this is more of a question as to whether the FBI's usage of Cloudflare is in alignment with Cloudflare Terms of Service.
6 Likes
Looks like the origin of this seizure was for the domain's DNS which the FBI then pointed to that Cloudflare edge
fox-news.top. 3600 IN NS ns1.fbi.seized.gov.
fox-news.top. 3600 IN NS ns2.fbi.seized.gov.
6 Likes
If the FBI is using their own nameservers then wouldn't that mean they are responsible for all DV requests? Maybe LE could give some friendly contact, even as a heads-up, as to the policy?
1 Like
No such relationship exists AFAIK. Let's Encrypt has clarified in the past that the subscriber is the entity requesting (and using) the certificate. The FBI doesn't request or use the certificate, Cloudflare does. Who owns or operates the nameservers has zero relevance to that.
7 Likes
You are asking pretty open-ended questions. Would help if you were more specific.
This looks like a simple case of someone trying to use a look-alike name for a different legal operating business. And, the FBI worked with the domain registrar to control the DNS server which in turn points to Cloudflare and alerts of their seizure to anyone trying to access it.
Cloudflare also used Google CA to get a cert and it is the Google cert I see when connecting to that seized domain. The LE cert may only be held for backup purposes by Cloudflare I don't know. That is a question better asked at their community or support.
As for the LE subscriber policy section 9.6.3 item 2 pretty much addresses this I think. Keep in mind what Nummer said though that Cloudflare is the LE subscriber in this case. My reason for mentioning this is that it looks to allow use of LE certs for legally seized domains.
6 Likes
As I understand it, the ability of any server to acquire a certificate for a domain name is a direct result of that server either being delegated control of that domain name's DNS zone (TXT or A/AAAA records at least) or being a target of that domain name's address record(s) (A/AAAA). In this case, the latter condition (at least) applies to Cloudflare. As to whom is doing the delegating and whether they have the legal authority to do so is a completely different question and out of scope of concern here.
With what brand of padlock an entity or its delegate chooses to secure a seized asset is ancillary to the ability of the entity to seize the asset.
8 Likes
We had a whole bunch of discussions about this at the very beginning of Let's Encrypt (at least on the EFF side, maybe in the merged group; I know I talked to @pde about it at some length).
The fact that domain names can be seized can be a way that the domain name system doesn't serve some users' interests or expectations, because domain names aren't "secure" in the Zooko's Triangle sense. You can't always be sure that they refer to the person or entity you expect them to, because a legal or regulatory system can intervene to break that link. (Edit: I guess it's actually more usual to say that they aren't "decentralized"; they're also not "secure" to the extent that you don't agree with the decisions of the people managing the system, but I think I've misplaced my Zooko-analysis by emphasizing "secure" there.)
There are other naming systems that try to prevent involuntary transfers of names, at least at a technical level (the name is considered to belong to someone who possesses an associated secret, and no one can override that association). Namecoin and some other blockchain-based naming systems are famous examples. HPKP, which has now been deprecated, is the closest that the mainstream browser ecosystem has come to that—there you could make long-lasting pins which would continue to be enforced by browsers, and would in principle be enforced on the client side regardless of domain name ownership transfers.
One can also argue that some of the mechanisms that have been created for domain seizures are sometimes supportive of end users' ability to use domain names to reach or identify the parties they expect. For example, probably most uses of UDRP seizures (on trademark grounds) are against people who were actually impersonating a brand in order to trick end users—but certainly many of them aren't, because trademark law isn't perfect at anticipating (or caring about) users' beliefs or expectation, and not all users believe or expect exactly the same thing.
I personally think domain name seizures are mostly a misfeature in DNS, mainly because users should have an interest in being able to use DNS to find and refer to the parties they expect. But I admit this is a murky question because so many people have so many different understandings of what DNS names are supposed to mean (if anything).
However, the actually deployed Let's Encrypt service (and the CA/B Forum) have never questioned the idea that the domain validation to which CAs currently attest is based on ownership as determined by the ICANN DNS root, or possibly of additional names which are not in conflict with it (e.g. .onion following the issuance of the associated RFC). If the ICANN processes determine that domain name ownership should be transferred for some reason, certificate authorities might in principle want users to be able to be aware of that, but they don't second-guess or contradict it.
I think that CAs ought to do more to inform users when domain name ownership has changed (and potentially to allow users to choose to deliberately contact the previous owner instead of the new owner), and @pde, at least, would have been interested in exploring potential mechanisms for that. In principle, for example, it might be possible to have some kind of client-side pinning enforcement again, including one that CAs could help support via an extension. But we don't have any technical mechanism available for that right now, and there's no way that CAs would try to tell ICANN what to do in terms of determining domain ownership. If the CAs tried to do that, I believe they would just lose: most of all, I think browser vendors wouldn't agree that this is in end users' interests, and they wouldn't allow CAs to remain trusted if the CAs actively tried to override and contradict ICANN decisions.
Let's Encrypt could conceivably amend its terms of service to say that Let's Encrypt certificates must not be used on seized web sites, based on the idea that the operators consciously intend to trick users into connecting to someone that they know the users didn't intend to talk to. (For example, if a site has been seized by law enforcement, some users might not want to connect to the new version at all because they don't want law enforcement to collect any data about them.) But how to define that is also something of a thorny question.
7 Likes
I want to personally thank you, @schoen, for taking the time and effort to provide the history and clarity you have here. Regardless of what discussion may or may not arise, it's efforts like these that make the internet a brighter place.
3 Likes
To me, all this somewhat hinges on that word "certificate" and the question of what exactly is being "certified", which, I feel we all know too well here, has led to some thorny discussion and a great many questionable assumptions to the detriment of many who may seemingly have the best of intentions.
5 Likes
Doesn't the TOS stipulate that it is not to be used on seized websites unless there was no content on the sites protected by the 1st Amendment? Presumably the FBI is doing this so they can ensure connections are successful and result in the capture of visitors' IP addresses.
1 Like
The subscriber agreement makes no such stipulation. If you think that it does, share the language that is giving you that impression.
6 Likes
I disagree with this somewhat.
The role of DV certificate is simply to ensure the Certificate is only issued to the actual administrator of the domain. If a domain name has been seized, the ownership has legally changed. I don't see any difference between this situation - a domain transfer compelled by lawful government orders - and a sale initiated/consented-to by a domain owner, or a transfer ordered by a legal court or ICANN.
This is a completely different situation than if a government agency attempted to use LetsEncrypt for a MITM attack and obtained a DV certificate for a domain they do not own.
7 Likes
The end user might not realize that this has happened, or might prefer that it didn't happen. In that case, the administration of the domain name system itself doesn't have its priorities aligned with the end user's. (Any other domain name transfer mechanism can have the same problem.)
4 Likes
That bit is important.
Perhaps ICANN or the CA/B forum can iterate on solutions. Perhaps browsers/libraries will one-day have plugins that detect ownership/dns changes and warn before loading. There are a lot of ways to address this, but none seem appropriate to me at the CA level - much less as the focus of a single CA. (/rant)
7 Likes
Yes, I agree with that. If a CA just decided to fix this by refusing to recognize domain transfers (and continuing to issue certificates to the original domain owner), it would create confusion and fragmentation, and root programs would surely distrust that CA.
6 Likes