searching for keys

[kardan]

Hi, 

this already solved my mystery. Sorry that this was an easy one and
thanks for all your answers! I changed the certificate and feel a bit
more knowledged now. I usually retrieve TLS certificates with the
attached script (feedback appreciated) on first contact, thus I falsely
ignored the pool cert.

14 Jul 2013 12:08:27 +0200 Pete Stephenson <pete at heypete.com>:

> On Sun, Jul 14, 2013 at 9:46 AM, kardan <kardan at riseup.net> wrote:
> Did you follow the referral and query whois.publicdomainregistry.com
> to get the more detailed information about the domain? For example,
> http://smartwhois.com/whois/SKS-KEYSERVERS.NET will follow the
Amazing, the first time I saw somebody registering with a fingerprint
in the domain holder field.

> > Searching for the owner via gpg brings different results without
> > success. I assume the pool is not that well mantained?
Sorry, I was too tired.

> I searched for the registrant of sks-keyservers.net on the keyservers
> and found two current, valid public keys for them: a 4096-bit RSA key
> signed by lots of people (0x6B0B9508) and a 15,360-bit(!) RSA key with
> only a self-sig (0x43E67CF7).
I wonder how long the 15kb key will be safe. For my understanding with
current hardware it is possible to attack keys below 1kb. This means
anything encrypted below in the last years will be readable quite soon.
So the key used for encryption now should be choosen to not only
withstand current cluster power but must last next 50 years for
example. Otherwise all the data currently sniffed by the NSA, Iran,
google, etc. will be plain until governments become repressive enough
which is, looking at the last decade, before I am 60. (I hope you
correct me to be wrong for missing a significant detail.)

> The PEM certificate you mentioned,
> 
> > SSL certificate for hkps.pool.sks-keyservers.net:
> >
> > -----BEGIN CERTIFICATE-----
> > MIIGkzCCBXugAwIBAgIDCsjWMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
> [snip]
> 
> Appears to have been issued by StartSSL, a well-known CA, and has not
> been signed by the pool CA. The key is issued with a
> CN=www.secretresearchfacility.com. There is a pool key server running
> under that domain, keyserver.secretresearchfacility.com, but it's
> running on a server that uses SNI to use multiple SSL certificates on
> a single server.
Good to know how to overcome IPv4 scarcity for TLS.
https://en.wikipedia.org/wiki/Server_Name_Indication

> GnuPG appears to support SNI and so works correctly (gpg2 --search
> --keyserver hkps://keyserver.secretresearchfacility.com
> --keyserver-options ca-cert-file=./sks-keyservers.netCA.pem 0xDA122186
>  works properly) but does curl? If not, curl would not specify the
> correct hostname it's looking for and the server (which doesn't know
> what hostname the client wants) would present its default CA, which is
> the StartSSL-issued one.
Curl has no problems with this one either.

* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x8dc66a0) send_pipe: 1, recv_pipe: 0
* Connected to keyserver.secretresearchfacility.com (80.241.60.3) port 443 (#0)
* found 1 certificates in /home/kardan/config/certs/sks-keyservers.netCA.pem
*        server certificate verification OK
*        common name: keyserver.secretresearchfacility.com (matched)

14 Jul 2013 13:37:18 +0200 Kristian Fiskerstrand
<kristian.fiskerstrand at sumptuouscapital.com>:

> Also note that there is no requirement or any of the servers to offer
> a human-readable web interface, and as such no checking is performed
> as to how a possible such page is formed. This is a probably reason
> for you reporting getting data back on a non-encrypted channel, if.e.g
> you are met with a hard-coded <form action> on such a HTML template.
> The pool is configured to work with direct client HKP[2] requests and
> I'm not aware of any issues with this.

I see, the links on https://sks-keyservers.net/i/ are indeed to http

<form action="http://pool.sks-keyservers.net:11371/pks/lookup"
method="get">

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sslcert-get
Type: application/octet-stream
Size: 1224 bytes
Desc: not available
URL: </pipermail/attachments/20130716/eed4b696/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: </pipermail/attachments/20130716/eed4b696/attachment-0001.sig>