Opened 8 years ago

Closed 2 years ago

#3972 closed enhancement (wontfix)

Implement proposal 179: TLS certificate and handshake normalization

Reported by: ioerror Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: tor-relay
Cc: nickm, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Nick,

Here's my WIP for prop 179:
https://gitweb.torproject.org/ioerror/tor.git/commit/f3bb6846975193d9a6649c31f94bda47e4014070

I think removing the static cert stuff from the code and the proposal is probably a good idea.

Child Tickets

TicketTypeStatusOwnerSummary
#4548defectclosedImplement dynamic (rakshasa) primes (part of proposal 179)
#4549defectclosedImplement user-defined certificate strings through torrc (part of the proposal 179 efforts)
#4550enhancementclosedAllow bridge operators to specify their own link certificates (part of proposal 179)
#4570defectclosedImplement certificate serial number covert channel (part of proposal 179)
#4583defectclosedObfuscate the default certificate validity times
#4584defectclosedImplement a new certificate serial number strategy (part of proposal 179)
#8443defectclosedSSL handshake filtered when MAX_SSL_KEY_LIFETIME_ADVERTISED is 365 days

Change History (16)

comment:1 Changed 8 years ago by nickm

(For my reference, the brach name here is "tls-cert-work")

comment:2 Changed 8 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.3.x-final
Priority: minormajor
Summary: review some proposal-179 wip codeImplement proposal 179: TLS certificate and handshake normalization

comment:3 Changed 8 years ago by nickm

As previously discussed: s/rakshasa/something else/

As you mention above: let's NOT do the "internet widgets", Some-State, AU business. Those might be common values, but we've no evidence that they're common enough that a censor wouldn't block them.

all functions need docmentation

non-constant Identifiers start with a lower-case letter

Does DH_generate_parameters really require DH_check afterwards?

Why not use the default number of prime checks?

Can we store our DH prime to disk, so we don't need to regenerate it every time we start up?

2048-bit RSA, but 1024 bit DH? Why?

The start-time fuzzing makes me a little twitchy; we should document that magic 18.

When we _do_ generate a certificate chain, we should retain the ability to have the DN of the issuer of signed certificate match the DN of the identity cert.

We should see if we can do what we _really_ want here, and present cert A during the initial handshake, then present cert B and cert C during the renegotiation, where A can be anything with the right key.

comment:4 Changed 8 years ago by ioerror

I'll call it a dynamic prime.

I plan to remove the static cert stuff, though I suspect it might be useful to have some common defaults to ease configuration, I agree that we lack evidence to decide that it won't just end up as some kind of obvious network distinguisher.

When other servers do 2048-bit RSA - what size DH does say, Apache do for cipher modes that we use?

comment:5 Changed 8 years ago by ioerror

Nick - If you read this report ( https://www.ssllabs.com/ssldb/analyze.html?d=www%2etorproject%2eorg&s=38%2e229%2e70%2e46 ) - I see that our website uses a 2048-bit RSA key and the DH is 1024-bit. Eg: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128)

What happens if we crank up the DH parameter to be dynamic and 2048-bits? Seems like we'll perhaps stick out, eh?

comment:6 in reply to:  5 Changed 7 years ago by asn

Replying to ioerror:

Nick - If you read this report ( https://www.ssllabs.com/ssldb/analyze.html?d=www%2etorproject%2eorg&s=38%2e229%2e70%2e46 ) - I see that our website uses a 2048-bit RSA key and the DH is 1024-bit. Eg: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128)

What happens if we crank up the DH parameter to be dynamic and 2048-bits? Seems like we'll perhaps stick out, eh?

Hmm, that ssllabs.com report is a bit weird (What is p, g and Ys supposed to be? If g is the generator, is the generator supposed to be 1? Or is it one bit?).

BTW, in DHE TLS ciphersuites the server supplies the DHE parameters through a ServerKeyExchange message and the client is supposed to accept them. The keylength is not known by the client before the handshake.

Looking at the OpenSSL code, the generated DH modulus in DHE mode seems to always be 1024 bits (or 512 if export40 restrictions apply). I guess that makes 1024 bits a more sensible choice wrt fingerprinting.

In ssl3_send_server_key_exchange():

                        if ((dhp == NULL) && (s->cert->dh_tmp_cb != NULL))
                                dhp=s->cert->dh_tmp_cb(s,
                                      SSL_C_IS_EXPORT(s->s3->tmp.new_cipher),
                                      SSL_C_EXPORT_PKEYLENGTH(s->s3->tmp.new_cipher));

and

#define SSL_C_EXPORT_PKEYLENGTH(c)  SSL_EXPORT_PKEYLENGTH((c)->algo_strength)
#define SSL_EXPORT_PKEYLENGTH(a) (SSL_IS_EXPORT40(a) ? 512 : 1024)

(Note that the DH keys generated in DHE mode are only used for a single session and then they are thrown away; hence their small size is not terribly alarming.)

comment:7 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Remaining parts of this need to go in 0.2.4.x after analysis.

comment:8 Changed 7 years ago by nickm

Type: defectenhancement

comment:9 Changed 7 years ago by nickm

Keywords: needs_review removed
Status: newneeds_review

comment:10 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:11 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:12 Changed 6 years ago by nickm

Status: needs_reviewneeds_revision

Remaining pieces are needs_revision; putting this there too.

comment:13 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:14 Changed 5 years ago by nickm

Cc: nickm arma added; nickm arma removed
Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

Moving nearly all needs_revision tickets into 0.2.6, as now untimely for 0.2.5.

comment:15 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: unspecified

comment:16 Changed 2 years ago by nickm

Resolution: wontfix
Severity: Normal
Status: needs_revisionclosed

The remainder of this ticket is superseded by the existence of PTs.

Note: See TracTickets for help on using tickets.