[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Pluggable transport idea: TLS session resumption
Here's an idea for a new pluggable transport. It's just a TLS tunnel,
but with a twist that allows the server's certificate to be omitted,
depriving the censor of many classification features, such as whether
the certificate is signed by a CA, the certificate's lifetime, and
whether the commonName matches the server's IP address. I got the idea
from ShadowsocksR:
https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md#2%E6%B7%B7%E6%B7%86%E6%8F%92%E4%BB%B6
The trick that makes it work is RFC 5077 session tickets. How it's
supposed to work is, the client makes a TLS connection as usual, and the
server sends back a session ticket before beginning the flow of
application data. The session ticket is just a random blob from the
client's point of view; from the server's point of view it's an
authenticated ciphertext that encodes session parameters such as the
ciphersuite and master secret. The next time the client connects to the
same server, it sends the session ticket along with its ClientHello and
the server can skip sending its certificate.
Here's a simple way to adapt session tickets for circumvention. The
client *always* sends a session ticket when making a connection, even
the very first time. The ticket doesn't come from a previous
communication with the server; the client generates the ticket itself.
The ticket could for instance be a random string--the censor wouldn't be
able to distinguish--but we can also use those bits for other purposes.
When the server receives the ClientHello, it *pretends* that the ticket
was a valid one, and finishes the handshake using hardcoded session
parameters, just statically configuring what it would have encoded into
a session ticket.
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.
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)
* statefully track which tickets servers have issued, and block
connections that use an unknown ticket.
* track the fraction of connections that use session tickets on each
TLS server.
* active-probe the server in order to get a certificate, and then look
at certificate features.
We'd have to do some research to find out the distribution of session
ticket sizes in the wild. (RFC 5077 recommends a specific format:
https://tools.ietf.org/html/rfc5077#section-4.)
I didn't think of this idea; it comes from ShadowsocksR and its
tls1.2_ticket_auth plugin.
https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md#2%E6%B7%B7%E6%B7%86%E6%8F%92%E4%BB%B6
The documentation is in Chinese. Here is what Google Translate says in
English:
Analog TLS1.2 handshake at client has a session ticket situation
is connected. Currently complete analog implementation, software
testing through capture perfectly disguised as TLS1.2. Because
there is no ticket so send certificates and other complicated
steps, so the firewall can not make a judgment based on the
certificate. At the same time it comes with the ability of
certain anti-replay attacks. In case of a replay attack is
searched end log in to the service, you can grep "replay attack"
search, you can use this plug-in found in your area there is no
line of interference for TLS. TLS relatively powerless firewall,
anti-blocking ability than other plug-ins should be strong, but
may also encounter a lot of interference, but the agreement
itself will check out any interference, then disconnect
encounter interference, to avoid long waits, so that customers
end browser or reconnect themselves. This plug-in is compatible
with the original agreement (the server is configured to require
tls1.2_ticket_auth_compatible), one more than the original
protocol handshake causes the connection will take longer, use C
# client open automatically reconnect when performed better than
the other plug-ins. Support for custom parameters, parameters
SNI, it sends the host name field, this function is very similar
to the TOR meet widget, for example, is set to cloudfront.net
disguised as a cloud server requests, you can use a comma
separate multiple host such as a.com, b.net, c.org (C # supports
only), then it will randomly use. Note that error settings for
this parameter may cause the connection to be disconnected even
IP is blocked, such as how to set clear then please leave it
blank. Recommended customized parameter settings to
cloudflare.com or cloudfront.net.
This is how a normal ticketless handshake looks
(https://tools.ietf.org/html/rfc5246#section-7.3):
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
This is how the ticket-using transport would look:
(https://tools.ietf.org/html/rfc5077#section-3.1):
ClientHello
(SessionTicket extension) -------->
ServerHello
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev