searching for keys

kardan kardan at riseup.net
Sun Jul 14 09:46:31 CEST 2013 

Hi,

On Sat, 13 Jul 2013 20:20:16 -0500 Larry Brower
<ivangrunt09 at gmail.com> wrote:

> http://keyserver.stack.nl also uses SSL. Is your main t that someone
> will see the keys you are looking for or retrieving?
> If this is the case then why not have them send them to you encrypted
> via email?

I worry about the general possibility to search keys without revealing
any metadata to the public. I think this is legitimate. If one sends
them to me encryptedly via email even better, but I need to have the
possibility to update them frequently to observe revocations and other
changes (best with low frequency via parcimonie). Or did you mean there
is a possibility to request keys via email from the key server? I never
heard of.

Am Sun, 14 Jul 2013 02:33:43 +0000
schrieb Henry Hertz Hobbit <hhhobbit at securemecca.net>:

> > [1] https://hkps.pool.sks-keyservers.net/
> > [2] http://keyserver.stack.nl  

> I question the legitimacy of the first in the first place since
> it doesn't even have a WHOIS record for either sks-keyservers.net
> or hkps.pool.sks-keyservers.net 

Thanks for the inspection! From my limited view I can not say what
makes a keyserver legitmate. This is what whois says for me

   Domain Name: SKS-KEYSERVERS.NET
   Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
   Whois Server: whois.PublicDomainRegistry.com
   Referral URL: http://www.PublicDomainRegistry.com
   Name Server: NS1.KFWEBS.NET
   Name Server: NS10.SKS-KEYSERVERS.NET
   Name Server: NS11.SKS-KEYSERVERS.NET
   Name Server: NS12.SKS-KEYSERVERS.NET
   Name Server: NS13.SKS-KEYSERVERS.NET
   Name Server: NS6.SKS-KEYSERVERS.NET
   Status: clientTransferProhibited
   Updated Date: 17-feb-2013
   Creation Date: 01-dec-2006
   Expiration Date: 01-dec-2015


Searching for the owner via gpg brings different results without
success. I assume the pool is not that well mantained?

$ gpg --search
kf at kfwebs.net gpg: suche nach "kf at kfwebs.net" auf hkps-Server
pool.sks-keyservers.net gpgkeys: HTTP search error 51:
gnutls_handshake() warning: The server name sent was not recognized

$ gpg --verbose --keyserver-options=debug --search kf at kfwebs.net
gpg: searching for "kf at kfwebs.net" from hkps server
pool.sks-keyservers.net gpgkeys: curl version = libcurl/7.31.0
GnuTLS/2.12.23 zlib/1.2.8 libidn/1.25 libssh2/1.4.3 librtmp/2.3
gpgkeys: search type is 0, and key is "kf at kfwebs.net"
* About to connect() to pool.sks-keyservers.net port 443 (#0)
*   Trying 192.0.224.138...
* Adding handle: conn: 0x984de90
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x984de90) send_pipe: 1, recv_pipe: 0
* Connection refused
*   Trying 192.95.24.133...
* Connection refused
*   Trying 198.82.169.69...
* Connected to pool.sks-keyservers.net (198.82.169.69) port 443 (#0)
* found 1 certificates
in /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
* server certificate verification failed.
CAfile: /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem CRLfile: none
* Closing connection 0
gpgkeys: HTTP search error 60: server certificate verification failed.
CAfile: /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem CRLfile: none
gpg: key "kf at kfwebs.net" not found on keyserver gpg: keyserver internal
error gpg: keyserver search failed: keyserver error

$ gpg --verbose --keyserver-options=debug --search kf at kfwebs.net
* About to connect() to pool.sks-keyservers.net port 443 (#0)
*   Trying 173.175.198.28...
...
gpg: keyserver timed out
gpg: keyserver search failed: keyserver error

*   Trying 91.121.176.163...
...
* server certificate verification failed.
  CAfile: /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem CRLfile: none

*   Trying 88.198.24.12...
...
* server certificate verification failed.
  CAfile: /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem CRLfile: none

*   Trying 87.106.189.5...
...
* server certificate verification failed.
  CAfile: /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem CRLfile: none

*   Trying 80.90.43.162...
* server certificate verification failed.
  CAfile: /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem CRLfile: none

*   Trying 80.241.60.3...
* Adding handle: conn: 0x89cee90
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x89cee90) send_pipe: 1, recv_pipe: 0
* Connected to pool.sks-keyservers.net (80.241.60.3) port 443 (#0)
* found 1 certificates
  in /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
* gnutls_handshake() warning: The server name sent was not recognized

*   Trying 66.114.139.158...
* Adding handle: conn: 0x90efe90
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x90efe90) send_pipe: 1, recv_pipe: 0
* Connected to pool.sks-keyservers.net (66.114.139.158) port 443 (#0)
* found 1 certificates
  in /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
* gnutls_handshake() failed: An unexpected TLS packet was received.


> and the browser warns that the
> certificate may not be legitimate.  Since I worked with lots of
> malware, this would lead me to believe I was well into the red
> zone.

Interesting, what are scenarios for a "bad" keyservers beneath
sending me wrong keys? The pool is maintained by Kristian Fiskerstrand
(kfwebs.net) who publishes about PGP/gpg quite a while and see no
reason to not trust him. I took the link from the mentioned gpg howto
by Daniel Kahn Gilmore:

https://we.riseup.net/riseuplabs+paow/openpgp-best-practices
> Don’t use pgp.mit.edu
> 
> pgp.mit.edu as a keyserver has been broken for years, especially with
> certain types of key updates. For a long time subkey updates, key
> expiration changes, revocations and other important information that
> you may wish to communicate to others, they were dropping on the
> floor.
> 
> They changed their software somewhat recently to a better supported
> keyserver, but it is still broken in ways that make it so it isn’t
> getting updates.
> 
> [...]
> 
> consider making your default keyserver use a
> keyserver that provides HKPS transport
> 
> Instead of the default, unencrypted hkp, you can use hkps! This
> obscures your social relationship map from anyone who may be snooping
> on your traffic. If you do a gpg —refresh-keys on a keyserver that is
> hkp only, then someone snooping your traffic will see every single
> key you have in your key ring as you request any updates to them.
> That is pretty interesting information.
> 
> Note that, for debian/ubuntu users, you will need to install the
> gnupg-curl package to use hkps.
> 
> You can use hkps.pool.sks-keyservers.net as your default keyserver,
> this is a pool containing only servers available using hkps. This
> pool only include servers that have been certified by the
> sks-keyservers.net CA.

<snip>

> On the other hand if you
> live in the FSA, er, the USA and are searching for the keys
> of the human rights advocates sitting next to Edward Snowden
> recently I can understand the concern.  I am not trying to
> contact those human rights activists so I am not worrying
> about that. 

That is not my concern either, but data retention is quite aggressive
in europe as well. I just think it is a bad idea the reveal when I
search whose gpg first and when they are updated (see above). Speaking
of Snowden allow me one noteworthy quote from his yesterday's statement:

"This willingness by powerful states to act extra-legally represents a
threat to all of us, and must not be allowed to succeed."

Have a good day remembering those who don't!
Kardan

More information about the Gnupg-users mailing list