Project

General

Profile

Feature #15279

Feature #15281: Stack one single SquashFS diff when upgrading

Refresh Tails signing key before each upgrade check

Added by anonym almost 2 years ago. Updated 19 days ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Installation
Target version:
Start date:
02/04/2018
Due date:
% Done:

100%

Feature Branch:
feature/15281-single-squashfs-diff
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Upgrader

Description

That way the expiry of our keys will be much less problematic for users when Tails Upgrader looks for upgrades. So, before Tails Upgrader verifies any UDF, it's run something like:

curl https://tails.boun.org/tails-signing.key | \
    gpg --import-options merge-only --import

which should be safe thanks to merge-only.


Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision b0521813 (diff)
Added by intrigeri about 1 month ago

Export minimal signing key that the Upgrader will fetch (refs: #15279)

Revision afaf64e3 (diff)
Added by intrigeri about 1 month ago

Move the Upgrader's trusted keyring to tails-upgrade-frontend's $HOME and make it writable by that user (refs: #15279)

This will be needed in order to refresh our signing key before checking
for upgrades.

Revision 0c2ae4d6 (diff)
Added by intrigeri about 1 month ago

Fix minimal signing key that the Upgrader will fetch (refs: #15279)

The previous version was too minimal to be usable.

Revision cced26b6 (diff)
Added by intrigeri about 1 month ago

Upgrader: refresh the signing key before checking for available upgrades (refs: #15279)

Revision e5e98537
Added by segfault 19 days ago

Merge branch 'feature/15281-single-squashfs-diff' into stable (Closes: #15281, #15279, #15283, #15286)

History

#1 Updated by anonym almost 2 years ago

  • Tracker changed from Bug to Feature
  • Target version set to Tails_3.6

IMHO, let's do this ASAP.

#2 Updated by anonym almost 2 years ago

  • Subject changed from Refresh Tails signing key to Refresh Tails signing key before each upgrade check

#3 Updated by anonym almost 2 years ago

#4 Updated by intrigeri almost 2 years ago

#5 Updated by intrigeri almost 2 years ago

  • Parent task set to #15281

#6 Updated by anonym almost 2 years ago

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 almost 2 years ago

So... I wrote boun.org apparently... :)

#8 Updated by intrigeri almost 2 years ago

  • Target version changed from Tails_3.6 to Tails_3.7

#9 Updated by intrigeri almost 2 years ago

  • Target version changed from Tails_3.7 to Tails_3.8

#10 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_3.8 to Tails_3.10.1

#11 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_3.10.1 to Tails_3.11

#12 Updated by intrigeri over 1 year ago

#13 Updated by intrigeri over 1 year ago

  • Assignee changed from anonym to intrigeri

#14 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_3.11 to Tails_3.12

#15 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_3.12 to Tails_3.13

#16 Updated by intrigeri about 1 year ago

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.

#17 Updated by intrigeri about 1 year ago

#18 Updated by intrigeri about 1 year ago

#19 Updated by intrigeri 12 months ago

  • Target version changed from Tails_3.13 to 2019

#20 Updated by intrigeri 12 months ago

#21 Updated by intrigeri 12 months ago

#22 Updated by intrigeri 10 months ago

  • Assignee deleted (intrigeri)

#23 Updated by anonym 8 months ago

"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 7 months ago

Meta: I'll try hard not to dive into this topic too much before we actually start the work on #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 7 months ago

intrigeri wrote:

Meta: I'll try hard not to dive into this topic too much before we actually start the work on #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!

#26 Updated by intrigeri about 2 months ago

  • Target version changed from 2019 to Tails_4.2

#27 Updated by intrigeri about 2 months ago

  • Assignee set to intrigeri

#28 Updated by intrigeri about 2 months ago

  • Priority changed from Normal to High

#29 Updated by intrigeri about 1 month ago

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 about 1 month ago

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.

#31 Updated by intrigeri about 1 month ago

  • Status changed from Confirmed to In Progress

#32 Updated by intrigeri about 1 month ago

  • Feature Branch set to feature/15281-single-squashfs-diff

#33 Updated by intrigeri about 1 month ago

  • Status changed from In Progress to Needs Validation

#34 Updated by intrigeri about 1 month ago

  • Assignee changed from intrigeri to segfault

#35 Updated by segfault 19 days ago

  • Status changed from Needs Validation to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF