On Wed, 7 Sep 2016 14:24:12 -0700 David Fifield <david@xxxxxxxxxxxxxxx> 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
Attachment:
pgpVKAuC7dERQ.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev