Update ciphers.inc to match ciphers from current Firefox

Firefox changed ciphersuits since we last updated ciphers.inc. We need to re-run get_mozilla_ciphers.py on the most recent stable Firefox and openssl, to generate a new ciphers.inc.

We should fix get_mozilla_ciphers if it needs it; the code may have rotted a bit.

changed milestone to %Tor: 0.3.0.x-final

added 027-triaged-1-out actualpoints::.2 component::core tor/tor milestone::Tor: 0.3.0.x-final nickm-deferred-20160905 owner::nickm points::2 priority::high resolution::implemented severity::normal status::closed tor-03-unspecified-201612 type::enhancement labels

Trac:
Milestone: N/A to Tor: 0.2.7.x-final

Marking triaged-out items from first round of 0.2.7 triage.

Trac:
Keywords: N/A deleted, 027-triaged-1-out added

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.???

Is anyone working on this? The little-t tor cipher suits presented are wildly different from a normal Firefox 38 ESR browser.

Trac:
Sponsor: N/A to N/A

Adding for consideration, tho it's very late in the process.

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.2.7.x-final

Hmmm. It looks like enough changes have been made in the identifiers that openssl uses between 1.0.0 and 1.0.1 and 1.0.2 and master that we should really reconsider for 0.2.8. I get different answers for every openssl version I try.

I've updated the script to work at all.

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.8.x-final
Priority: normal to major

Updates in branch 15426_027

Trac:
Severity: N/A to Normal

Throw most 0.2.8 "NEW" tickets into 0.2.9. I expect that many of them will subsequently get triaged out.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

This would be 'small' if my scripts worked on the latest ff and openssl. But I think there's some tweaking to do.

Trac:
Points: N/A to small/medium
Reviewer: N/A to N/A

Trac:
Priority: High to Medium

Trac:
Status: new to accepted
Owner: N/A to nickm

Trac:
Points: small/medium to 2

Defer some of my own tickets to 0.2.???

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???
Keywords: N/A deleted, nickm-deferred-20160905 added

This ticket makes me wish we had a network-team developer focused on the censorship side of things: is fixing our cipher suite the most important thing we could be doing to blend in better with browsing traffic these days? Heck, is matching Firefox's signature the thing we should be doing still, or is some other browser much more popular in key locations this decade?

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

This is now being used in places in England to block access to Tor. Can confirm Gatwick Airport uses this.

Modifying the header using for example Fiddler on Windows makes Tor network accessible again.

well then. how hard could it be?

Trac:
Priority: Medium to High
Milestone: Tor: unspecified to Tor: 0.3.0.x-final

Trac:
Username: jryans
Cc: N/A to jryans@gmail.com

This is now being used in places in England to block access to Tor. Can confirm Gatwick Airport uses this.

Modifying the header using for example Fiddler on Windows makes Tor network accessible again.

Airport using some DPI, that periodically (several days or weeks) get updates from vendor. You can't to make ciphersuites for Tor and Firefox to match for 100%, they using different libs, smart dpi vendor will use that difference for sure. So this ticket can't help you to bypass censorship in any real timeline.

If you want to play censorship box vs. plain Tor, then you need to make ciphersuites configurable by user, and still to be ready to get specific openssl's fpr.

That was easy enough -- see branch ciphers.inc for the client side.

For the server side, see branch server_ciphers. For that, there are a couple more ciphersuites to consider now. I've restored and re-run gen_server_ciphersuites to take those into account. For now, CCM is ranked below GCM and above CBC-SHA; Chacha is ranked below AES.

Trac:
Status: accepted to needs_review
Actualpoints: N/A to .2

I'm uncertain of how useful this actually is, and if we were going to match a browser's ciphersuites, matching chrome's would probably be "better" as it totally crushes firefox in terms of market share. That's probably a topic for a different discussion though.

The client branch looks ok from a "it matches Firefox" point of view, though if it were up to me, I'd move ChaCha around at runtime depending on if hardware AES is available or not.

Does OpenSSL do the right thing client side if TLS < 1.2 is negotiated, and the server picks an AEAD suite (RFC 7251 Sec. 3)?

The server branch likewise looks ok, though my comments regarding ChaCha prioritization also apply here. Nitpick: Update the MANDATORY list to remove the DES suite (Per: #19998 (moved)).

Created:

• #21338 (moved) for the switch-to-the-chrome ciphers thing.
• #21339 (moved) for the "use ChaCha when it's faster" thing.

Updated server_ciphers for the MANDATORY change and some indent fixes.

Discussed the openssl/TLS-1.2 thing on #tor-dev a little

Okay. Merging the now stuff (yawning says "deal with that stuff later" so IIUC I got review) and leaving the later stuff for later.

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

closed

changed time estimate to 16h

added 1h 36m of time spent

mentioned in issue #21338 (moved)

mentioned in issue #21339 (moved)

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

mentioned in issue tpo/core/tor#21338 (closed)

mentioned in issue tpo/core/tor#21339 (closed)