gpg --refresh with large keyrings and hkps in 2.1.1

[Ben McGinnes]

On 14/04/2015 12:50 pm, Daniel Kahn Gillmor wrote:
> On Tue 2014-12-16 19:13:19 -0500, Daniel Kahn Gillmor wrote:
>> i'm trying to test "gpg --refresh" with large keyrings in gnupg 2.1.1.
>> It's better than it was before, but i'm still getting some errors with a
>> larger keyring.
>>
>> In particular, i'm seeing an abort when i try to refresh the a large
>> keyring against an hkps keyserver; only the first 83 keys get refreshed,
>> and then gpg aborts with:
>>
>> gpg: keyserver refresh failed: Input/output error
> 
> I'm still seeing this problem with gpg --refresh for large keyrings in
> 2.1.3 (though the cutoff is different -- it's about 88 now instead of
> 83).  I've opened https://bugs.g10code.com/gnupg/issue1950 to track the
> issue.

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.

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.

Note also that using proxychains is only necessary because while
dirmngr recognises a specified keyserver, it doesn't recognise proxy
settings.  Whether this is related or not, I haven't yet one hundred
percent confirmed (because I haven't gotten around to setting up a
MitM on my own traffic).

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.

Now I get that there's that annoying license conflict which pretty
much locks GPG into GnuTLS, in spite of it's ... ah, track record.
However, there's a nice and easy solution to that whole situation: add
support for SOCKS5 proxies and restore support for HTTP/S proxies
natively to allow a local proxy configuration to utilise the user's
choice of GnuTLS, OpenSSL, LibreSSL or whatever else (e.g. my Tor
service is compiled with OpenSSL 1.0.2 and ec_nistp_64_gcc_128
enabled).  Then worry about isolating what GnuTLS broke this time.

Yes, this is a guestimate ... but given past performance, the chances
that GnuTLS broke something (again), it's a reasonably well founded
one.  Hence my suggestion to remove GnuTLS from the equation.


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150416/c89b611b/attachment.sig>