Tails

#6 Updated by anonym 2018-02-10 17:38:47

WTF, wget?

$ wget --debug -O- https://tails.boun.org/tails-signing.key
Setting --output-document (outputdocument) to -
DEBUG output created by Wget 1.18 on linux-gnu.

Reading HSTS entries from /home/amnesia/.wget-hsts
URI encoding = ‘UTF-8’
--2018-02-10 17:29:44--  https://tails.boun.org/tails-signing.key
Certificates loaded: 166
Resolving tails.boun.org (tails.boun.org)... 69.172.201.153
Caching tails.boun.org => 69.172.201.153
Connecting to tails.boun.org (tails.boun.org)|69.172.201.153|:443... 1518283788 ERROR torsocks[14480]: Connection refused to Tor SOCKS (in socks5_recv_connect_reply() at socks5.c:549)
Closed fd 3
failed: Connection refused.
Releasing 0x00005bc92043c760 (new refcount 1).

You too, curl?

$ curl -v --proxy socks5h://127.0.0.1:9150 https://tails.boun.org/tails-signing.key
*   Trying 127.0.0.1...
* TCP_NODELAY set
* SOCKS5 communication to tails.boun.org:443
* SOCKS5 request granted.
* Connected to (nil) (127.0.0.1) port 9150 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to tails.boun.org:443 
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to tails.boun.org:443

I tried several other HTTPs (incl. HSTS) sites without problem both for wget and curl. Hm…

#7 Updated by anonym 2018-02-10 18:33:35

So… I wrote boun.org apparently… :)

#16 Updated by intrigeri 2018-11-08 08:21:02

One possibly slightly nicer option (once our signing key has a UID tails.boum.org) would be to use WKD:https://wiki.gnupg.org/WKD.

#23 Updated by anonym 2019-06-13 11:33:11

“Always” doing such a fetch increases the fingerprint of Tails’ initial network signature, and it is over a megabyte of data that would be fetched unnecessarily in the vast majority of cases. We could avoid that by either:

1. modify tails-iuk so it fetches the key if the UDP signature verification fails and then try again
2. make the wrapper check if the key in the keyring is expired and fetch if so

Let’s first note that “always” fetching has a nice security property both of these approaches looses out on: if we revoke our signing key, “always” fetching means it will be immediately picked up by users.

If we compare 1 vs 2:

• In 1 it will be a bit awkward to get the freshly fetched key into the amnesia user’s keyring due to the user separation. In 2 this is trivial.
• In 2 we only check if our current key is expired and fetch if so, but 1 would fetch it on any failure, possibly covering a few other cases.
• 2 requires perl, so probably intrigeri should implement it then.

I still think 2 is good enough (and simpler!), and would be happy to implement it. But I’m unsure whether we want to loose out on the revocation always being detected. That actually sounds pretty nice, especially since users are unlikely to update the key themselves.

@intrigeri, I’d like your take on this one.

#24 Updated by intrigeri 2019-06-15 09:44:42

Meta: I’ll try hard not to dive into this topic too much before we actually start the work on Feature #15281 and friends, because too many WIP things at the same time makes my life more painful than it could be. ⇒ just throwing in another idea.

> We could avoid that by either:

> 1. modify tails-iuk so it fetches the key if the UDP signature verification fails and then try again
> 2. make the wrapper check if the key in the keyring is expired and fetch if so

Or 3. publish another, “light” version of tails-signing.key, that only has the bits we need here. That is, the public key material without extra signatures that we don’t need. This would solve the “fetching too much data, most of the time unnecessarily” problem while still allowing subkeys revocation certificates to be retrieved. The only problem I see with this is: we need to think about updating that key every time we update tails-signing.key. We could add a CI job (Jenkins or GitLab CI, whatever) that verifies that these two exported keys are “sufficiently in sync” (to be defined), either pro-actively or if we ever notice we’re not good at remembering we should do that.

#25 Updated by anonym 2019-06-26 09:29:54

intrigeri wrote:
> Meta: I’ll try hard not to dive into this topic too much before we actually start the work on Feature #15281 and friends, because too many WIP things at the same time makes my life more painful than it could be. ⇒ just throwing in another idea.

Understood!

> Or 3. publish another, “light” version of tails-signing.key

I also considered that…

> The only problem I see with this is: we need to think about updating that key every time we update tails-signing.key.

… but shelved the idea because of this issue, but…

> We could add a CI job (Jenkins or GitLab CI, whatever) that verifies that these two exported keys are “sufficiently in sync” (to be defined), either pro-actively or if we ever notice we’re not good at remembering we should do that.

… this saves the day! Great!

#29 Updated by intrigeri 2019-12-18 20:19:21

Let’s try to define “sufficiently in sync”. Say F (full) is the tails-signing.key we’re already publishing, and L (light) is the new, lighter version we want here. How about we start with this:

• The expiration date of the master key in F is the same as the expiration date of the master key in L.
• For every non-expired subkey that F includes: it’s also present in L, with the same expiration date.

Good enough?

#30 Updated by intrigeri 2019-12-22 21:08:46

I think I have a better idea: refresh the aforementioned “light” version of the key at release time. IMO:

• It’s good enough in terms of keeping that key fresh, because we’re doing pretty good at updating our signing key and subkeys ahead of time to support upgrading older Tails (which is the point here).
• It’s way cheaper to implement than the CI check proposed earlier here.
• From the RM’s perspective, I imagine it’ll look like one more command in a block of shell commands they would anyway copy’n’paste, so it should be essentially free for the RM.