Re: [Sks-devel] Pools & HSTS header

[Daniel Kahn Gillmor]

On Fri 2016-06-03 10:49:57 -0400, Christoph Egger wrote:
> William Hay <address@hidden> writes:
>> On Thu, May 26, 2016 at 12:47:57AM +0200, Valentin Sundermann wrote:
>>> Hi,
>>> 
>>> I enforce HTTPS on all my domains by sending the HSTS header to my
>>> visitors. HSTS forces the browser to use in future only secure
>>> connections to this domain. More info on Wikipedia[1] :)
>>> Since my keyserver could be added to pools of keyservers without any
>>> notice to me. It could be possible that some servers will send these
>>> kind of headers on pool domains too.
>>> 
>>> Did I miss there something or could this really lead to problems? :)
>>
>> AIUI HSTS only works if the header is received over an https connection
>> not an http one.  Unless you have a cert in the name of one of the pools
>> then anyone trying to connect to the pool who ends up connecting to your
>> server will not get far enough to see the HSTS header because of a name 
>> mismatch.
>
> Well.
>
>   http://pool.sks-keyservers.net(:11371)? --redirect--> 
> https://keyserver.siccegge.de 
>
> And if keyserver.siccegge.de present a valid certificate + HSTS would be
> a problem no? (and potentially undetected if the pool script mainly
> checks API pages)

No, this case is not a problem, because the HSTS header in this case
would be limited in scope to https://keyserver.siccegge.de/ -- this
would mean that the user could no longer visit
http://keyserver.siccegge.de:11371 (indeed, they might get redirected by
their browser to https://keyserver.siccegge.de:11371, which would be
wrong!), but they could still visit https://keyserver.siccegge.de
successfully.

I think the concern raised is if a client has accepted the sks-keyserver
CA, and they visit https://hkps.pool.sks-keyservers.net/.  Then in that
case, they see one of many servers, and those servers themselves offer
an HSTS header, while the others do not.

However, i don't think this is a particularly bad thing, given that the
entire point of the name hkps.pool.sks-keyservers.net is to force HTTPS.
if you've accepted a cert for any of them, then you should accept the
HSTS header for all of them.

Arguably, we should *encourage* people who operate hkps members of the
pool to set the Strict-Transport-Security when serving that virtual
Host.

The bigger problem is actually the HPKP (public key pinning) header: one
member of the pool could use it to lock out other members of the pool,
and i don't see a way around that.

Perhaps we should include a standard HPKP header that indicates the SKS
CA key and a backup key, and encourage everyone in the pool to set that
in addition to HSTS?

   --dkg

signature.asc
Description: PGP signature