On Fri 2016-06-03 10:49:57 -0400, Christoph Egger wrote: > William Hay <w...@dumain.com> 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
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel