1. 12

  2. 5

    In one of the diagrams on certificate transparency, it looks like the browser agent may be expected to query the log server as an auditor, as part of checking the validity of a certificate.

    Doesn’t that seem like a privacy leak, if every time you visit a TLS site, you (browser) ask a 3rd party if the certificate appears in the trusted log? It seems like that 3rd party would then have the capability to associate your ip with requests for a specific TLS cert.

    1. 2

      Google are implementing the inclusion proof check using DNS mirrors of the log servers - see: https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/view

      The idea is that you already leak the hostnames you’re visiting to your DNS resolver and leaking the requests for inclusion proofs to the same resolver isn’t too different.

      1. 1

        Interesting. Thanks for the link.

        Reading it, it looks like the queries will still go to “log servers”, just using a DNS based channel.

        Each trusted log will have a domain name that can be used to perform CT DNS queries. This domain name will be added to the CTLogInfo stored in Chrome for each log… [snip] Clients will ask for inclusion proofs over DNS, which is meant to be proxied via the clients’ DNS servers. Analysis of privacy implications for using a DNS-based protocol are documented here

        However, in that referenced document there is some clarification..

        Chrome clients receive Signed Tree Heads (STHs) via the component updater, so in order to check for inclusion of an entry all a client has to do is obtain an inclusion proof from the CT log that issued it. However, doing so over HTTPS will expose, to the log, which client observed which certificates.
        To overcome this, a DNS-based protocol for obtaining inclusion proofs was devised. Google is operating mirrors which implement this DNS-based protocol of all CT logs trusted by Chromium.

        Further in that same document it states that STHs dns queries should go over the same resolver path as standard client dns requests, using existing infrastructure.

        That does indeed sound much more reasonable than querying the log servers directly!

        I wonder what the ramifications of MitM’ing (either modifying or simply blocking) those specific dns queries will be. Will this use some in-channel signatures, or rely on dnssec? Seems like /lots/ of overhead (and yet more centralization) compared to HPKP.

        1. 1

          As for centralisation — the evolution of revocation checks (OCSP stapling) are actually scarier, here performing audit is just public service by the browser, not a precondition to connection. CT inclusion proof can be provided inside the certificate.

          As for MitM — these requests are basically signed, STH are obtained via the browser updater, CT inclusion proof is a proof that the certificate has been included in the Merkle tree. If you can break that, you can break SHA256 or Chrome update, and you don’t care about CT anymore. Using HTTPS instead of DNS would not allow to improve the proof size.

          As for HPKP — well, it is just too convenient for ransomware after server takeover. And inconvenient for Let’s Encrypt at the same time.

    2. 4

      If HPKP isn’t an acceptable solution to avoiding certificate mis-issuance

      It’s perfectly acceptable, and it’s both a simpler and more secure method than Certificate Transparency. At least, this is the conclusion I came to after studying these and other systems for the past 2+ years.

      CT logs are append-only and cryptographically verified — using a Merkle tree, just like your favourite blockchain.

      False. Whereas with blockchains there is only one log to verify, in CT there is an arbitrary number of possible logs. If CT isn’t implemented properly, it’s possible to hide mis-issuance. The chance of it not being implemented properly is very high.

      Furthermore, unlike HPKP, CT doesn’t prevent MITM attacks, it can only post-facto maybe detect them.

      A key advantage of CT over HPKP (sorry for the pun) is that verification happens at the level of granularity of a certificate (and its associated trust chain), not a public key. Although it requires more supporting infrastructure than public key pinning, the added flexibility of CT reduces the burden on website operators to exhaustively specify their trust chain.

      That is not a “burdern”, it is what you’re supposed to do. Be clear about who can and cannot issue certificates for your website. CT robs website owners and website visitors of this security. It further makes censorship of all websites easier to do by reducing the number of CAs overall.

      Google could have kept HPKP. They chose to remove it and deprive website owners of this option. In the world of web security protocols, this is almost unheard of. Why did they do this? Because HPKP gives website owners more power and more control over the security of their websites. The reasons they give are deceptive nonsense. The reason many fall for it is due to Certificate Transparency’s extremely complex design, which requires significant time investment to fully grok and compare to alternative systems.

      1. 2

        Very helpful! I saw posts about Chrome removing pinning and was wondering what was going on.

        1. 2

          Expect-CT sounds like something I could reasonably setup on my website and all subdomains.

          Though it might break my internal CA certificates… /shrug Probably gona move those to a .intranet TLD