Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we keep both -+- Reporter: arma | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: 026-triaged-1, nickm-patch, andrea- Actual Points: | review Points: | Parent ID: -+- Comment (by nickm): Okay, will target for 0.2.6.4-??? or 0.2.7.1-alpha, since 0.2.6.3-alpha comes out today. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:10 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we keep both -+- Reporter: arma | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: 026-triaged-1, nickm-patch, andrea- Actual Points: | review Points: | Parent ID: -+- Comment (by andrea): This branch looks good to me; merge away. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:9 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we keep both -+- Reporter: arma | Owner: Type: defect | Status: closed Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: 026-triaged-1, nickm-patch, andrea- implemented| review Actual Points: | Parent ID: Points: | -+- Changes (by nickm): * status: needs_review = closed * resolution: = implemented Comment: Merged to master. w -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:11 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we
keep
both
+
Reporter: arma| Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.6.x-final
Component: Tor |Version:
Resolution: | Keywords: 026-triaged-1, nickm-patch
Actual Points: | Parent ID:
Points: |
+
Comment (by sysrqb):
Relatively quick review. The rewrite seems to solve this and #11457.
Thoughts:
- if the first cert in the list is very expired and all subsequent certs
are from the future, we don't remove it until we reach the future.
- I think similar scenario to #11457, where one cert is created then soon
after another is created, after two days all tors will discard the
original cert. if the authority then starts reusing the original, everyone
will re-request it every hour? This is much less bad than #11457, but it's
a side-effect of discarding unexpired, superseded certs.
- should we remember the signing key digest of the certs we download, and
not discard superseded certs which we redownload often?
- I wonder what other weird edge cases exist.
Minor consmetic changes
{{{
diff --git a/src/or/routerlist.c b/src/or/routerlist.c
index 7112282..83d1c69 100644
--- a/src/or/routerlist.c
+++ b/src/or/routerlist.c
@@ -498,7 +498,7 @@ trusted_dirs_remove_old_certs(void)
* Remove it. */
should_remove = 1;
} else if (next_cert_published + SUPERSEDED_CERT_LIFETIME now) {
-/* Certificate has been superseded for OLD_CERT_LIFETIME.
+/* Certificate has been superseded for SUPERSEDED_CERT_LIFETIME.
* Remove it.
*/
should_remove = 1;
@@ -512,7 +512,7 @@ trusted_dirs_remove_old_certs(void)
} DIGESTMAP_FOREACH_END;
#undef DEAD_CERT_LIFETIME
-#undef OLD_CERT_LIFETIME
+#undef SUPERSEDED_CERT_LIFETIME
trusted_dirs_flush_certs_to_disk();
}
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:7
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we keep both + Reporter: arma| Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: 026-triaged-1 Actual Points: | Parent ID: Points: | + Changes (by nickm): * status: new = needs_review Comment: See branch bug11454_11457 for a rewrite of the cert expiration code. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we keep both + Reporter: arma| Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: 026-triaged-1 Actual Points: | Parent ID: Points: | + Comment (by nickm): See 8157b8b7 and #854 for information on how this logic first appeared. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we keep both + Reporter: arma| Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: 026-triaged-1 Actual Points: | Parent ID: Points: | + Changes (by nickm): * keywords: = 026-triaged-1 Comment: I think what we want here is for the logic to be discard superseded certificates if any certificate newer than them has existed for at least X days? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we
keep
both
+
Reporter: arma| Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.6.x-final
Component: Tor |Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
+
Comment (by arma):
I think maybe this line wanted to be
{{{
-(cert_published + OLD_CERT_LIFETIME newest_published)) {
+(newest_published + OLD_CERT_LIFETIME now)) {
}}}
so we wait 7 days before deleting any unexpired certs, in case we see them
again (and earlier in the function we ensure that we never delete the
newest cert for a given authority).
Does that sound plausible?
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:1
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we keep both + Reporter: arma| Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | + Comment (by arma): (I found the bug by setting up a test network and then updating a signing key and then moving my date forward a month. So it is a confirmed real bug.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #11454 [Tor]: If two auth certs are both old but were generated nearby in time, we keep both
#11454: If two auth certs are both old but were generated nearby in time, we
keep
both
+
Reporter: arma| Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.6.x-final
Component: Tor |Version:
Keywords: | Actual Points:
Parent ID: | Points:
+
In trusted_dirs_remove_old_certs() we check if
{{{
(cert_published + OLD_CERT_LIFETIME newest_published)) {
}}}
when deciding whether to discard an old cert from our cache.
We don't check it at all with respect to current time.
So if an authority generates a signing key in January, and then generates
ten more signing keys within a week, and now it's April, we'll still keep
all of them until they expire or until a new signing key shows up that's
more than 7 days newer than them.
This cannot be the right logic.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11454
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
