Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 11/28/2015 2:26 PM, nusenu wrote:
> The important info for me here is: How is "about to expire"
> defined? x days before expiry or

I think 24 hours before expiry.

> 80% of its lifetime is over?

No.

> Can it be configured?

No. This would not be helpful - complicating the already complicated
code for this feature which wouldn't solve/fix or make anything
better/easier.

> yes that is correct. So for the workaround of the workaround I
> will simply invoke tor twice. First time without --keygen for key
> generation, then with --keygen for signing key renewal.
> 
> thanks for the quick reply.

Hey, welcome :)
That sounds good to me.
Yeah, we  built it with a logic that will work for all types of
operators, people with less experience with Tor and can easily make
mistakes, misconfigurations, etc. Advanced users like you who code
scripts can always find workarounds.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWWaK1AAoJEIN/pSyBJlsRF04IANfxG9/i+WbAVt2HwY5yOWb5
SwCYQvyMHWrUBFC8MexdOQZnKZ9NLfngJ4O5yO+4+BTDFSNy1FZilkjN3MY1Uaix
ZIG9hmFiZMRpEks7LJWtL1SvQF5bE/H4UlyEsrPmNjE3m+mZqPB1XfRj4f0/dXFE
pFrHIV3YCHBgezpN7ZxMiyQZZGpTXmOh+ee0MLJ51NvHzZwYFCrAiIEbMYJdnuQ4
as4WEzT9frX1N9Tmq0Tkg9BmeROvyeUsFfuKvgh+g2AeaNHgI8HJUWbM86IFDKSd
Gs+OpkL9ot+3ecZ//PdlfBzSobkyZ4gwh53CrPNLgyptXwGoU2T4HWd0hWb9L8g=
=ncc0
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] tor ignores --SigningKeyLifetime when keys exist

[nusenu]

(thread split from [1])

s7r wrote:
> - - when you run tor --orport [...] just to generate the keys in a
> non-interactive way, include a PublishServerDescriptor 0 in the
> command as well, send the log to /dev/null and terminate the process
> immediately. The descriptor will have to be published by the Tor
> process actually running the relay. If the master id private key is
> not encrypted, --keygen should be able to renew the medium term
> signing key in a non-interactive way. But it's not a big deal if you
> decide to do it with tor --orport [...] if it's easier for you this way.

Turns out my workaround to generate keys without a passphrase
non-interactively is not working entirely in every case since tor
apparently ignores --SigningKeyLifetime (when used without --keygen)
when keys exist: Signing keys are not (re)generated according to the
(new) SigningKeyLifetime parameter (signing key/cert remains unchanged).

reproducer:
mkdir tdata
tor --PublishServerDescriptor 0 --orport 1234 --datadirectory tdata
--list-fingerprint --quiet

(new signing key with default expiry created)

attempt to change (reduce) expiry:
tor --PublishServerDescriptor 0 --orport 1234 --datadirectory tdata
--SigningKeyLifetime "1 week" --list-fingerprint --quiet

expected result: key lifetime is reduced to 7 days
actual result: key lifetime is not changed (remains at 1 month)

(invoking tor with --keygen causes the expected lifetime but can not be
run non-interactively if keys do not exist)

So I reopened [2].



[1] https://lists.torproject.org/pipermail/tor-dev/2015-November/009959.html
[2] https://trac.torproject.org/projects/tor/ticket/17127
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 11/28/2015 1:48 PM, nusenu wrote:
> (thread split from [1])
> 
> reproducer: mkdir tdata tor --PublishServerDescriptor 0 --orport
> 1234 --datadirectory tdata --list-fingerprint --quiet
> 
> (new signing key with default expiry created)
> 
> attempt to change (reduce) expiry: tor --PublishServerDescriptor 0
> --orport 1234 --datadirectory tdata --SigningKeyLifetime "1 week"
> --list-fingerprint --quiet
> 
> expected result: key lifetime is reduced to 7 days actual result:
> key lifetime is not changed (remains at 1 month)
> 
> (invoking tor with --keygen causes the expected lifetime but can
> not be run non-interactively if keys do not exist)
> 
> So I reopened [2].
> 
> 
> 
> [1]
> https://lists.torproject.org/pipermail/tor-dev/2015-November/009959.html
>
> 
[2] https://trac.torproject.org/projects/tor/ticket/17127

I think [2] is the wrong link? There's nothing about this in there.

I think this is expected and correct behavior.

If medium term signing key exists, and is sufficiently valid in the
future for Tor, it won't try to automatically renew them.
It will use the new SigningKeyLifetime value for the NEW keys, once
the ones it already has are _about_ to expire and Tor _wants_ to
generate new medium term signing key.

If you already have medium term signing key valid 30 days in the
future you can't replace it using the automated key generator in Tor
(no manual --keygen).

I think it should stay like this. If you want to change the lifetime
of the medium term signing key with --orport, do a rm -rf
ed25519_signing_* before that command.

P.S. also if they master id key is not encrypted you can use --keygen
in a non-interactive way afaik.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWWZefAAoJEIN/pSyBJlsR3MkH/2NsRc9Ua22Mx4xDzvEJIU9C
yNXgtabAD3w/UMHdgCC6q9dW2z7r+w97cPQ6ZBEZ34a98SPaM1HtUhvHG6/tM5wh
M3vtWs+WdF72QNwfDKsXfbgg4HNdvKczsttuuIHMXEOhLk9+2ehKMqGw+WPn1Fst
QNjN3Cup225m2wRc+n0EBaMUefQXhCfx6qQPnyjTi9wnCjNIpfhTRp3zzslObIcZ
cteJaBP+nkxsoS81XA3M2M6HSCUdNeEq+IVjt7WgciOD4USfeJlEmijIldYbAGwW
JFXihEsO6cIoaX3fOusjj7XIV5XaxeyfMFMC5g7Rnw3ueGYuCik82GP4UM+IXF8=
=Yzi1
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist

