Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But what about clients that aren't browsers?


There is not currently a good story for non-browser clients. Generally, non-browser clients don't enforce CT, and those that do are at risk of breaking if they don't stay on the ball with changes to the CT ecosystem. Browser makers can stay on the ball because they are well-resourced and competently staffed; non-browser apps, not so much.

Case in point: earlier this year a bunch of CT-enforcing Android apps were suddenly unable to establish any TLS connections because Google stopped publishing a JSON file which these apps should never have been consuming in the first place. There was plenty of warning that this would happen, but the author of the Android CT library was not on the ball, and app developers were not keeping their dependencies up-to-date: https://groups.google.com/g/certificate-transparency/c/38Lr9...

I hope this will get better with time and we will find a way to safely extend the benefits of CT to non-browser apps. I think we're more likely to find success with CT than with DNSSEC, but there is no free lunch.


What about them? It's not like any of this technology requires a Javascript implementation to run.


But how prevalent is it that other clients verify a cert is in a CT log?


That's not how CT works! You don't have to go check if a cert is in a log!

(How many client/embedded systems do fully recursive DNSSEC verification? Zero!)


You have to check that a cert includes a signature that it was logged, or you risk accepting a certificate that wasn't logged.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: