* Domain apple-id-2.com is not currently registered
* Domain apple-id-2.com has (apparently) never been registered
* LetsEncrypt, on 2017-01-03, issued a valid certificate for apple-id-2.com
Since we can't know how validation was successfully performed, all we can do is speculate. Someone from LetsEncrypt will have to investigate and let us know. Fortunately, they should have very detailed audit logs for exactly this purpose.
I wonder if maybe someone had that domain and then deleted it. Dynadot(and probably others) for example lets you delete domains for a partial refund within a certain limited amount of time - which I think is a neat feature.
I know there are historical whois sites, but as far as I know unless someone in the past checked for the domain with their service, they'd have no record of it otherwise. So maybe that would explain how it has a cert for a domain that currently does not exist and appears to never been registered.
That might be possible. A lot of these "domain info" sites receive a daily feed from the registries (i.e. Verisign) that include all domain registrations, renewals, etc., so I would think they'd have it in their database even if that happened.
What is unusual is that if someone had it and then deleted it, it doesn't still show up in the whois records in a 30, 60 or 90 day redemption period. From dealing with a few .net domains that recently expired and went into redemption, it takes a long time for a defunct domain to actually disappear and become re-registerable again by another totally different purchaser.
Redemption period I know of for when domains expire. But if you do the grace deletion it's pretty much instantly. I was debating on a domain once with myself, deleted it and then a day or so later registered it again. Usually you can delete within the first 118 hours on certain tlds.
https://www.dynadot.com/domain/grace_deletion.html has some info about it. I'm only familiar with Dynadot because I use them, but other providers that offer this should have similar information and times.
My guess is they had a localised DNS resolution failure for the domain and some how hit a web server, or something else, that ticked all the boxes and granted the certificate. A long shot, though.
As someone who doesn't know much about the inner workings of the whole TLS stack, why is this surprising? I know in the past I've self-signed certificates for domains that only existed on my LAN. Why couldn't that be the case here? Why shouldn't a central signing authority issue certificates for people's intranets?
I could sign a certificate for 'johndoe.com' without proper verification or I am using it in my local intranet. Let's Encrypt requires external verification to ensure certificates like this one and other miscellaneous certificates are issued.
I've been wondering how that could be done in a practical way. You'd have to register domains that people are likely to register in the next 90 days. You could probably just resell the domains if you were able to predict that.
Best defence against this, if you're worried, is to wait 24 hours after gaining control of the domain, then check Certificate Transparency monitors for issuance in that domain.
(24 hours is the CT Maximum Merge Delay, a correctly operating log promises to be able to reliably and consistently tell the monitors about any certificates logged more than 24 hours ago)
People's general thrust has been that Let's Encrypt's approach means anybody who can control an FQDN can get a certificate for that FQDN and they don't like that.
One group object that DV (Domain Validated) certificates which only validate control over the FQDN just shouldn't exist at all. They believe you should need to prove a "real world" identity to someone or else not be able to have a certificate. Obviously that would put HTTPS back to pretty rare, because proving real world identity costs money and requires some effort, whereas DV has been completely automated.
Another group are fine with DV, except that they have an objection to nebulously defined "obviously bad" FQDNs. They argue (and they're not entirely wrong) that humans try to parse the FQDN for sense, and it leads them astray. They see microsoft-helpline in the FQDN and conclude it's a Microsoft helpline, or they see mybank-login-page and figure it's the log in page for their bank...
Changing either of these things would be a radical policy alteration for the Web PKI. In the anti-DV group that might actually be seen as a good thing, a handful of CAs literally don't offer DV, their businesses could actually grow if DV were abolished.
Right now, the Baseline Requirements which control how a public CA should behave to stay trusted in the Web PKI, say the CA must have a "High risk" list which protects some FQDN from being issued without human oversight. Let's Encrypt do operate such a list and since they have no human oversight if you hit the list you just can't get a certificate - about once a month somebody asks on their public forum about such a name, e.g. aa.edu ran into this, so did some outfit with the same initials as Deutsche Bank. However the BRs don't specify what must be on the list at all.
I don't happen to think any of this is "shady" on the part of Let's Encrypt, but some people do.
> Not totally surprising as I have never seen Let's Encrypt do anything that could be remotely considered diligence in not doing shady stuff.
With SSL/TLS that is only "domain validated" that's a problem with any registrar, whether it's a commercial $11/year certificate or a free one from LE. There is very little that you need to prove to get an SSL cert with domain validation, all that you need is control over the domain registrar nameserver records so that you can point the ns1, ns2, ns3 etc records at nameservers you fully control. You only need to prove that you can insert an arbitrary TXT record in the DNS records for the domain (thereby proving you "control" it). Or host a small text file on an httpd that answers on an IP where domainnname.com's A record maps to that IP. There is no other proof of entity status or control required.
I could go out right now and register super-happy-funtime-googleplaystoreverification.com, set the ns1 and ns2 for it to a couple of bind9 servers that I control, make a zonefile, and point the A record for the hostname at an IP that I control (a throwaway $2/mo VPS) and get a DV validated SSL cert.
This is why things like EV SSL certs were invented.
Any person with a prepaid visa card from walmart, a $3/mo hosting package and a little bit of knowledge can get an SSL cert that is DV only.
Head of Let's Encrypt here. Our team is looking into this and so far we don't see any evidence of mis-issuance in our logs. It looks like the domain in question, 'apple-id-2.com', was registered and DNS resolved for it successfully at time of issuance. Here is the valid authorization record including the resolved IP addresses for 'apple-id-2.com':
Since there are a myriad of registrars that can register .com , and it was apparently registered and domain-validated successfully at the time of cert issuance. Is there any way that LE can obtain from Verisign a historical copy of the whois record as it appeared for the domain at the time it was issued, while the domain was live? I'm hoping that verisign keeps such historical records for expired or deleted domains.
edit: In addition to all of the data currently captured via the ACME client challenge/response, would it not be a good idea for LetsEncrypt to store a copy of the 'whois' record for a domain at the time a new cert is issued? In a worst case scenario for a .com domain, all of the registrant details can be opaque and hidden behind a privacy proxy, but it will have at least one functioning authoritative nameserver, and the hostname and IP address of that authoritative nameserver can be stored forever.
This could help to track down future abuse in the event that large numbers of suspiciously named domains can all be correlated to a set of common authoritative nameservers.
but it will have at least one functioning authoritative nameserver, and the hostname and IP address of that authoritative nameserver can be stored forever.
The authoritative nameserver could have been ns1.apple-id-2.com with an IP of 198.185.159.145, which would not provide any more information than is already present.
Yes, that's true, it's entirely possible to host the start of authority (SOA) authoritative DNS for a domain on the same IP that is also an httpd or hosting a myriad of other services. But if that information was captured at least it would be known that was the configuration at the time the cert was issued.
edit: there are a number of shady black market things that use very short TTLs and "fast flux DNS" for phishing and scam traffic relay/proxy purposes. In the event that a large number of spurious domains were registered and part of a larger botnet, it's valuable data to know that fast flux is indeed in use, or rule it out.
Whois and resolving is not the same concept. Resolving require a name server and a record in a root name server that leads to them, while whois is a free text business record that may or may not exist, and all icann can do is to try enforce policies over registrars so they update and maintain correct records.
I doubt lets encrypt has whois records. Automatic retrieval of such records is general disliked/forbidden, a major pain to parse (free text), and its not part of any current LE authentication mechanism. They could however include the resolve data of the domain in the public logs, which would include name servers names and their ip-addresses.
More specifically, if anything truly weird is going on, hopefully Squarespare abuse/network operations would cooperate to investigate who had that IP at that particular point in time.
Since let's encrypt gives a certificate to anyone who can make DNS temporarily resolve to them, it seems like the most plausible answer is that someone managed to send spoofed DNS responses to let's encrypt.
If the CA system is only as secure as the DNS, that means we really need to increase DNSSEC deployment, and maybe LE should make DNSSEC mandatory for domains they issue certificates to in this way.
The attack vector DNSSEC would protect against is DNS spoofing by an active MitM.
That sort of attack might only be possible for nation state adversaries (or maybe it's not that hard to intercept LE's DNS requests) but I suppose that for many nation states it would be cheaper just to force a CA operating in their country to issue them a fraudulent certificate if they wanted to spoof a specific domain.
It seems like if our attack vector is "a nation state willing and able to subvert companies operating in their country", DNSSEC and the existing x509 CAs are both equally threatened, with the downside that Chrome/Firefox can't delist a TLD when somebody discovers the malicious usage
Yes, I was indirectly making the point that against such an adversary both systems are equally threatened (although there may be malicious actors less capable than a nation state that can spoof a DNS response).
One difference you didn't mention, though, is that with DNSSEC the domain owner can choose which TLD they register under, whereas it is less common for a site to specify which CAs are allowed to issue certificates for it (especially in a way that works if the browser hasn't visited that site yet).
The mechanism by which sites (well, domains) can specify which CA may issue is named CAA, it's part of DNS and is an IETF standard.
However, the current Baseline Requirements for trusted CAs don't actually require them to check CAA unless their declared policies say that they check. Let's Encrypt's policies say so, as do Symantec's but many others do not.
Gerv (of Mozilla) is trying to get this changed, either by industry agreement in the BRs, or de facto by changing the Mozilla root programme rules if the CAs try to block changing this in the BRs or keep stalling too long.
43 comments
[ 3.1 ms ] story [ 82.0 ms ] thread* Domain apple-id-2.com is not currently registered
* Domain apple-id-2.com has (apparently) never been registered
* LetsEncrypt, on 2017-01-03, issued a valid certificate for apple-id-2.com
Since we can't know how validation was successfully performed, all we can do is speculate. Someone from LetsEncrypt will have to investigate and let us know. Fortunately, they should have very detailed audit logs for exactly this purpose.
I know there are historical whois sites, but as far as I know unless someone in the past checked for the domain with their service, they'd have no record of it otherwise. So maybe that would explain how it has a cert for a domain that currently does not exist and appears to never been registered.
https://www.dynadot.com/domain/grace_deletion.html has some info about it. I'm only familiar with Dynadot because I use them, but other providers that offer this should have similar information and times.
In terms of technical limitations, nothing stops any CA from issuing any cert they want. It's the business consequences that stop them from doing so.
If Let's Encrypt wants to keep themselves on the trusted-root-CA list of Windows, Chrome, MacOS, et. al., they need to keep their noses clean.
(24 hours is the CT Maximum Merge Delay, a correctly operating log promises to be able to reliably and consistently tell the monitors about any certificates logged more than 24 hours ago)
https://crt.sh/?id=72482400
There's some evidence that apple-id-1.com existed back then:
https://www.thedailywhois.com/2017-01-03/apple-id-1.com
;; ANSWER SECTION: apple-id-2.com. 500 IN A 50.63.202.53
Creation Date: 2017-02-22T21:57:50Z
The cert was issued in January parsed.validity.start 2017-01-03T22:17:00Z
Not totally surprising as I have never seen Let's Encrypt do anything that could be remotely considered diligence in not doing shady stuff.
Jeremiah Gowdy "went ahead and bought the domain until someone figures out what's happening."
Mind elaborating? I'm not familiar enough to know what shady stuff they've done, and I'm a happy user of LE so far. Would love to know more.
One group object that DV (Domain Validated) certificates which only validate control over the FQDN just shouldn't exist at all. They believe you should need to prove a "real world" identity to someone or else not be able to have a certificate. Obviously that would put HTTPS back to pretty rare, because proving real world identity costs money and requires some effort, whereas DV has been completely automated.
Another group are fine with DV, except that they have an objection to nebulously defined "obviously bad" FQDNs. They argue (and they're not entirely wrong) that humans try to parse the FQDN for sense, and it leads them astray. They see microsoft-helpline in the FQDN and conclude it's a Microsoft helpline, or they see mybank-login-page and figure it's the log in page for their bank...
Changing either of these things would be a radical policy alteration for the Web PKI. In the anti-DV group that might actually be seen as a good thing, a handful of CAs literally don't offer DV, their businesses could actually grow if DV were abolished.
Right now, the Baseline Requirements which control how a public CA should behave to stay trusted in the Web PKI, say the CA must have a "High risk" list which protects some FQDN from being issued without human oversight. Let's Encrypt do operate such a list and since they have no human oversight if you hit the list you just can't get a certificate - about once a month somebody asks on their public forum about such a name, e.g. aa.edu ran into this, so did some outfit with the same initials as Deutsche Bank. However the BRs don't specify what must be on the list at all.
I don't happen to think any of this is "shady" on the part of Let's Encrypt, but some people do.
With SSL/TLS that is only "domain validated" that's a problem with any registrar, whether it's a commercial $11/year certificate or a free one from LE. There is very little that you need to prove to get an SSL cert with domain validation, all that you need is control over the domain registrar nameserver records so that you can point the ns1, ns2, ns3 etc records at nameservers you fully control. You only need to prove that you can insert an arbitrary TXT record in the DNS records for the domain (thereby proving you "control" it). Or host a small text file on an httpd that answers on an IP where domainnname.com's A record maps to that IP. There is no other proof of entity status or control required.
I could go out right now and register super-happy-funtime-googleplaystoreverification.com, set the ns1 and ns2 for it to a couple of bind9 servers that I control, make a zonefile, and point the A record for the hostname at an IP that I control (a throwaway $2/mo VPS) and get a DV validated SSL cert.
This is why things like EV SSL certs were invented.
Any person with a prepaid visa card from walmart, a $3/mo hosting package and a little bit of knowledge can get an SSL cert that is DV only.
https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...
We can't be sure why the reporter was unable to find a WHOIS record, we can only confirm that validation properly succeeded at time of issuance.
Update: Squarespace has confirmed that they did register the domain and then released it after getting a certificate from us.
edit: In addition to all of the data currently captured via the ACME client challenge/response, would it not be a good idea for LetsEncrypt to store a copy of the 'whois' record for a domain at the time a new cert is issued? In a worst case scenario for a .com domain, all of the registrant details can be opaque and hidden behind a privacy proxy, but it will have at least one functioning authoritative nameserver, and the hostname and IP address of that authoritative nameserver can be stored forever.
This could help to track down future abuse in the event that large numbers of suspiciously named domains can all be correlated to a set of common authoritative nameservers.
The authoritative nameserver could have been ns1.apple-id-2.com with an IP of 198.185.159.145, which would not provide any more information than is already present.
edit: there are a number of shady black market things that use very short TTLs and "fast flux DNS" for phishing and scam traffic relay/proxy purposes. In the event that a large number of spurious domains were registered and part of a larger botnet, it's valuable data to know that fast flux is indeed in use, or rule it out.
https://www.google.com/search?q=fast+flux+dns+malware&ie=utf...
I doubt lets encrypt has whois records. Automatic retrieval of such records is general disliked/forbidden, a major pain to parse (free text), and its not part of any current LE authentication mechanism. They could however include the resolve data of the domain in the public logs, which would include name servers names and their ip-addresses.
NetRange: 198.185.159.0 - 198.185.159.255 CIDR: 198.185.159.0/24 NetName: SQUARESPACE NetHandle: NET-198-185-159-0-1 Parent: NET198 (NET-198-0-0-0-0) NetType: Direct Assignment OriginAS: AS53831 Organization: Squarespace, Inc. (SQUAR-30) RegDate: 2013-01-15 Updated: 2013-01-15 Comment: http://www.squarespace.com Ref: https://whois.arin.net/rest/net/NET-198-185-159-0-1
OrgName: Squarespace, Inc. OrgId: SQUAR-30 Address: 225 Varick St City: New York StateProv: NY PostalCode: 10014 Country: US RegDate: 2012-04-26 Updated: 2017-01-04 Comment: https://squarespace.com Ref: https://whois.arin.net/rest/org/SQUAR-30
OrgNOCHandle: SYSTE409-ARIN OrgNOCName: Systems OrgNOCPhone: +1-347-758-4644 OrgNOCEmail: systems-net@squarespace.com OrgNOCRef: https://whois.arin.net/rest/poc/SYSTE409-ARIN
OrgTechHandle: SYSTE409-ARIN OrgTechName: Systems OrgTechPhone: +1-347-758-4644 OrgTechEmail: systems-net@squarespace.com OrgTechRef: https://whois.arin.net/rest/poc/SYSTE409-ARIN
OrgAbuseHandle: ABUSE5803-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-347-758-4644 OrgAbuseEmail: abuse-network@squarespace.com OrgAbuseRef: https://whois.arin.net/rest/poc/ABUSE5803-ARIN
That sort of attack might only be possible for nation state adversaries (or maybe it's not that hard to intercept LE's DNS requests) but I suppose that for many nation states it would be cheaper just to force a CA operating in their country to issue them a fraudulent certificate if they wanted to spoof a specific domain.
One difference you didn't mention, though, is that with DNSSEC the domain owner can choose which TLD they register under, whereas it is less common for a site to specify which CAs are allowed to issue certificates for it (especially in a way that works if the browser hasn't visited that site yet).
However, the current Baseline Requirements for trusted CAs don't actually require them to check CAA unless their declared policies say that they check. Let's Encrypt's policies say so, as do Symantec's but many others do not.
Gerv (of Mozilla) is trying to get this changed, either by industry agreement in the BRs, or de facto by changing the Mozilla root programme rules if the CAs try to block changing this in the BRs or keep stalling too long.