[nusenu]

> I think [2] is the wrong link? There's nothing about this in there.

thanks for pointing that out, correct URL:
https://trac.torproject.org/projects/tor/ticket/17603


> I think this is expected and correct behavior.
> 
> If medium term signing key exists, and is sufficiently valid in the
> future for Tor, it won't try to automatically renew them.
> It will use the new SigningKeyLifetime value for the NEW keys, once
> the ones it already has are _about_ to expire and Tor _wants_ to
> generate new medium term signing key.

The important info for me here is: How is "about to expire" defined?
x days before expiry or
80% of its lifetime is over?
Can it be configured?


> If you already have medium term signing key valid 30 days in the
> future you can't replace it using the automated key generator in Tor
> (no manual --keygen).
> 
> I think it should stay like this. If you want to change the lifetime
> of the medium term signing key with --orport, do a rm -rf
> ed25519_signing_* before that command.
> 
> P.S. also if they master id key is not encrypted you can use --keygen
> in a non-interactive way afaik.

yes that is correct. So for the workaround of the workaround I will
simply invoke tor twice.
First time without --keygen for key generation,
then with --keygen for signing key renewal.

thanks for the quick reply.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor ignores --SigningKeyLifetime when keys exist

[nusenu]

s7r:
> On 11/28/2015 2:26 PM, nusenu wrote:
>> > The important info for me here is: How is "about to expire"
>> > defined? x days before expiry or
> I think 24 hours before expiry.


After trying this in practice I can confirm that tor renewed the signing
key after it entered a timewindow not bigger than 24 hours before key
expiry (not before).



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] documentation for new offline master key functionality (--keygen is undocumented)

[nusenu]

> I have actually tried this in practice to see what happens.
> 
> If you replace the ed25519 medium term singing key and certificate in
> $datadirectory/keys, Tor will re-read keys from disk even if you don't
> send a SIGHUP when it outputs:
> 
> [notice] It looks like I should try to generate and sign a new
> medium-term signing key, because the one I have is going to expire
> soon. To do that, I'm going to have to try to load the permanent
> master identity key.

If that logentry is generated on a system with 'OfflineMasterKey 1' I
would find it a bit misleading since it will never be able to load the
permanent master key.

> This message is repeated once every 30 seconds or so. When you send a
> SIGHUP, the reload happens instantly.
> 
> So, if an user correctly generates and provides the new medium term
> signing key and certificate and forgets to SIGHUP (reload), when the
> old key expires Tor won't exit. This is good.

Thanks for this info, so we don't have to do anything else than just
replace the key files (no explicit SIGHUP needed) - and tor will read it
when necessary. That is great since it makes key renewal idempotent out
of the box.

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] does renewing ed25519 signing key hurt if done to often?

[nusenu]

the 'problem' solved itself
(tor does not need HUP when it's keyfile changed)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] tor weather warning tor ops about expiring signing keys?

[nusenu]

Hi,

I'm wondering if a service like a future tor weather could have an
additional check to warn relay ops about key expiry:
(something like "Email me when the router's signing key is about to
expire")

Do relays disclose the fact that they are run via OfflineMasterKey 1?
Do dir auths/tor clients see when a currently used signing key is about
to expire?

thanks
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Summary of meek's costs, October 2015

[David Fifield]

On Fri, Nov 20, 2015 at 05:50:51PM -0600, Tom Ritter wrote:
> On 18 November 2015 at 16:32, David Fifield  wrote:
> > There was an unfortunate outage of meek-amazon (not the result of
> > censorship, just operations failure). Between 30 September and 9 October
> > the bridge had an expired HTTPS certificate.
> > [tor-talk] Outage of meek-amazon
> > 
> > https://lists.torproject.org/pipermail/tor-talk/2015-October/039231.html
> > 
> > https://lists.torproject.org/pipermail/tor-talk/2015-October/039234.html
> > And then, as a side effect of installing a new certificate, the bridge's
> > fingerprint changed, which caused Tor Browser to refuse to connect. It
> > used to be that we didn't include fingerprints for the meek bridges, but
> > now we do, so we didn't anticipate this error and didn't notice it
> > quickly.
> > Update the meek-amazon fingerprint to 
> > B9E7141C594AF25699E0079C1F0146F409495296
> > https://trac.torproject.org/projects/tor/ticket/17473
> > [tor-talk] Changed fingerprint for meek-amazon bridge (attn support)
> > 
> > https://lists.torproject.org/pipermail/tor-talk/2015-November/039397.html
> > Interestingly, the meek-amazon bridge still had about 400 simultaneous
> > users (not as much as normal) during the time when the fingerprint
> > didn't match. I would have expected it to go almost to zero. Maybe it's
> > people using an old version of Tor Browser (from before March 2015) or
> > some non–Tor Browser installation.
> 
> It seems like it would be better to use the SPKI rather than the cert
> fingerprint, this would allow you to reissue the same key and keep
> things working for older clients.

The fingerprint I'm talking about is the relay fingerprint, not the
HTTPS/X.509 one. The HTTPS certificate and the relay identity
fingerprint are completely independent. It just happened that in this
case, the relay was so configured, that when it rebooted to start using
the new HTTPS cert, it also generated a new identity key.

We're not pinning the HTTPS cert and in fact we can't; it's just used
for confidentiality on the CDN↔meek-server link.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev