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
