Hi, I think it would be good if tails_htp security would be further improved.
Anyone able to break SSL can tamper with the user's clock. This leads to at least two known problems. https://sourceforge.net/p/whonix/wiki/Security/#whonixs-secure-and-distributed-time-synchronization-mechanism (To be fair, I wrote that.) "If the clock is too much off, it's also easy for an adversary's webserver to detect "Oh, that's the Tor Browser user who's clock is X in past/future.", thus allowing the adversary to link all sessions to the same pseudonym. " Also quoting again: https://tails.boum.org/contribute/design/Time_syncing/ > If your bridge also can setup a SSL MitM attack against the HTP connections (e.g. the attacker also controls a SSL CA shipped by Debian), it can trick you into using this old consensus for max. one week, which is much worse. It is now possible to pin certificates in curl. Pin the SSL public key for real, not the much weaker method of pinning the certificate authority: https://sourceforge.net/p/whonix/wiki/Dev_sslcertpinning/ (It was possible before, but no one except the curl devs knew about.) Why not start pinning certificates? I can think of multiple paths depending on cooperation of the tails_htp remote servers. Idea 1 (least secure, least maintenance): At build time we download the SSL public certificates, verify they are valid using CA and hope at build time they were legit. Use the downloaded certificate for certificate pinning. Problem: SSL certificates expire. Idea 2: Ask the website owners if they can publish the gpg signed fingerprints of their SSL public keys. Problem: SSL certificates expire. Idea 3 (most secure, least maintenance, most one time work for website owners): They install a second self signed SSL certificate (for a part of their website) and and publish a gpg signed message with SSL public keys fingerprints. Cheers, adrelanos _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
