[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #2340 [Applications/Tor Browser]: protect users against freeze, replay and version-rollback attacks (was: GPG signatures do not authenticate filenames)

#2340: protect users against freeze, replay  and version-rollback attacks
--------------------------------------+--------------------------
 Reporter:  rransom                   |          Owner:  tbb-team
     Type:  defect                    |         Status:  assigned
 Priority:  Very High                 |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-security              |  Actual Points:
Parent ID:  #3893                     |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------
Changes (by traumschule):

 * parent:   => #3893


Comment:

 pulling this up again (ranking 2nd among
 [https://trac.torproject.org/projects/tor/query?status=!closed&priority=Very+High
 Very High] priority, since how long? :)

 want to learn crypto a little later:
 - https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-
 repositories/
  - for example replay attack: a malicious actor performing a MitM against
 your machine has saved the metadata with the vulnerable version. The
 malicious actor replays that metadata to your system, preventing your
 system from seeing the newly patched libEXAMPLE. This gives the attacker
 up until the `Valid-Until` date to attempt to launch an attack against
 you.

 What I learned:
 - we know downloading executable files from a website is unsafe unless the
 authenticity is checked (by verifying the issuer of the TLS certificate),
 assuming the used encryption is not vulnerable to a
 [https://www.schneier.com/blog/archives/2015/03/freak_security_.html
 rollback attack] or the server has not been compromised in another way
 - to protect against this, files need to be signed with the release key
 which is kept offline (not anywhere near the production environment),
 trusting the signer's opsec
 - it is better to go "the debian way" (or [https://fedoramagazine.org
 /fedora-secures-package-delivery/ fedora's]
 [https://fedoraproject.org/wiki/Create_release_signing_key#fedora-release
 signing architecture]) by pooling all files in a trusted infrastructure
 (though this is not failprove, see link above)
 - package repositories should provide an sufficiently low expiration time
 (implemented for
 [http://deb.torproject.org/torproject.org/dists/sid/Release sid], good!),
 to protect against distribution of vulnerable older versions (fedora uses
 3 days)
 - signatures should always be created with
 [https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-
 Options.html --default-sig-expire] (esoteric warning!) to set a
 [https://tools.ietf.org/html/rfc4880#section-5.2.3.6 signature expiration
 time] - the date will be shown on verification,
 [http://deb.torproject.org/torproject.org/dists/sid/Release.gpg not
 implemented]:

 {{{
 curl http://deb.torproject.org/torproject.org/dists/sid/Release > Release
 curl http://deb.torproject.org/torproject.org/dists/sid/Release.gpg >
 Release.sig
 $ gpg --verify Release.sig
 gpg: assuming signed data in 'Release'
 gpg: Signature made Fri 10 Aug 2018 01:28:01 PM CEST
 gpg:                using RSA key 2265EB4CB2BF88D900AE8D1B74A941BA219EC810
 gpg: Good signature from "deb.torproject.org archive signing key"
 [unknown]
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the
 owner.
 Primary key fingerprint: A3C4 F0F9 79CA A22C DBA8  F512 EE8C BC9E 886D
 DD89
      Subkey fingerprint: 2265 EB4C B2BF 88D9 00AE  8D1B 74A9 41BA 219E
 C810
 $ gpg --list-packets Release.sig # just for reference
 # off=0 ctb=89 tag=2 hlen=3 plen=307
 :signature packet: algo 1, keyid 74A941BA219EC810
         version 4, created 1533900481, md5len 0, sigclass 0x00
         digest algo 8, begin of digest a8 9f
         hashed subpkt 33 len 21 (issuer fpr v4
 2265EB4CB2BF88D900AE8D1B74A941BA219EC810)
         hashed subpkt 2 len 4 (sig created 2018-08-10)
         subpkt 16 len 8 (issuer key ID 74A941BA219EC810)
         data: [2048 bits]
 }}}
 When a signature has an expiration date however it is shown at the end:
 {{{
 gpg: Signature expires Wed 14 Aug 2019 03:37:29 AM CEST
 $ en gpg --list-packets vanguards/TODO.txt.sig
 # off=0 ctb=89 tag=2 hlen=3 plen=441
 :signature packet: algo 1, keyid AA84FDED4E218633
         version 4, created 1534210649, md5len 0, sigclass 0x00
         digest algo 10, begin of digest 54 c3
         hashed subpkt 33 len 21 (issuer fpr v4
 D32C227073F822651EAD8F5DAA84FDED4E218633)
         hashed subpkt 2 len 4 (sig created 2018-08-14)
         critical hashed subpkt 3 len 4 (sig expires after 1y0d0h0m)
         subpkt 16 len 8 (issuer key ID AA84FDED4E218633)
         data: [3070 bits]
 }}}
 Question is what a user is supposed to do, when the signature has been
 expired.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2340#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs