Opened 7 years ago

Closed 6 years ago

#4583 closed defect (duplicate)

Obfuscate the default certificate validity times

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: needs-proposal tor-bridge
Cc: ioerror Actual Points:
Parent ID: #3972 Points:
Reviewer: Sponsor:

Description

Implement fuzzing of the certificate's 'notBefore' field, so that it's not so apparent that we are creating new certs every 2 hours.

Jake's code generated an 18-bits random number and substracted it from time(NULL). This approach fuzzes 'notBefore' for a maximum of 72 hours approx.

Do we like it? Should we increase it? Should we decrease it? Is there anything we should be careful with, when increasing/decreasing the fuzzing factor?

Since our new advertised MAX_SSL_LIFETIME is 1 year, I would incerase the fuzzing factor, even allowing our maximum fuzzing to be a month or so.

Child Tickets

Change History (10)

comment:1 Changed 7 years ago by asn

Status: newneeds_review

Check out my branch bug4583 at git://gitorious.org/mytor/mytor.git.

It even contains a changes file, in case you need it!

comment:2 Changed 7 years ago by nickm

Hm. The right fix here is to actually use the cert for a long time, not just to claim that we're using it for a long time. This fix doesn't help so much if we're going to keep rotating our initially presented CA certs so often.

Also, using "exactly 365*24*60*60 seconds" as our idea of the length of a year probably is more fingerprintable than rotating our certs too often. When actual CAs sell certs, I believe they don't do it like that. Some of them do stuff more along the times of timegm/gmtime manipulation -- some so that notBefore is at 00:00:00 GMT and notAfter is 23:59:59 GMT. We should probably see what openssl self-signed certs tend to have in this regard.

comment:3 in reply to:  2 Changed 7 years ago by asn

Summary: Implement certificate start time fuzzing (part of proposal 179)Obfuscate the default certificate validity times

Replying to nickm:

Hm. The right fix here is to actually use the cert for a long time, not just to claim that we're using it for a long time. This fix doesn't help so much if we're going to keep rotating our initially presented CA certs so often.

Makes sense.
(When we roll out user-defined certificates (CA-signed or not) we should probably start respecting their validity dates and stop trying to act smart with advertised and internal certificate validities.)

Also, using "exactly 365*24*60*60 seconds" as our idea of the length of a year probably is more fingerprintable than rotating our certs too often. When actual CAs sell certs, I believe they don't do it like that. Some of them do stuff more along the times of timegm/gmtime manipulation -- some so that notBefore is at 00:00:00 GMT and notAfter is 23:59:59 GMT.

Right.

We should probably see what openssl self-signed certs tend to have in this regard.

Hm, it seems like the default '-days' argument of req(1SSL) and x509(1SSL) is '30', for thirty days of duration.
I'm not sure how HTTPS server operators who use self-signed certificates generate them, and whether Apache provides them with a custom generation script with a custom certificate duration.

We probably need to dive into the SSL observatory and look for self-signed certificate durations.

comment:4 Changed 7 years ago by nickm

Milestone: Tor: unspecified

comment:5 Changed 7 years ago by nickm

Status: needs_reviewneeds_revision

comment:6 Changed 7 years ago by nickm

Keywords: needs-proposal added

comment:7 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:8 Changed 7 years ago by nickm

Component: Tor BridgeTor

comment:9 Changed 6 years ago by arma

I think this ticket now counts as a duplicate of #8443 (oops)

comment:10 Changed 6 years ago by arma

Resolution: duplicate
Status: needs_revisionclosed
Note: See TracTickets for help on using tickets.