5 ms·
This is all the more critical when you consider how the usual web developer handles the complexities of chained certificate verification: namely, by disabling v
by rcoder 17y ago
This is all the more critical when you consider how the usual web developer handles the complexities of chained certificate verification: namely, by disabling verification entirely, and instead trusting every upstream certificate as offered.
For example, as of Rails 2.3, ActiveResource (the default RESTful web service API client used in many Rails applications) disables all SSL verification whenever SSL is used, without so much as a configuration flag to enable it again.
- tptacek 17y agoThis is a meme that needs to die. Users of SSL routinely fall into behavior traps that ruin the security of SSL. That doesn't leave them secure: it leaves them screwed. The problem that SSL is solving (and that applications are failing to solve) is hard. If you can establish relationships between members of your protocol, you can rely on continuity for security. Continuity is what SSH uses. It's easier than authority, and it's sane to recommend that people take advantage of it when possible. But when your users will constantly be enrolling new participants into your system, continuity becomes a huge design risk, just like how everyone used to lose their SSH keys to sniffers at Usenix Security.
- defen 17y agoThis comment went a little over my head - if you don't mind, can you point me to something that explains what continuity and authority are in this context? I'm also curious to learn how people used to lose their SSH keys because of continuity. Thanks.
- tptacek 17y agoThe first time two hosts communicate using SSH, they share no keys and have to exchange them with a handshake. That exchange isn't secure.