General Transparency | Hacker News Reader

General Transparency

certificate-transparency.org

45 pointstosh9 comments

It's kind of weird that this is an HTTP link. It's also kind of weird that certificate-transparency.org doesn't redirect you to HTTPS.

Stranger still as the HTTPS version seems to be in working order.

Key Transparency [0] uses the same model. Too bad the project seems inactive.

[0]: https://security.googleblog.com/2017/01/security-through-tra...

Humans are nosy. This works out to our advantage in Certificate Transparency, not a few problems have been uncovered by people who were just browsing either their own output from CT or https://crt.sh/ and they said, as so often, not Eureka but "Huh, that's weird".

Knowing james.johnson.example was issued a certificate does kinda give away what the Johnsons are calling their new boy baby before they announce it, but the argument that DNS names in the Internet are supposed to be "private" feels intuitively implausible, so we just said "Certificates in the Web PKI are public documents", and it's true because we said so and we meant it. Like those Inalienable Rights.

But in Key Transparency your nosiness gets you nowhere, the privacy concerns were too great, and so a Key Transparency system doesn't tell us anything humans are nosy about. Who has keys? What keys? What can we say about those keys? Out of understandable deference to privacy we learn nothing of interest about these topics.

Still it isn't _that_ inactive, it has changes from July or so in the git repo. Maybe something will yet come of it.

I'd like to see a transparent ledger for software releases, to make targeted malicious update attacks detectable.

Similarly, pinning the hash of the index resource for a web site using a transparent ledger could let web apps be as secure as native apps with auto update.

Have you seen this: https://wiki.mozilla.org/Security/Binary_Transparency?

Build this into a LineageOS release and it would make targetted software replacement quite a bit harder. Thought it would be thankless work that mightn't be worth bothering with.

"we do not claim to support decentralisation"

What a strange statement to make. I feel like such an apparent preference should be accompanied by a very clear explanation of the disadvantages of decentralisation (other than "it's hard and we don't know how to do it").

Ideally, a page discussing the relative merits of centralisation and decentralisation would start with a threat model too, so the reader knows what problems are attempting to be solved, and which are out of scope.

If the people who downvoted me thought that I was being disparaging with my comment of "we don't know how to do it", let me clarify that this was not my intent. What I meant was that there are genuine difficulties in trying to decentralise trust, and I don't think anyone knows how to solve them all right now.

For example, we could store transparency data in a blockchain, which might have independent economic incentives to keep it operating beyond the life span of any individual log provider (and without an individual log provider being able to rewrite history), but how does a piece of software check a value on a blockchain without receiving that piece of information from a trusted intermediary (or better a configurable list of mutually-independent semi-trusted intermediaries)?

Reply on news.ycombinator.com