Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/07/2012 03:18 AM, Phil Pennock wrote: On 2012-10-06 at 11:12 +0200, Stephan Seitz wrote: I'ld like to add ssl to my server, but prior I'm afraid I need a few questions answered. If I'm going to install a self-signed *.pool.sks-keyservers.net, that CRT wouldn't have any reputation. As long as there's no additional trust added (e.g. via monkeysphere), one main purpose of certificates, the knowledge of talking to the right server, isn't given. I think that self-signed is out. But if the pool server operator issues certs, given a CSR from you, then all certs are valid given a trust in the CA which is the pool server operator. If Kristian decides that he wants to take on this work, and figure out a safe way of managing key storage, then we can talk to the GnuPG folks about getting his private CA cert (created for this) shipped with GnuPG as an additional trust anchor. It doesn't need to be a system cert, just something which that application uses. Ok, I think I'm getting closer to having a working setup for a CA here using subjectAltNames for hkps.pool.sks-keyservers.net The current CA cert is available at [0] and I only currently sign https://keys.kfwebs.net:11375 and https://keys2.kfwebs.net. Anyone up for some testing? [0] https://sks-keyservers.net/sks-keyservers.netCA.pem -- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk Nulla regula sine exceptione No rule without exception This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 2012-10-08 at 19:44 +0200, Kristian Fiskerstrand wrote:
Ok, I think I'm getting closer to having a working setup for a CA here
using subjectAltNames for hkps.pool.sks-keyservers.net
The current CA cert is available at [0] and I only currently sign
https://keys.kfwebs.net:11375 and https://keys2.kfwebs.net.
Note for testing: GnuPG will use SRV records for the hkps: URL scheme,
which may override some local DNS overrides data, but will not use SRV
for the https: scheme.
The below is an example of a test against one of the existing servers,
since it's useful to test something which is supposed to work, before
trying to make your additional configuration work; I now _maybe_ have a
known-good state to try to work towards.
Kristian: this appears to be the same certificate as is presented if I
use {{ --keyserver keys2.kfwebs.net }}. Is there a way to confirm that
gpgkeys_hkps/curl are playing together nicely and setting
serverNameIndication in the TLS negotiation?
8 cut here 8--
% unbound-control local_data hkps.pool.sks-keyservers.net A 84.215.15.221
ok
~/.gnupg/gpg.conf:
keyserver https://hkps.pool.sks-keyservers.net
keyserver-options
verbose,ca-cert-file=/home/phil/.gnupg/CA/sks-keyservers.netCA.pem
Then:
% gpg --keyserver-options debug --refresh-key $gpg_key
gpg: refreshing 1 key from https://hkps.pool.sks-keyservers.net
gpg: requesting key 0x403043153903637F from https server
hkps.pool.sks-keyservers.net
gpgkeys: curl version = libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.2.3 libidn/1.22
libssh2/1.4.1 librtmp/2.3
Scheme: https
Host: hkps.pool.sks-keyservers.net
Path: /
Command:GET
* About to connect() to hkps.pool.sks-keyservers.net port 443 (#0)
* Trying 84.215.15.221...
* connected
* Connected to hkps.pool.sks-keyservers.net (84.215.15.221) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /home/pdp/.gnupg/CA/sks-keyservers.netCA.pem
CApath: none
* SSL connection using ECDHE-RSA-AES256-SHA
* Server certificate:
*subject: C=NO; ST=Oslo; O=keys2.kfwebs.net; CN=keys2.kfwebs.net
*start date: 2012-10-08 17:38:36 GMT
*expire date: 2013-10-08 17:38:36 GMT
*subjectAltName: hkps.pool.sks-keyservers.net matched
*issuer: C=NO; ST=Oslo; O=sks-keyservers.net CA; CN=sks-keyservers.net
CA
*SSL certificate verify ok.
GET / HTTP/1.1
[...]
8 cut here 8--
pgpmhMLJWpLWO.pgp
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/08/2012 10:09 PM, Phil Pennock wrote: On 2012-10-08 at 21:32 +0200, Kristian Fiskerstrand wrote: The certificate presented by keys2.kfwebs.net should be chained certificate containing both the CA itself and the individual cert for keys2.kfwebs.net. I'm not entirely sure that this is fully required, but at least it works for me :) Right, that tests subjectAltName operation in TLS certificate verification. That works. Unless everyone else _replaces_ their certs with certs issued by you, that in itself doesn't help: it means you become the only person who can issue certs for any SKS keyserver's HTTPS interface. Well, to be a pedant, only for the servers that are to be included in the hkps pool :p The key is for other people to be able to issue _different_ certs based on the serverNameIndication in the TLS client hello message; vhosting, like the Host: header in HTTP, but moved up into the TLS handshake so that the server can select the correct key/cert pair to use for the session. I'll go ahead and send you a CSR shortly, so that sks.spodhuis.org can have two certs and we can test. :) Lovely! Must admit my setup is a tad more plain than that (just using nginx in front of SKS) :) Will be interesting to see how that goes. -- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk Veni vidi visa I came, I saw, I bought This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/08/2012 10:49 PM, Phil Pennock wrote:
On 2012-10-08 at 22:12 +0200, Kristian Fiskerstrand wrote:
Lovely! Must admit my setup is a tad more plain than that (just using
nginx in front of SKS) :) Will be interesting to see how that goes.
Mine too.
...
So, assuming that GnuPG is also doing the right thing with SRV-based
lookups, I think that the certificate side of things is working.
At least that is a good thing in all this :)
Unfortunately, with an https: keyserver, GnuPG is sending a request for
/ instead of /pks/lookup?... :(
If I do:
% unbound-control local_data
% _pgpkey-https._tcp.hkps.pool.sks-keyservers.net SRV 10 10 443
sks.spodhuis.org
ok
and specify keyserver hkps://hkps.pool.sks-keyservers.net in
~/.gnupg/gpg.conf, then I find that GnuPG has a security bug!
That seems like another bug to add to the SRV port not being used for
SRV handling. Are you sending it over to gnupg-{users,devel}?
I'll have to remove the SRV record for keys.kfwebs.net for the pool to
function correctly at the moment, as this is not handled. But that bug
has already been reported upstream.
Any thoughts on how I should proceed? Should I disable the cert check in
my crawler so that all hkps servers show up for now until some more of
the server operators (presuming they want to) generate CSRs, or, given
the young nature of this pool, would it be OK to just grow organically?
--
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
Veni vidi visa
I came, I saw, I bought
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/08/2012 11:01 PM, Kristian Fiskerstrand wrote: On 10/08/2012 10:49 PM, Phil Pennock wrote: On 2012-10-08 at 22:12 +0200, Kristian Fiskerstrand wrote: Lovely! Must admit my setup is a tad more plain than that (just using nginx in front of SKS) :) Will be interesting to see how that goes. Mine too. ... So, assuming that GnuPG is also doing the right thing with SRV-based lookups, I think that the certificate side of things is working. At least that is a good thing in all this :) Unfortunately, with an https: keyserver, GnuPG is sending a request for / instead of /pks/lookup?... :( If I do: % unbound-control local_data % _pgpkey-https._tcp.hkps.pool.sks-keyservers.net SRV 10 10 443 sks.spodhuis.org ok and specify keyserver hkps://hkps.pool.sks-keyservers.net in ~/.gnupg/gpg.conf, then I find that GnuPG has a security bug! Just a point I forgot in my latest email. I'm checking port 443 by default if there is no SRV record. So you should be able to just remove this in your setup. -- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk Great things are not accomplished by those who yield to trends and fads and popular opinion. (Jack Kerouac) This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
Am Montag, den 08.10.2012, 13:09 -0700 schrieb Phil Pennock: On 2012-10-08 at 21:32 +0200, Kristian Fiskerstrand wrote: The certificate presented by keys2.kfwebs.net should be chained certificate containing both the CA itself and the individual cert for keys2.kfwebs.net. I'm not entirely sure that this is fully required, but at least it works for me :) Right, that tests subjectAltName operation in TLS certificate verification. That works. Unless everyone else _replaces_ their certs with certs issued by you, that in itself doesn't help: it means you become the only person who can issue certs for any SKS keyserver's HTTPS interface. The key is for other people to be able to issue _different_ certs based on the serverNameIndication in the TLS client hello message; vhosting, like the Host: header in HTTP, but moved up into the TLS handshake so that the server can select the correct key/cert pair to use for the session. I'll go ahead and send you a CSR shortly, so that sks.spodhuis.org can have two certs and we can test. :) Hi guys, sorry for asking dumb questions, but this is something far beyond my daily business ;) I recently created a key /csr for keyserver.secretresearchfacility.com . It's signed by a CA, so I currently do have a valid crt. As I read your posts, I guess I should create a new csr for that key like: subjectAltName = @alt_names [alt_names] DNS.1 = keyserver.secretresearchfacility.com DNS.2 = hkps.pool.sks-keyservers.net and glue the results (my key, the two crt's and the intermediate(s)) together? I don't believe this will work ;) Another approach could be SNI, couldn't it? I already use namebased vhosts (thank's for your explanation of TLS, phil), so I could configure two proxies which are identical despite the hostname and the certificates. That way, I would use two different keys / crts without the need for subjectAltName. signature.asc Description: This is a digitally signed message part ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 2012-10-08 at 23:01 +0200, Kristian Fiskerstrand wrote:
That seems like another bug to add to the SRV port not being used for
SRV handling. Are you sending it over to gnupg-{users,devel}?
I just filed a bug:
https://bugs.g10code.com/gnupg/issue1447
I'll have to remove the SRV record for keys.kfwebs.net for the pool to
function correctly at the moment, as this is not handled. But that bug
has already been reported upstream.
Any thoughts on how I should proceed? Should I disable the cert check in
my crawler so that all hkps servers show up for now until some more of
the server operators (presuming they want to) generate CSRs, or, given
the young nature of this pool, would it be OK to just grow organically?
I think we should leave the cert check in, _if_ you can ensure that
you're sending SNI of hkps.sks-keyservers.net, to retrieve the correct
cert from the server.
Then let it grow, and note that this pool is only going to be usable
with bug-fixed GnuPG.
-Phil
pgpeWDxYgQGoK.pgp
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/08/2012 11:08 PM, Phil Pennock wrote:
On 2012-10-08 at 23:01 +0200, Kristian Fiskerstrand wrote:
That seems like another bug to add to the SRV port not being used for
SRV handling. Are you sending it over to gnupg-{users,devel}?
I just filed a bug:
https://bugs.g10code.com/gnupg/issue1447
I'll have to remove the SRV record for keys.kfwebs.net for the pool to
function correctly at the moment, as this is not handled. But that bug
has already been reported upstream.
Any thoughts on how I should proceed? Should I disable the cert check in
my crawler so that all hkps servers show up for now until some more of
the server operators (presuming they want to) generate CSRs, or, given
the young nature of this pool, would it be OK to just grow organically?
I think we should leave the cert check in, _if_ you can ensure that
you're sending SNI of hkps.sks-keyservers.net, to retrieve the correct
cert from the server.
Then let it grow, and note that this pool is only going to be usable
with bug-fixed GnuPG.
Well, unless we adhere to the bug itself and remove the SRV record,
which isn't strictly necessary for the standard port.
--
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
Great things are not accomplished by those who yield to trends and fads
and popular opinion.
(Jack Kerouac)
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/08/2012 10:49 PM, Phil Pennock wrote: ... Unfortunately, with an https: keyserver, GnuPG is sending a request for / instead of /pks/lookup?... :( Btw, this is related to [0], the https:// scheme isn't intended to be used this way [0] http://lists.gnupg.org/pipermail/gnupg-devel/2009-November/025426.html -- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk Great things are not accomplished by those who yield to trends and fads and popular opinion. (Jack Kerouac) This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 2012-10-08 at 23:25 +0200, Kristian Fiskerstrand wrote: On 10/08/2012 10:49 PM, Phil Pennock wrote: Unfortunately, with an https: keyserver, GnuPG is sending a request for / instead of /pks/lookup?... :( Btw, this is related to [0], the https:// scheme isn't intended to be used this way Bleh, then specifying http:/https: as --keyserver should be a config bug and issue a warning, because while those URLs might be suitable for --fetch-keys they're just not suitable as --keyserver. -Phil pgpqLSOEHB1Vb.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/05/2012 06:23 PM, Phil Pennock wrote: Speaking for myself, I only use TLSv1+ and my nginx is built with SNI support, so if you want to figure out a policy for handing out certs, I can add a new cert for SNI hostnames in *.pool.sks-keyservers.net. alternately (or in addition?), we could use monkeysphere and the hkpms gpg keyserver handler, which would let us trivially add extra hostnames to each keyserver's certificate (an OpenPGP certificate, not X.509). Those of us who run servers in the pool or who are interested in keeping track of the players here could cross-verify each others' certificates, and end users who know or are willing to rely on us could verify them that way, while setting keyserver hkpms://hkps.pool.sks-keyservers.net in ~/.gnupg/gpg.conf. I'm happy to help people walk through those steps if they want, and if people think that's a reasonable idea. if people don't think it's a reasonable idea, i'd be interested to hear the reasons for that too. thanks for setting up the pool, kristian! --dkg signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 10/06/2012 12:23 AM, Phil Pennock wrote: I get results from: dig -t a hkps.pool.sks-keyservers.net dig -t srv _pgpkey-https._tcp.hkps.pool.sks-keyservers.net but not from: dig -t hkps.pool.sks-keyservers.net (NOERROR, with AUTHORITY section, so just looks as though there are no records configured). Is this just the pool being size-limited in records and happening to currently only include A records? Hi Phil, No, it was a temporary issue with my IPv6 connectivity[0], so no server was recorded as having IPv6 capability. This pool likely need the keyserver option set to no-check-cert to function as expected. Speaking for myself, I only use TLSv1+ and my nginx is built with SNI support, so if you want to figure out a policy for handing out certs, I can add a new cert for SNI hostnames in *.pool.sks-keyservers.net. Let me think a bit more about this one :) [0] https://www.sixxs.net/tickets/?msg=tickets-7961722 -- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk Varitatio delectat Change pleases This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 2012-10-06 at 11:12 +0200, Stephan Seitz wrote: I'ld like to add ssl to my server, but prior I'm afraid I need a few questions answered. If I'm going to install a self-signed *.pool.sks-keyservers.net, that CRT wouldn't have any reputation. As long as there's no additional trust added (e.g. via monkeysphere), one main purpose of certificates, the knowledge of talking to the right server, isn't given. I think that self-signed is out. But if the pool server operator issues certs, given a CSR from you, then all certs are valid given a trust in the CA which is the pool server operator. If Kristian decides that he wants to take on this work, and figure out a safe way of managing key storage, then we can talk to the GnuPG folks about getting his private CA cert (created for this) shipped with GnuPG as an additional trust anchor. It doesn't need to be a system cert, just something which that application uses. I suspect that any such approach would have a master root cert shipped with GnuPG and kept on an offline storage device, used for signing an intermediate CA which is used for his routine signing of keyserver CSRs, so that if there is an incident then we can recover without affecting the install base of GnuPG: create new intermediate, give all keyserver operators new CRTs based on their previous CSRs, wait for some reasonable amount of time for updates and then drop from the pool any servers still using the old CRT; use master/root to revoke old intermediate, update CRL. Make sure that the communication with the GnuPG folks has discussed how often a CRL should be checked, if at all. (There's also the OCSP stapling option which shifts around the failure boundaries, but OCSP stapling support is more problematic, server-side, last I checked). I'm also concerned about the self-signed CAs. If we're going to self-sign certs, shouldn't we send the CSRs to Kristian to have it signed by his CA? That was my proposal; Monkeysphere is different and adds a _different_ trust mechanism to TLS -- if traditional PKI validation fails, then check in a different store. That approach works, if someone is in the strong set or has trust paths to various keys. As far as I can see, without having actually used it, this becomes more problematic for the occasional user, unless Monkeysphere is replacing the untrustworthy trusted third party in PKI by designating some PGP keys as hopefully not untrustworthy trusted third parties in the web of trust. Oh, and one slightly off-topic question. Does some of you know the current acceptance of TLS1.1/SNI in the web? I'ld need to switch to SNI for Port 443. SNI is available from TLS1.0 onwards; TLSv1.1+ are good and worthy, but not required. Except, apparently, in Opera, but that's Opera being weird, not a protocol requirement. http://en.wikipedia.org/wiki/Server_Name_Indication#Support Summary: Just about every current browser you'd expect to see being used, except for all the folks with pre-Honeycomb Android phones/tablets, who are going to be increasingly stuck unless their providers get off their arses and actually provide updates. Onto TLS1.1+: GnuTLS has supported TLS1.1+ for many years; OpenSSL came out with a stable release (1.0.0) which supported them a year or so back, IIRC. It looks like NSS is just about managing to get support into mainline and out to browsers now? https://bugzilla.mozilla.org/show_bug.cgi?id=565047 In practice, SNI support is now about at the point where you wouldn't want to rely on it for something revenue generating (or of equal importance in non-commercial organisations) but for ancillary systems it should be fine. On personal websites, it's definitely okay. I've been using it for years, without issues. Sometimes scripting language support is problematic. Most notably, Python folks decided that SNI support would only go into Python 3. But since Python 2 has no support for TLS verification, if you're using Python2 for security-sensitive TLS handling, you're already in such deep trouble that this isn't a big additional problem. Switch to Python 3 for competent TLS handling. -Phil pgpyw1PHFk1AN.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
On 2012-10-05 at 20:48 +0200, Kristian Fiskerstrand wrote: Just to inform that I've added a new hkps subpool to the list of options. Regular A and and SRV records are included for port 443 servers, and a lookup is performed for _pgpkey-https._tcp on the individual servers to determine if a hkps enabled service is listening on another port, in which case this is included as a SRV record also in the pool (but not as an A or record). I get results from: dig -t a hkps.pool.sks-keyservers.net dig -t srv _pgpkey-https._tcp.hkps.pool.sks-keyservers.net but not from: dig -t hkps.pool.sks-keyservers.net (NOERROR, with AUTHORITY section, so just looks as though there are no records configured). Is this just the pool being size-limited in records and happening to currently only include A records? This pool likely need the keyserver option set to no-check-cert to function as expected. Speaking for myself, I only use TLSv1+ and my nginx is built with SNI support, so if you want to figure out a policy for handing out certs, I can add a new cert for SNI hostnames in *.pool.sks-keyservers.net. -Phil pgpDpyDpqLqBM.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
