Hi, On Sat, 13 Jul 2013 20:20:16 -0500 Larry Brower <ivangrun...@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 <hhhob...@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 k...@kfwebs.net gpg: suche nach "k...@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 k...@kfwebs.net gpg: searching for "k...@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 "k...@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 "k...@kfwebs.net" not found on keyserver gpg: keyserver internal error gpg: keyserver search failed: keyserver error $ gpg --verbose --keyserver-options=debug --search k...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
