Re: [Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached

[Kristian Fiskerstrand]

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

[Gunnar Wolf]

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

[Kristian Fiskerstrand]

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

[Christoph Egger]

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=88BB08F633073D7129383EE71EA37A0C9F6C6333=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

[Kristian Fiskerstrand]

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

Re: [Sks-devel] Pools & HSTS header

[Daniel Kahn Gillmor]

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

[William Hay]

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

[Christoph Egger]

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