Re: [Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached
On 06/04/2016 01:26 AM, Gunnar Wolf wrote: > Do you have an example of keys coming from evil32? 0xA6B2BBAD94C09C7F -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Uxor formosa et vinum sunt dulcia venena Beautiful women and wine are sweet venom 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] 32-bit (short ID) collisions: New milestone(?) reached
Kristian Fiskerstrand dijo [Sat, Jun 04, 2016 at 01:16:16AM +0200]: > > For the full version, please read my post: > > > > http://gwolf.org/node/4070 > > This doesn't seem to reference the [evil32] keyring that seems to have > been [included in the public network], btw. Nothing new there and > irrelevant from a security perspective. Yes, I saw that, and was intrigued not to find any suspicious matching keys in the public network. I guess I didn't know how to look — Do you have an example of keys coming from evil32? ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached
On 06/04/2016 12:43 AM, Gunnar Wolf wrote: > Hi all, > > For the full version, please read my post: > > http://gwolf.org/node/4070 This doesn't seem to reference the [evil32] keyring that seems to have been [included in the public network], btw. Nothing new there and irrelevant from a security perspective. References: [evil32] https://evil32.com [included in the public network] https://sks-keyservers.net/status/key_development.php -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins 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] 32-bit (short ID) collisions: New milestone(?) reached
Hi! Gunnar Wolf writes: > There are several tools relying on this (now very) weak 32-bit scheme; > the first such tool we found was precisely the «PGP pathfinder & key > statistics» service, which fails badly: Even specifying the full > fingerprints, I do get three (absolutely fake!) trust path into the > impostor: > > > http://pgp.cs.uu.nl/mk_path.cgi?FROM=AB41C1C68AFD668CA045EBF8673A03E4C1DB921F&TO=88BB08F633073D7129383EE71EA37A0C9F6C6333&PATHS=trust+paths Moving this to full fingerprints is pretty high on my TODO list for a while .. though old consumers seem to be pretty unhappy with any change to the data so this needs fixing as well (the website being the only exception). Hope I can get it done this summer ... You shouldn't trust the data there fwiw .. the mining script doesn't actually *check* any signatures and blindly believes what it says on the envelope. Might change as well when I fix the collector but we'll see. Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached
On 06/04/2016 12:43 AM, Gunnar Wolf wrote: > Hi all, .. > > And the main reason I am writing this mail: SKS listings all show this > 32-bit ID only. It does differentiate when keys collide on their short > keyids, but it promotes users using a weak representation; IMO we > should change SKS to show either long keyids or the full fingerprint. > You can't trust the output from keyservers for this data to begin with, so at this point it is moot, you need to download the key in question and perform your own calculation of the fingerprint as part of a bilateral exchange of information out of band to validate the key. PS, although the short keyid is used in listing, the 64 bit long keyid is used for cross-references, this is a convenience factor and not related to any security (as keyservers doesn't provide any, users have to) -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We all die. The goal isn't to live forever, the goal is to create something that will." (Chuck Palahniuk) signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached
Hi all, For the full version, please read my post: http://gwolf.org/node/4070 In short: In Debian, we found two keys sharing the «9F6C6333» short ID, sporting the same name in them, but one of them is *not* recognized by the supposed owner. Not only that, this key is signed by three keys (not (yet?) uploaded to the global keyring) B29B232A, F2C850CA and 789038F2 — Those are also the three short IDs for the keys signing the legitimate key. There are several tools relying on this (now very) weak 32-bit scheme; the first such tool we found was precisely the «PGP pathfinder & key statistics» service, which fails badly: Even specifying the full fingerprints, I do get three (absolutely fake!) trust path into the impostor: http://pgp.cs.uu.nl/mk_path.cgi?FROM=AB41C1C68AFD668CA045EBF8673A03E4C1DB921F&TO=88BB08F633073D7129383EE71EA37A0C9F6C6333&PATHS=trust+paths And the main reason I am writing this mail: SKS listings all show this 32-bit ID only. It does differentiate when keys collide on their short keyids, but it promotes users using a weak representation; IMO we should change SKS to show either long keyids or the full fingerprint. Greetings, ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Pools & HSTS header
On Fri 2016-06-03 10:49:57 -0400, Christoph Egger wrote: > William Hay 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
Re: [Sks-devel] Pools & HSTS header
On Fri, Jun 03, 2016 at 04:49:57PM +0200, Christoph Egger wrote: > 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) You don't specify what hostname keyserver.siccegge.net presents a valid for which is kind of key. If it does an http redirect to https://keyserver.siccegge.de which presents a certificate for keyserver.siccegge.de then it is keyserver.sicegge.de that will go into the https only list which is fine since keyserver.siccegge.de supports https. If it does an http redirect to https://pool.sks-keyservers.net then unless keyserver.siccege.de has a certificate in that name the browser will start complaining loudly and won't even see the HSTS header. William signature.asc Description: Digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Pools & HSTS header
William Hay 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) Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel