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 over 1 year ago. Updated 3 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Installation
Target version:
Start date:
02/04/2018
Due date:
% Done:

0%

Feature Branch:
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

History

#1 Updated by anonym over 1 year ago

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

IMHO, let's do this ASAP.

#2 Updated by anonym over 1 year ago

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

#3 Updated by anonym over 1 year ago

#4 Updated by intrigeri over 1 year ago

#5 Updated by intrigeri over 1 year ago

  • Parent task set to #15281

#6 Updated by anonym over 1 year 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 over 1 year ago

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

#8 Updated by intrigeri over 1 year ago

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

#9 Updated by intrigeri over 1 year 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 about 1 year ago

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

#12 Updated by intrigeri about 1 year ago

#13 Updated by intrigeri about 1 year ago

  • Assignee changed from anonym to intrigeri

#14 Updated by intrigeri 11 months ago

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

#15 Updated by intrigeri 11 months ago

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

#16 Updated by intrigeri 10 months 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 10 months ago

#18 Updated by intrigeri 10 months ago

#19 Updated by intrigeri 8 months ago

  • Target version changed from Tails_3.13 to 2019

#20 Updated by intrigeri 7 months ago

#21 Updated by intrigeri 7 months ago

#22 Updated by intrigeri 6 months ago

  • Assignee deleted (intrigeri)

#23 Updated by anonym 3 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 3 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 3 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!

Also available in: Atom PDF