Opened 11 years ago

Last modified 7 years ago

#854 closed enhancement (Fixed)

Reducing an overload if certificates changed.

Reported by: rovv Owned by: nickm
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.1.6-alpha
Severity: Keywords:
Cc: rovv, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

  1. Tor (caches) should not delete the old certificates as soon as a new received. In the current version the difference between the time of publications are usually more than 48 hours, except a rare cases.
  1. Client must request a certificates by signing key digest not identity, if a digest (from consensus) known and client wish to obtain it exactly. (If this does not entail additional risks)
  1. Client can trust a signature, for some a short period after certificate expired. This will reduce the risk of failure if the resulting consensus signed multiple keys, certificates that expired at the same time. Perhaps, authority directory also could continue this time to sign the consensus look for warning the owner.
  1. ...(your suggestion)

...

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (8)

comment:1 Changed 11 years ago by rovv

For the first two items an example of fixes presented,
please consider them only as an illustration to the suggestions:

--- routerlist.c Sat Nov 8 06:32:00 2008
+++ routerlist.test.c Sat Nov 8 11:55:50 2008
@@ -282,6 +282,7 @@

if (!trusted_dir_certs)

return;


+ time_t now = time(NULL);

DIGESTMAP_FOREACH(trusted_dir_certs, key, cert_list_t *, cl) {

authority_cert_t *newest = NULL;
SMARTLIST_FOREACH(cl->certs, authority_cert_t *, cert,

@@ -289,8 +290,13 @@

newest->cache_info.published_on))

newest = cert);

SMARTLIST_FOREACH(cl->certs, authority_cert_t *, cert,

  • if (newest && (newest->cache_info.published_on >
  • cert->cache_info.published_on + OLD_CERT_LIFETIME)) {

+ if (newest &&
+ /* a live certs storing if they are not over the most recent more than 48h */
+ (((newest->cache_info.published_on > cert->cache_info.published_on +

+ OLD_CERT_LIFETIME) && !ftime_definitely_after(now, cert->expires))

+ /* a non-live certificates storing only for 48h after published most recent */
+ ((newest != cert) && ftime_definitely_after(now, cert->expires) &&
+ (newest->cache_info.published_on < now - OLD_CERT_LIFETIME)))) {

SMARTLIST_DEL_CURRENT(cl->certs, cert);
authority_cert_free(cert);
trusted_dir_servers_certs_changed = 1;

@@ -418,8 +424,10 @@

pending = digestmap_new();
missing_digests = smartlist_create();

-

  • list_pending_downloads(pending, DIR_PURPOSE_FETCH_CERTIFICATE, "fp/");

+ if (status)
+ list_pending_downloads(pending, DIR_PURPOSE_FETCH_CERTIFICATE, "sk/");
+ else
+ list_pending_downloads(pending, DIR_PURPOSE_FETCH_CERTIFICATE, "fp/");

if (status) {

SMARTLIST_FOREACH(status->voters, networkstatus_voter_info_t *, voter,

{

@@ -443,10 +451,10 @@

log_notice(LD_DIR, "We're missing a certificate from authority "

"with signing key %s: launching request.",
hex_str(voter->signing_key_digest, DIGEST_LEN));

  • smartlist_add(missing_digests, voter->identity_digest);

+ smartlist_add(missing_digests, voter->signing_key_digest); /* only cert with sk needs, not any with fp */

}

});

  • }

+ } else {

SMARTLIST_FOREACH(trusted_dir_servers, trusted_dir_server_t *, ds,

{

int found = 0;

@@ -473,12 +481,15 @@

smartlist_add(missing_digests, ds->v3_identity_digest);

}

});

-
+ }

if (!smartlist_len(missing_digests)) {

goto done;

} else {

smartlist_t *fps = smartlist_create();

  • smartlist_add(fps, tor_strdup("fp/"));

+ if (status)
+ smartlist_add(fps, tor_strdup("sk/"));
+ else
+ smartlist_add(fps, tor_strdup("fp/"));

SMARTLIST_FOREACH(missing_digests, const char *, d, {

char *fp;
if (digestmap_get(pending, d))

comment:2 Changed 11 years ago by rovv

We can't ask a certificate by digest of signing key,
if there is an attacker capable to poison a cache of forming
the certificate for this (sk) key signed by special chosen
identity key. (If this is possible) Calling of
authority_cert_get_by_sk_digest() will always give a somebody else's
certificate. Client in that logic will be asking for something
which never be return, until the exhaustion of limits on the requests.
So client can to obtain the exactly required certificate only
if asked it by fingerprint of identity key.
(in the current opportunities of caches and clients)

comment:3 Changed 11 years ago by nickm

Implemented fix for part 1 in r17247.

For part 2, we have two options:

(a) We can add a new "download by fp _and_ sk" option that requires both to match.
(b) We can add a cross-certification element to certificates (that is, a signature of the identity key using the

signing key) so that you can't include a signing key in a cert without knowing its private key.

Either of these would have some compatibility issues, so we couldn't deploy the full version of either right away.
The migration path for (a) would be, "add a download-by-fp-and-sk URL. Once enough servers support it, have clients
use it (on servers that support it) when they want to download by sk." For (b), the migration path would be "add the
field to certificates. Have clients verify it where present. Make all authorities regenerate their certificates to
use the new cross-cert feature. Once all have done so, make clients and servers reject certificates without cross-
certification. Then we can download by sk."

comment:4 Changed 11 years ago by rovv

The first (a) option, the quickest way, in a change both dir_spec and code.

The second (b) option, makes Tor more secure in terms of pure science.
But will require significant changes and perhaps a longer period
of implementation. And perhaps once in the far future will be necessary.
However, no special gains that will be bring for today, because Tor
does not use the sk in isolation from fp while determining
the authenticity of certificates.

comment:5 Changed 11 years ago by nickm

So issue 1 is fixed; for issue 2, I've written a proposal (prop 157) that encompasses a) and b) above.

For issue 3, I think I'm going to argue for "no". If we say a certificate is still valid to use
for (say) 7 days after it has expired, all we have really done is redefined "valid-until " to mean
"valid-until-7-days-after".

Perhaps it would be better to make clients (or just caches?) start warning a few days _before_ the
certificate expires. Right now, the authority itself warns, but that seems not to always be good enough.

comment:6 Changed 11 years ago by nickm

I believe all the issues here are either fixed, or wontfix, or in proposal 157. Closing the bug.

comment:7 Changed 11 years ago by nickm

flyspray2trac: bug closed.

comment:8 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.