Implement restored semantics of TLS ClientHello

changed milestone to %Tor: 0.2.4.x-final

added SponsorZ component::core tor/tor milestone::Tor: 0.2.4.x-final priority::medium resolution::implemented status::closed tor-relay type::project labels

Trac:
Keywords: SponsorZ deleted, SponsorZ tor-relay added
Milestone: N/A to Tor: 0.2.4.x-final

Trac:
Cc: andrea, nickm to andrea, nickm, mikeperry

Wow, that was easy so far. See branch tls_echde in my public repository. I've tested it on a mixed network with some 0.2.2 clients. Still need to test with v2 servers. Looks like a promising start though.

Trac:
Status: new to needs_review

If agl's numbers are right, P224 would be much faster than P256, and secure enough for us. But before we get too deep there, we need to check what (if anything) our choice of curve will do to fingerprintability here, or whether our choice of ECDHE ciphers at all will make us fingerprintable. In the latter case, maybe bridges should disable them by default when not using a pluggable transport.

Talked with arma ; he thinks "just go with p224" might be a good idea.

We need to make sure that when we do this, we tell everybody with a 64-bit system to make sure their openssl is 1.0.1, built with "enable-ec_nistp_64_gcc_128" -- that's where the big performance boost is.

(FWIW, the enable-ec_nistp_64_gcc_128 option seems to make P224 about 2x faster and P256 about 1.6X faster.)

I think this all looks okay to merge to me; you should explain to me how all this clients lying about ciphers to avoid fingerprinting business works to me someday, though, I think.

Okay, I rebased into tls_ecdhe_rebased, add a few more commits (cleanups, p244, configurable group, detect missing enable-ec_nistp_64_gcc_128), squashed again into tls_ecdhe_rebased_v2.

Joyeux Noël. Merged onto master.

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

closed

moved to tpo/core/tor#7200 (closed)

Implement restored semantics of TLS ClientHello

Child items ...

Activity