Re: [TLS] The case for a single stream of data

[Colm MacCárthaigh <[e-mail]>]

On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara <[e-mail]>
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