So I'm not a PKI / Network guy but I do use certificates in my LBs, Proxies ETC. Can anyone tell me why we need to issue certs for IPs that isn't about tracking consumers through the internet? The world already run on domain names with certs.
To me, this looks like LE is creating the infrastructure to essentially fingerprint / tag every home internet users public IP with a certificate that broadcasts their subscriber information making literally everything someone does online trace-able back to them.
to be fair, there is CG NAT to contend with but I imagine that identification can be handled trivially.
So what am I missing? I don't understand what the upside is to the people, again, this really just feels like exploring approaches to de-anonimize the internet as it marches towards being a full fat surveillance grid.
The IP subject alternative names (SANs) in certificates are for servers serving those certificates, not users/visitors utilizing the services of those servers. Issuing a certificate under the ACME protocol requires the controller of an IP address to participate in the ACME protocol. There wouldn't be much purpose in obtaining a server-based certificate for an entity acting as a client (e.g. browser) in such a way. I fail to see the danger here unless someone is planning to utilize their home IP address for providing services on the public internet where the danger would be properly securing their home server for such a purpose.
I think maybe you're thinking that IP-based certs could be sent with client requests to servers, which, while possible, isn't really how the current consumer-service model works. The client/browser would need to have such a cert issued, which would require willing participation (by a controller of the client IP address), then the client/browser (or some MITM entity) would need to willingly transmit said certificate with requests. Even with that, the only subscriber information to be revealed even if the CA were to cooperate in such a scheme would be the IP address of the client in the cert and IP address of the requester of the cert. I could see how sending a cert with a client IP address could bypass the anonymity of proxies and tor and such, but why would anyone send a client cert with such info with requests in those situations where privacy/anonymity is desired. It would be like stapling a government-issued ID to one's forehead while attending a masquerade ball. Nothing would stop one from stapling someone else's ID there instead since there's no way of confirming that said ID belongs to the one behind the mask. There would need to be active participation of infrastructure operators for such a scheme to work and there would be much simpler/cheaper ways of accomplishing such than compromising/leveraging the PKI infrastructure.
So the understanding is that this is a field being added to an x.509 certificate issued via ACME protocol (which is supported by LE, RHEL IDM, DigiCert, Sectigo, SSL.com, Entrust, Keyfactor, GlobalSign, Venafi, AppViewX and more) to track an IP address?
Also, I'm confused why you say this would have to be a ACME-only thing as basically everyone (GlobalSign, Digicert, etc) Offers x.509 certificates? That seems misleading. Everyone who matters supports x.509 and acme so you're making it sound as if this is an opt-in thing when it's both a standard and a ubiquitously protocol.
and we can see the purpose of an x.509 certificate is: a digital document that binds a public key to an identity, such as a website, individual, organization, or device, using a digital signature from a trusted certificate authority (CA).
So the intent / foresight is there. I would imagine it would be TRIVIAL for carrier to implement this by having gateways augmented to sign packets or session data so that it can be verified as it moves through their network to it;s destination. To wit, this is similar to RPKI, Zero Trust networks, and I think but am not sure BGP or it's secure equivalent.
What LE does is make it free to do this, and shifts the burden of the system off the ISP so they could do the tracking without managing the PKI infrastructure.
again, the point of this is we're moving towards dystopia. it's not about what's common now, it's about what advancements and new features could facilitate and if it's possible. which honestly it sounds like it is.
What I'm not sure of is does LE issue client or device identity certificates "like that" and if LE designed for such a scale?
LE removed client cert usage recently. Granted, nothing technical stops someone/something from violating that permission. IP addresses in SANs have been around for a long time. Infrastructure providers wouldn't even need a publicly-trusted cert (from e.g. LE) to accomplish what you're suggesting. They wouldn't even need a cert at all in fact. The whole idea behind PKI is end-to-end encryption between parties backed by sole possession of a private key by an end party where said key is confirmed for usage by a trusted third party (the CA). The two entities doing the communicating (e.g. server and browser) are the only ones who have the ability to decrypt the coms. If you're concerned with tracking who is communicating with what server that's a different problem altogether with lots of ways that could be accomplished. Said actors would need the willing/naive cooperation of virtually all infrastructure from browser to server, which is extremely unlikely to happen. Producing and utilizing client certs for purposes of "IDing" clients is not really what the PKI does.
Let's say for example that a nefarious ISP wants to sign all your outbound traffic with a private key that they tie to your home IP address via a cert containing that private key's public key. They then send that cert and signature along with your traffic so that anyone can confirm said signature. Someone seeing this traffic would need to understand what is happening to utilize this in some way. Sure, only something that has control of your home IP (e.g. your ISP) could prove control over said IP to get a publicly-trusted CA to issue a cert for said IP. The ISP would essentially be confirming via signature that they are the ones originating the traffic since they possess the private key for the signature and assigned the IP address in the cert. We would need to take their word for it that said traffic actually belongs to you via your ISP connecting your traffic to the IP address they assigned to you, which happens anyway. This scheme would essentially leak origination information via the attached cert so long as said cert and verifiable signature remain attached. Of course since all outbound connection requests you make via your IP address pass through your ISP anyhow, it's not particularly difficult to determine to what entities your traffic is supposed to flow. The only thing the signature accomplishes is simply verifying the integrity of the traffic sent out by the ISP which would prevent someone from claiming that another entity had tampered with the traffic en-route to the destination so long as every entity along the way keeps the cert and signature attached. Mind you, the contents of that traffic would likely be encrypted via TLS between you and the destination entity making analysis of the content useless.
I think what I'm envisioning is basically carrier-level PKI. I don't even think it's about in/egress or TLS/SSL on HTTP traffic so much as network level security. With wISPs and satellite internet providers providing internet gateways authenticated with client x.509 certificates instead of simple modems to facilitate service delivery, everything is now attributable to the subscriber, visible, and therefore available for analysis.
so the horrifying thing about this announcement is what appears to be an addition to the x509 certificate schema that enables IP based tracking which I would imagine is crucial in censorship or deplatforming scenarios. The schema of the cert is being extended to handle contengencies necessary to have infratructure devices like routers, firewalls,and switches simply drop packets based on a variety of contengineces facilitate by the schema extension.
I can see from where you're coming, but considering that publicly-trusted certificates are publicly-available to anyone (see https://crt.sh for an example), anyone could attach a cert with your IP address to anything, which doesn't prove attribution. It would be like attaching a picture of Elvis to everything then attributing everything to Elvis. A signature produced by the private key associated with the public key in a cert is the only way to truly attribute origination of any given traffic to particular source(s) listed in said cert via fully trusting in the integrity of the entity doing the signing (e.g. an ISP). This would essentially provide a way for entities further down the pipe to distinguish the origination of traffic, which could enable some kinds of traffic discrimination I suppose. In this traffic tagging, in order to single out a subscriber, the originating entity (e.g. ISP) would need to provide and vouch-for actual identifying information of their IP assignee (the subscriber), which would paint the ISP in a pretty horrible light and likely violate a ton of privacy laws. This scheme is essentially IP-based filtering downstream based on upstream origination information. It essentially defeats proxies that would pass on identifying information by protocol assuming that downstream entities would reject requests without identifying information attached. Digital "let's see your papers", if you will.
So you might be talking about a SAN allowing an IP Address since 2005 via RFC 5280 but my understanding is most public CAs refused to issue such a cert until recently. So widespread deployment and trust in the IP in the SAN isn't common and probably wont uptick until now. My understanding is that it is NOT common for orgnaizations to do this, instead relying on certificates based on DNS name or PKI.
So while technically yeah X.509 has had a field, no it's not supported or adopted until now.
Sure, some client could still send such a cert w/out that EKU to a partner server. But, such coordinating client/server pairs can do whatever they wish to exchange data they don't need a publicly trusted cert for that.
These are not the same thing. IP certificates are supported, and adopted, for over seven years, as you've already been shown. They are not common. They will most likely continue to be uncommon, because with pretty rare exceptions (like DNS), domain names are much simpler and more robust to use than IP addresses.
yeah, for my part I'm of the opinion that Multi-ntional trillion dollar corporations and Universities designated as a flexible institutions of research and innovation don't reflect the industry, small business, and hobbyist/prosumer usage, even if they are subject to similar regulations. That may be unfounded but I do appreciate you sharing these things and helping to broaden my perspective as to what is happening.
It wasn't commonly used — and it will probably continue to not be commonly used — but it has been supported. If someone wanted to use them to track users somehow, they already could have done that.
And it's already dropped on the shortlived profile, which is the only one that allows an IP SAN.
Surely ISPs already know what IPs belong to which subscribers at any moment so they can track data usage for billing and data limit purposes. They can of course also log the IPs you connect to.
"everything is now attributable to the subscriber". Is the concern here is that the ISP and Google search (as an example) collude so they can link your searches to your IRL identity via a certificate that's added to the TCP stream somehow?
I don't see why they'd use LE certificates for this. There's no convenient way to insert personal identity info into these. All certs are also logged into CT, so it'd be found out pretty quickly. A private CA would make much more sense.
IMO it would make even more sense for Google search to just send the IPs+timestamps to the ISP and de-anonymise the user that way.
AFAIK, the main use of IP certs will be DoT/DoH, which improve people's security and privacy in a concrete way.
ISRG/LE's goal is to improve security and privacy. If IP certs were to be abused in some way to undermine this, then I would expect them to intervene to stop it.
