sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] quality of pool.sks-keyservers.net via http / https


From: Stephan Seitz
Subject: Re: [Sks-devel] quality of pool.sks-keyservers.net via http / https
Date: Wed, 10 Jul 2013 12:38:47 +0200

Am Dienstag, den 09.07.2013, 16:15 -0400 schrieb Phil Pennock: 
> On 2013-07-09 at 17:07 +0200, Stephan Seitz wrote:
> > It's not only about the design or something, some members are
> > redirecting to completely different content, which leads to any kind of
> > 404's because http://pool.sks-keyservers.net/pks/... doesn't exist.
> 
> I think the problem you are encountering is a *lack* of redirection.

Hi Phil,

yes, you're right, but you get the point anyway ;)


> If a site operator serves up an HTML web-page with resource links (CSS,
> images, scripting) referencing the hostname as supplied by the Host:
> header, that may not work well (unless the client is using SPDY).  If
> the site operator serves up the same page, referencing another hostname,
> that might cause cross-domain security issues, for some content.

Well, not necessarily. I assume most site operators are always setting
up vhosts for their own "keyserver.TLD" but didn't mention about
aliasing *.pool.sks-keyservers.net and keys.gnupg.net.


> Which is why, ideally, the server's top-level content on unrecognised
> hostnames (pools, and local aliases to the pool) will immediately
> redirect the user with a 302 to that server's own site, so that the page
> renders locally.  For the top-level content on the :11371 port, if that
> is provided by SKS itself (which doesn't do redirects) then meta refresh
> tags can work.

I think it's very unlikely to find other content than sks. For some kind
of proxy setup in front name-based aliases could also make sense, but
that heavily depends on the particular setup.

> As Kristian notes, none of this affects usage of keyservers with PKS
> clients, such as GnuPG or various graphical tools.

Right, gpg won't care about that. As I tried to explain, there is no
technical impact. It's about humans trying to get in contact with end to
end encryption for their very first time. Believe me, it's a hard way to
convince people that pgp isn't rocket-science. It's about training.
Maybe it's not the best way to start with a "Hey, take a look at my key.
By now, just use your browser."


> All of that aside, If you're requesting https: of a keyserver pool, you
> have some serious issues to face to get any kind of decent security,
> because the keyservers are run by unaffiliated volunteers from all over
> the globe, so there's no central key as required to normally get a
> certificate issued to the pool hostname (which is the one that clients
> will verify).

I know, I'm running a server which happens to be at the hkps pool ;)

> Instead, Kristian runs a dedicated mini-CA used to let server operators
> register with some local key and get a cert for the pool hostname, which
> when combined with TLS SNI can let server operators issue different
> certs for different hostnames and so provide for verifiable identity.
> See:
>   http://www.sks-keyservers.net/overview-of-pools.php
> for more details on hkps.pool.sks-keyservers.net.

@Kristian Would you think it's a good idea to put a link to the CA.pem
at some prominent position on the main page? I searched for it a few
weeks ago and currently found it on the overview of pools page. But my
former unsuccessful search could be a sign of lack of media
competence :-)

> Finally, if you're concerned about PRISM, using the public pools might
> be unwise.  How do you know that the NSA and GCHQ are not running
> keyservers in the public pools, so that they can get information about
> which IPs are requesting which PGP key ids or doing what uid searches?

Good point. I didn't thought about that.

> (Beware too that a lot of PRISM appears to be based around traffic
>  analysis, so when using PGP and defending against that, you'll need to
>  use --hidden-recipient while distributing the messages via some
>  mechanism that doesn't reveal the desired target address, so not
>  email).

Yes, also a nice hint.

Thanks a lot for your response!

Cheers,

- Stephan

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]