[tor-dev] Pluggable transport idea: TLS session resumption

[Yawning Angel]

On Wed, 7 Sep 2016 14:24:12 -0700
David Fifield <david at bamsoftware.com> wrote:
> The protocol as just described would be vulnerable to active probing;
> the censor could test for servers by sending them garbage session
> tickets and seeing how they respond. But that's easy to fix. We can,
> for example, let the client and server have a shared secret, and have
> the server treat the session ticket as the client part of an obfs4
> handshake--which conveniently resembles a random blob. If the session
> ticket doesn't pass obfs4 authentication, then the TLS server can
> respond as it naturally would if a client sent an invalid session
> ticket; i.e., issue a new ticket and do a full handshake (then send
> dummy data, I guess). The server can also honor its own legitimately
> issued tickets, but still send dummy data in response. Only clients
> who know the shared secret will be able to access the proxy
> functionality of the server.

Don't use the obfs4 handshake for this (or anything new, really).
It's possible to do better.
 
> In order to block such a transport, the censor will have to look at
> features other than the server certificate. It could, for example:
>  * block all session tickets (dunno how costly that would be)

That's not really feasible, since the correct behavior is to fall back
to the standard handshake, being that this is an optimization.  Though
this depends on what clients do when the connection process is closed
after the ClientHello is sent.

>  * statefully track which tickets servers have issued, and block
>    connections that use an unknown ticket.

This is probably feasible, particularly by the sort of people that have
been looking at ClientHello already anyway.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160908/e0558a06/attachment.sig>