gpg --refresh with large keyrings and hkps in 2.1.1

[Daniel Kahn Gillmor]

On Wed 2015-04-15 14:44:55 -0400, Ben McGinnes wrote:
> I have a work-around for something else relating to dirmngr which may
> also serve as work-around for this.  Now since I've got around 9,400
> keys in my public keyring, if I can do a full refresh (regardless of
> keyserver or server connection protocol), then that ought to do the
> job.  Now granted, I'm not trying to force TLS connections to the
> keyservers, but the reason for that is that my workaround is to pipe
> all keyserver traffic through proxychains and Tor.
>
> I figure that since the keys are what they are, they can protect
> themselves.  So the real benefit is in foiling traffic analysis and
> since all Tor connections use TLS within the Tor network anyway, no
> one's going to really be able to see which keys I'm requesting or
> updating.

Does this protect the privacy of your keyring effectively against people
snooping between tor and the keyserver, though?

Your keyring is likely to be unique to you.

Tor circuits to a particular endpoint are likely to be stable over the
period of time it would take to fetch the whole keyring.

As a result, someone monitoring traffic as it flows between the tor exit
nodes and the keyservers can see your keyring today, and can probably
notice when you add new keys to your keyring.

> Now here's the thing, via the proxychains tunnel there is no trouble
> with a TLS connection (proxychains feeds into a default privoxy
> instance and then into the Tor SOCKS5 service, all of which is strung
> together with a handful of bash scripts to load the relevant homedir
> and optionally restart dimngr through proxychains).  It happily
> munches its way through approx. 9,300 of those keys.  The remaining
> hundred or so have hard-coded keyserver preferences pointing to https,
> hkps or ldap services and those keel over with the same errors that
> have been reported already or a report that the keyserver cannot be
> reached.

You can specify keyserver-options no-honor-keyserver-url if you want to
avoid this last bit.  Are you saying that this doesn't work with dirmngr
for you?

> Note also that using proxychains is only necessary because while
> dirmngr recognises a specified keyserver, it doesn't recognise proxy
> settings.

This is distressing.  the dirmngr info pages clearly documents these
options:

'--honor-http-proxy'
     If the environment variable 'http_proxy' has been set, use its
     value to access HTTP servers.

'--http-proxy HOST[:PORT]'
     Use HOST and PORT to access HTTP servers.  The use of this options
     overrides the environment variable 'http_proxy' regardless whether
     '--honor-http-proxy' has been set.

I just tested it and i think they're still broken for 2.1.3.

I see that https://bugs.g10code.com/gnupg/issue1786 has been opened
about this, i've just commented there.  Let's take this part of the
discussion there.

> Now, without taking each packet apart, there is one major difference
> between the Tor TLS connections and GPG's TLS connections.  That, of
> course, is that most notorious of SSL/TLS libraries: GnuTLS.  My
> suspicion is that this is the source of the failure to reach hkps and
> https keyservers, regardless of variations in the error messages GPG
> responds with.

Hm, there was no "failure to reach hkps and https keyservers" -- just
that the refresh process terminates after some number of keys are
fetched, instead of continuing through the entire list.  I don't think
the rest of your proposal addresses the concerns i've raised in this
thread -- if the proxy situation is working, that doesn't remove the
need for hkps.

         --dkg

PS I think calling GnuTLS "most notorious" is bizarre.