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

If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface. Multiple critical SSL/TLS CVEs-- including some we know for a fact the NSA relied on-- came from cipher negotiation.


> If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface.

Not really. The degree of malleability in cipher negotiation is widely considered to have been a Bad Move in SSL/TLS's early design, and modern (well-designed) cryptographic protocols don't enable the kinds of parametric malleability that made SSL/TLS so exploitable at the time.

Signal's protocol, for example, is perfectly interoperable; the lack of interoperability comes from a (not unreasonable) constraint at the application layer, not the protocol itself. Another example would be MLS[1], which supports fixed suites rather than parametric malleability and uses the technique from RFC 8701[2] to prevent clients from getting clever and trying to add their own extensions that undermine the fixed suites.

[1]: https://datatracker.ietf.org/doc/rfc9420/

[2]: https://www.rfc-editor.org/rfc/rfc8701.html




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

Search: