On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > Doesn't this imply that clients or CDN are using unsafe HTTP methods in > 0-RTT data? Which is of course _seriously_ broken. >
It doesn't really. First; the CDN may be acting as a Layer 4 TLS proxy. Some CDNs sell these as SSL accelerators that work by moving the handshake closer to clients and do almost nothing else. For example S3 Transfer acceleration works like that: http://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html . In that case, the TLS proxy isn't necessarily even aware of the under-lyling protocol. Will they be able to resist the easy-to-enable 0-RTT time savings? But secondly, in the real world, these can be GETs and that's how many APIs are constructed. Why? because even though it ignores correct REST principles, people can test and compose these operations more easily from the command line (e.g. curl). We've all seen many APIs like this. Because HTTP specification expressly forbids any and all updates and > writes using safe methods. Ignoring that causes very severe security > vulernabilities even today (e.g., causes essentially undefendable CSRF > attacks). > These aren't browser requests, they can be SDK and other clients making HTTP API requests. That's much more common too, by volume. CSRF isn't an issue in cases like that. I think everything I'm writing applies even for a careful REST-compliant case too. Even if the client is using PUT or POST or DELETE or whatever, the same kind of transactional semantics apply. All it takes is a disconnect between the settings in any of the middle transport layers and the expectations of the underlying protocol. I just think that disconnect is very predictable. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
