[HN Gopher] You Should Run a Certificate Transparency Log
___________________________________________________________________
You Should Run a Certificate Transparency Log
Author : Metalnem
Score : 54 points
Date : 2025-07-07 20:36 UTC (2 hours ago)
(HTM) web link (words.filippo.io)
(TXT) w3m dump (words.filippo.io)
| agwa wrote:
| Sunlight and static-ct-api are a breath of fresh air in the CT
| log space. Traditional CT log implementations were built on
| databases (because that's the easiest way to implement the old
| API) and were over-complicated due to a misplaced desire for high
| write availability. This made operating a CT log difficult and
| expensive (some operators were spending upwards of $100k/year).
| Consequentially, there have been a rash of CT log failures and
| few organizations willing to run logs. I'm extremely excited by
| how Sunlight and static-ct-api are changing this.
| eddythompson80 wrote:
| I wonder if this is the solution something like SponsorBlock is
| looking for[1][2]. They have a similar-ish problem. How to
| replicate crowdsourced data that trickles in slowly, but
| ideally you want replicated quickly.
|
| WAL replication, rsync, bittorrent, etc all things that don't
| quite work as needed.
|
| [1] https://github.com/mchangrh/sb-
| mirror/blob/main/docs/breakdo...
|
| [2] https://github.com/ajayyy/SponsorBlock/issues/1570
| tonymet wrote:
| Is any amateur or professional auditing done on the CA system?
| Something akin to amateur radio auditing?
|
| Consumers and publishers take certificates and certs for granted.
| I see many broken certs, or brands using the wrong certs and
| domains for their services.
|
| SSL/TLS has done well to prevent eavesdropping, but it hasn't
| done well to establish trust and identity.
| sleevi wrote:
| All the time. Many CA distrust events involved some degree of
| "amateurs" reporting issues. While I hesitate to call
| commenters like agwa an amateur, it certainly was not
| professionally sponsored work by root programs or CAs. This is
| a key thing that Certificate Transparency enables: amateurs,
| academics, and the public at large to report CA issues.
|
| At the same time, it sounds like the issues you describe aren't
| CA/issuance issues, but rather, simple misconfigurations. Those
| aren't incidents for the ecosystem, although definitely can be
| disruptive to the site, but I also wouldn't expect them to call
| trust or identity into disrepute. That'd be like arguing my
| drivers license is invalid if I handed you my passport; giving
| you the wrong doc doesn't invalidate the claims of either, just
| doesn't address your need.
| Spivak wrote:
| I think over the years trust and identity have gone out of
| scope for TLS--I think for the better. Your identity is your
| domain and it's not TLS's problem to connect that identity to
| any real life person or legal entity. I'm sure you still can
| buy EV certs but no one really cares about them anymore.
| Certainly browsers no longer care about them. And TLS makes no
| claim on the trustworthiness of the site you're connecting to,
| just that the owner of the cert proved control of the domain
| and that your connection is encrypted.
|
| I can't even imagine how much a pain it would be to try and
| moderate certs based on some consistent international notion of
| trustworthiness. I think the best you could hope to do is have
| 3rd parties like the BBB sign your cert as a way of them
| "vouching" for you.
| torbid wrote:
| These sound like good improvements but I still don't really get
| why the ct log server is responsible for storage at all (as a 3rd
| party entity)..
|
| Couldn't it just be responsible for its own key and signing
| incremental advances to a log that all publishers are responsible
| for storing up to their latest submission to it?
|
| If it needed to restart and some last publisher couldn't give it
| its latest entries, well they would deserve that rollback to the
| last publish from a good publisher..
| michaelt wrote:
| The point of CT logging is to ensure a person can ask "What
| certificates were issued for example.com?" or "What
| certificates were issued by Example CA?" and get an answer
| that's correct - even if the website or CA fucked up or got
| hacked and certificates are in the hands of people who've tried
| to cover their tracks.
|
| This requires the logs be held by independent parties, and
| retained forever.
| torbid wrote:
| I understand that. But..
|
| If 12 CAs send to the same log and all have to save up to
| their latest entry not to be declared incompetent to be CAs,
| how would all 12 possibly do a worse job of providing that
| log on demand than a random 3rd party who has no particular
| investment at risk?
|
| (Every other CA in a log is a 3rd party with respect to any
| other, but they are one who can actually be told to keep
| something indefinitely because they would also need to return
| it for legitimizing their own issuance.)
| michaelt wrote:
| As far as I know, CAs don't have to "save up to their
| latest entry"
|
| The info they get back from the CT log may be a Merkle Hash
| that partly depends on the other entries in the log - but
| they don't have to store the _entire_ log, just a short
| checksum.
| singron wrote:
| The publishers can't entirely do the storage themselves since
| the whole point of CT is that they can't retract anything. If
| they did their own storage, they could rollback any change.
| Even if the log forms a verification chain, they could do a
| rollback shortly after issuing a certificate without arousing
| too much suspicion.
|
| Maybe there is an acceptable way to shift long-term storage to
| CAs while using CT verifiers only for short term storage? E.g.
| they keep track of their last 30 days of signatures for a CA,
| which can then get cross-verified by other verifiers in that
| timeframe.
|
| The storage requirements don't seem that bad though and it
| might not be worth any reduced redundancy and increased
| complexity for a different storage scheme. E.g. what keeps me
| from doing this is the >1Gbps and >1 pager requirements.
| torbid wrote:
| If CAs have to share CTs and have to save everything the CT
| would save to their last submission then no CA can destroy
| the log without colluding with other CAs.
|
| (I.e. your log ends abruptly but polling any other CA that
| published to the same CT shows there is more including
| reasons to shut you down.)
|
| I don't see how a scheme where the CT signer has this
| responsibility makes any sense. If they stop operating
| because they are sick of it, all the CAs involved have a
| somewhat suspicious looking CT history on things already
| issued that has to be explained instead of having always had
| the responsibility to provide the history up to anything they
| have signed whether or not some CT goes away.
___________________________________________________________________
(page generated 2025-07-07 23:00 UTC)