Hacker News Reader

Comment by jaas | Hacker News Reader

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':

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.

View on HN

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.

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.

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.

https://www.google.com/search?q=fast+flux+dns+malware&ie=utf...

Those are Squarespace IPs too - somebody from there probably can pull some logs and find the user who set up a site on the apple-id-2 domain.

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.

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

A security researcher registered the domain AFTER you issued the certificate, as a precaution.

It was also registered previously (at the time of issuance) and later released by Squarespace, as mentioned in the update.

The IPs seem to belong to Squarespace

Reply on news.ycombinator.com