For most of the software on my computer, the developer certificate is enough information to know what software I'm running.
All your ISP can see is certificate hashes, OCSP lookups and DNS queries. It can't know what certificate hash is connected to what developer application…
Presumably that's an unsalted hash so that it can be checked against the list of certificate revocations, so whether it's a hash or not doesn't do anything for privacy. It's the same hash of Slack's dev certificate that every other Slack customer is sending.
Anyone snooping the connection can figure that out and see that my computer said "Check the revocation status of Slack Inc.," and the same goes for literally every other software company's certificate hash.
I'm glad it's being fixed but it's still bad that it was done this way in the first place.
It's not hard to match up a certificate hash to the issuer, because most issuers will likely only have a couple of certificates to simplify internal PKI. It's something that can be solved with a rainbow table, there aren't even salts involved.
It's not hard to match up a certificate hash to the issuer, because most issuers will likely only have a couple of certificates to simplify internal PKI.
These are Apple certificates; they have nothing to do with a company's internal PKI.
It's something that can be solved with a rainbow table, there aren't even salts involved.
2. The OCSP check get cached; the certificate lookup doesn't happen every time you launch an app.
3. You can block the OCSP lookup if you're all bent out of shape about it or strip the developer's signature and sign it using a different certificate.
4. The new protocol for checking will be encrypted and there will be UI for opting out of these checks.
All your ISP can see is certificate hashes, OCSP lookups and DNS queries. It can't know what certificate hash is connected to what developer application…