Re: [TLS] TLS renegotiation issue

[Florian Weimer <[e-mail]>]

* Eric Rescorla:

> I now have a draft extension up at:
>
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml
>
> Comments welcome.

Most email addresses are incorrect. 8-)

Based on the attack description in the draft, the server can implement
a layering violation and detect a splicing which crosses an
application-layer record boundary (which should result in a hard
error).  If the splicing does not cross a boundary, there is not
really any ambiguity, just a succession of differently authenticated
application records.

What seems to happen in vulnerable applications I've created in a
previous life (but I have no longer access to them, so I can't check
for sure) is that in a HTTP context, you tend to perform a sub-request
within the server to get the authentication information which only
applies to future requests, and use that to answer the
not-really-authenticated request as if it were authenticated.  As a
result, you're still vulnerable even if you refuse to renegotiation in
the middle of an HTTP request message.

So avoiding protocol changes seems to require an API change (to expose
part of the TLS record layer to the application layer, so that
byte-exact authentication information is available) plus extensive
application code changes, potentially resulting in additional
client/server round-trips.

Therefore, I think a protocol change is less invasive (assuming that
it is essentially free-for-all-uses IPR-wise).

-- 
Florian Weimer                <[e-mail]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]