If FBI can sniff all traffic originating from hosting provider, then it seems to be trivial to detect all Tor servers and go through them manually?
Something more like SSH, not relying on central CAs, would be less distinguishable - is it Tor traffic, or is it just someone accessing his/her server remotelly.
Therefore, since Tor tries to mimick common browsers and servers, it must always send a SNI extension.
Right, and since all browsers have no problem with plaintext http, TOR should be okay with it too. You know, to mimic traffic and stuff.
That's the most BS excuse I've ever heard. Sending the domain in the clear on TOR is completely inexcusable. But then, so is having JS enabled by default. Run, do not walk, RUN away from TOR.
Take your FUD elsewhere.
I believe you might be a bit confused with respect to what's in the SNI extension; the domain sent in the clear on Tor connections is not the domain requested by the browser, it is a completely unrelated randomly-generated domain name. Also, even without SNI the same can be found on the opposite direction: the certificate sent in the response also has a randomly-generated domain name.
Everything after the https:// is encrypted. Client does a DNS lookup on the host, but the host name in the request is encrypted. The path is encrypted. The get parameters are encrypted. Everything is encrypted to the server in the request. Everything coming back from the server is encrypted as well.
Team SNI comes along and says, "But we don't really care about security! We want to host multiple domains on the same IP address! How will the server know where to direct the SSL request without the domains?"
And so, in the name of reusing an IP address, security is now compromised for the domain. It is sent outside the SSL request, in the clear.
Is that about right? SNI on TOR? Nice one.
The handshake goes something like this: the client opens the connection and sends several parameters (in the clear). The server replies with its parameters (in the clear) and its certificate (in the clear, and it includes the domain name). Both sides exchange the key to be used (encrypted), switch to encrypted mode, and verify the handshake.
Notice that, even without SNI, the hostname is already sent by the server, in the clear, within the certificate. That poses a chicken-and-egg dilemma: the hostname is sent to the server after the handshake is finished, but the server has to present the correct certificate before the handshake is finished. The solution was to send the hostname (and only the hostname) at the start of the handshake. It's no big deal because the certificate hostname is already visible in the next handshake step.
For Tor, it's no big issue: it just manufactures a random hostname and presents it. Tor would have to do it (in the certificate) even without SNI. When using Tor, this does not compromise the domains requested by the browser, since they are sent directly to the exits within the triple-encrypted tunnel; only the chosen exits can see them.