In reading this bug[1] I can see that, in the past, Tor has been fingerprinted based on the cipher suites negotiated in the initial TLS handshake. Originally it looks like a copy of the cipher suites in a version of Firefox negotiating with Apache were used -- the goal being that it mimics a standard browser. The result of the bug was that the cipher suite was updated to look like other browsers.

My questions are:

• How effective is this solution? The pluggable transports page [2] shows why this isn't perfect, but is there any information on whether it's currently being used to block connections?
• While a variety of suites are offered only a few can actually be used by Tor. Would a plausible active attack exist where an adversary could force force negotiation using an unsupported cipher in order to verify the host is a Tor node?

[1] https://trac.torproject.org/projects/tor/ticket/4744

[2] https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports

In reading this bug I can see that, in the past, Tor has been fingerprinted based on the cipher suites negotiated in the initial TLS handshake. Originally it looks like a copy of the cipher suites in a version of Firefox negotiating with Apache were used -- the goal being that it mimics a standard browser. The result of the bug was that the cipher suite was updated to look like other browsers.

My questions are:

• How effective is this solution? The pluggable transports page shows why this isn't perfect, but is there any information on whether it's currently being used to block connections?
• While a variety of suites are offered only a few can actually be used by Tor. Would a plausible active attack exist where an adversary could force force negotiation using an unsupported cipher in order to verify the host is a Tor node?