Re: [Tails-dev] tails_htp SSL fingerprint pinning

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: adrelanos
CC: The Tails public development discussion list
Subject: Re: [Tails-dev] tails_htp SSL fingerprint pinning
Hi,

adrelanos wrote (27 Sep 2012 15:14:14 GMT) :
> I think it would be good if tails_htp security would be
> further improved.


I agree.

> Why not start pinning certificates?


Probably because nobody designed and implemented a working solution
yet. Looks like you started to. I'm glad you did, and I do hope you
bring this project to completion!

> 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.


Looks relatively easy.

> Problem: SSL certificates expire.


Ignoring hosts whose certificate expires within N weeks (N chosen
depending on the Tails release schedule, as far as I'm concerned).

Another problem: some hosts (e.g. Google) use tricks such as anycast
and multiple SSL certificates. These would have to be detected and
replaced within our pools.

This "let's get a static list of pinned host/certificate pairs"
problem is quite more generic than Tails' htpdate, so I guess it could
be dealt with as an independent project. I'm happy if someone
tackles it.

> Idea 2:
> Ask the website owners if they can publish the gpg signed fingerprints
> of their SSL public keys. Problem: SSL certificates expire.


This looks like a job for Monkeysphere [1] so it's not hard to get me
excited on it, but in practice, I doubt server administrators others
than those in our "pal" pool will do any such thing. I still very much
like our pal / foe / neutral pools design, so I'm not a fan of any
solution that requires cooperation from web server administrators.

[1] http://web.monkeysphere.info/

> 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.


The goal of escaping the SSL cartel is an important one, but I'm not
sure inventing a shiny new PKI, without any provision for key
expiration and revocation, is much of an improvement. And it looks to
me this idea means exactly that.

Also, given how SSL-enabled web servers work, either SNI is used
(still quite rare these days) or "a part of their website" would need
a dedicated IP => anyone who connects to that specific part of their
website would be singled out as a Tails' htpdate user.

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc