sks.daylightpirates.org is staying...again

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

sks.daylightpirates.org is staying...again

Daniel Roesler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Howdy all,

Once again, I'm letting everyone know my server is staying.

I'm constantly in-and-out of the pool due to issue #61*, but so
what? I can be of service to people needing to use pool when I'm
in and my CPU always calms back down after a few minutes and get
back into the pool.

We can't be dissuaded by spoilers and abusers. The vast majority
of the pool is still used for public key and signature sharing,
which is a cause I believe in.

I'm staying. I hope you do, too.

Daniel


* https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJb8s+4AAoJEMtwcDcM6wt6tHIH+wVcyGx0YCP0kugQa7QLUh/M
xG8qz5md/htkUx4YvQva5EDtKxDpuWXtwz2pkeD46CL1zj5sBQdrJgldhVjumMqI
mw3WLEHtopVIvToRROlwBTchi4MJctF9XQA5s6HvAAPEsV6YmijhV/nWYirpSIKj
IUT6Jw2lVYhhl0RiISteZg7rHrYu48kX+BkV2kUcL6GwQtHRhKLa92bwSI4SwYOq
D1SuSsw7NBl/qlUPjR5UF4Mi+PNyPZCvvNnXUYAkY6sMUTltiqG9eWaiWWbn/d9k
ASMFNsdup8LxE/du6TYxL2O3mJA8HoZx13W/YVOgZxU0GouJCnbEqcRM0Ayz/jc=
=rShr
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Yegor Timoshenko
> Howdy all,

Hey!

> I'm constantly in-and-out of the pool due to issue #61*, but so
> what? I can be of service to people needing to use pool when
> I'm in and my CPU always calms back down after a few minutes
> and get back into the pool.

If you want to momentarily fix the issue, rebuild SKS with the
following patch applied:
https://lists.nongnu.org/archive/html/sks-devel/2018-07/msg00053.html

However, mind that anyone can build another poison key by
following instructions in
https://bitbucket.org/skskeyserver/sks-keyserver/issues/60,
meaning underlying issue is not fixed.
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Alin-Adrian Anton
Hey Yegor and all,

Do you happen to have a long-term patch also, or just the hardcoded poison key?

I wonder why nobody thought about this possibility before.. so any lasting fix besides hardcoded blacklisting?

It is very easy to test for vulnerabilities if you actually install sks on your own machine first, and try to also fix it before publishing/exploiting it. Many have tutorials on this subject and all you need is a copy of a key dump.

There are other ways of bringing an sks server down, and BDB might not be the best idea for a server, still the network is important for both free software and individuals using it.

Blockchain technology has larger issues when it comes to GDPR yet we don't see blockchain nodes going away for this very reason.

The SKS network is even more important after the recent privacy incidents that everybody knows about, and I wonder how safe is PGP done in javascript, or sks key generation on Raspberry PI:) . There were issues for ssh key pairs.

I should try it, just to see how predictible the RPI key pair is. Btw I tried out these two commands on GNU/Linux (ffmpeg and drivers are necessary):

1) If you have a webcam on GNU/Linux just copy and run this line at the command prompt: echo `ffmpeg -t 5 -f video4linux2 -i /dev/video0 -f ogv - | sha512sum - | cut -f1 -d' '` > /dev/random; echo "You may run gpg --gen-key now"

2) For audio only random input with noise run this: echo `ffmpeg -f alsa -i hw:0 -t 10 -f ogv - | sha256sum | cut -f 1 -d' '` > /dev/random; echo "You may run gpg --gen-key now"

As far as I know anything you write into /dev/random on GNU/Linux is getting SHA1 with whatever was there already in the buffer, so the more data you copy into /dev/random the "better" it is in terms of random seed initialization. I think this observation is also important for Android e-mail clients and other embedded devices.

The noise provided by the webcam seems to be sufficient for initializing /dev/random so when the webcam is covered with plastic foil the command is still useful, maybe at boot/reboot time.

SKS seems to have a -seed parameter.


Alin Anton


On 11/19/2018 05:14 PM, Yegor Timoshenko wrote:
Howdy all,
Hey!

I'm constantly in-and-out of the pool due to issue #61*, but so
what? I can be of service to people needing to use pool when
I'm in and my CPU always calms back down after a few minutes
and get back into the pool.
If you want to momentarily fix the issue, rebuild SKS with the
following patch applied:
https://lists.nongnu.org/archive/html/sks-devel/2018-07/msg00053.html

However, mind that anyone can build another poison key by
following instructions in
https://bitbucket.org/skskeyserver/sks-keyserver/issues/60,
meaning underlying issue is not fixed.


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

-- 
Sl.univ.dr.ing. Alin-Adrian Anton
Politehnica University of Timisoara 
Department of Computer and Information Technology
2nd Vasile Parvan Ave., 300223 Timisoara, Timis, Romania


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Yegor Timoshenko
> Do you happen to have a long-term patch also, or just the
> hardcoded poison key?

I don't, and most importantly, I don't think a long-term patch is
even possible without completely overhauling SKS.

Fundamentally, given current implementation, this attack means
two things: attacker can take down the whole network via OpenPGP
packet spamming pinged back and forth by recon, and attacker can
deny recon to any specific key by adding a bunch of garbage
packets to that key to the point of making its recon impossible.
Both attacks are feasible today to anyone and do not require any
resources.

I can imagine how to fix the first problem while retaining full
compatibility with SKS, but not without making the latter even
worse than it is now which is in my opinion the more critical
problem.

1) If max key size is set, it means any key can be denied further
updates by uploading signatures up to that size (which will be a
valid attack even against validating keyservers; against
non-validating keyservers, any kind of packet will work). This
means at the very least being able to deny any further signatures
to that key, making it possible to undermine WoT, and unless a
complex per-packet-type disk quota system is implemented, any
further changes (like revocations!) whatsoever.

2) If max key size is not set, it is possible to add so many
signatures (or any kind of packet if there is no validation) to a
key that it becomes realistically impossible to fetch. That's the
attack I was going for initially, and was not aware about
implications outlined in 1). Performance issues of merging, and
any workarounds other than setting max key size also go in here.

So there are two fundamental issues with current design.

The first and more prominent one is
https://bitbucket.org/skskeyserver/sks-keyserver/issues/41, lack
of validation, closed as WONTFIX. That is also a critical UI flaw
that makes it easy to trick users who use HTTP interface.

The second and somewhat less critical is ability to append
packets to someone's key. It is imaginable to store signatures
with the user who has issued them, rather than with key which is
being signed. That will resolve this attack, but drastically
changes how WoT works.

To reiterate: any perceived long-term fix of this issue to the
current SKS codebase (e.g. max key size) will make it much easier
to do targeted attacks on keys, muting any future key updates for
them, which is already possible today. In my opinion, this is a
fatal flaw and the very thing that SKS design was supposed to
avoid.

> I wonder why nobody thought about this possibility before.. so
> any lasting fix besides hardcoded blacklisting?

People did think about those kinds of issues a decade ago, but
never acted upon them.
 
> It is very easy to test for vulnerabilities if you actually
> install sks on your own machine first, and try to also fix it
> before publishing/exploiting it. Many have tutorials on this
> subject and all you need is a copy of a key dump.

Not really. This particular key poison vulnerability can only be
seen if you have a testing network of at least three keyservers.

I didn't know the extent of damage my attacks will have: I was
just poking SKS for basic attack vectors that, at that time, I
was sure would have no effect at the network at large. I haven't
looked at SKS source code while testing any of the attacks
whatsoever.

I didn't even know these attacks had any pronounced long-term
effect on the network before ~3 weeks ago when I took a look at
sks-devel@ mailing list and found a huge discussion on the topic.
(I was never approached about this until recently.)

Now that I did take a look at source code, I think there might be
a way to corrupt any key (similar to
https://bitbucket.org/skskeyserver/sks-keyserver/issues/57 that
was fixed in GPG but AFAIK still not released), but point of
pursuing a tangible exploit is moot because other issues that
have been reported are comparably critical but have not been
fixed.

Historically speaking, it would seem as if benevolently attacking
the network was the most effective way to have it evolve. Say,
consider Evil 32, which was an effort that included bruteforcing
a 32-bit fingerprint lookalike to every key in trusted set
(https://evil32.com) and uploading it to keyservers. By then, the
danger of 32-bit key fingerprints was known for a long time, but
no one did anything about it.

> There are other ways of bringing an sks server down, and BDB
> might not be the best idea for a server, still the network is
> important for both free software and individuals using it.

There are likely other low-effort ways of bringing an SKS server
down :-(

You are right that SKS network is still important to a lot of
people, however I believe that this trust has been misplaced.
Hopefully these attack vectors (and potential mitigations) being
public will bring awareness to the issue and motivate someone to
create a more robust alternative to SKS, and users to prefer less
exploitable ways to share keys (or choose a different encryption
scheme entirely, say one that has forward secrecy, or pursue more
contained tools for signatures such as OpenBSD signify(1) or
minisign).

> Blockchain technology has larger issues when it comes to GDPR
> yet we don't see blockchain nodes going away for this very
> reason.

I don't think so. First, you can have a blockchain where nodes
can agree to delete data from it while retaining e.g. checksum of
the data so that future blocks are not invalidated. Second, space
on the blockchain is very scarce and thus at premium (requires
very expensive proof of work), while anyone can upload megabytes
of publicly available data to keyservers and have it mirrored by
all SKS operators worldwide.

> The SKS network is even more important after the recent privacy
> incidents that everybody knows about, and I wonder how safe is
> PGP done in javascript, or sks key generation on Raspberry PI:)
> . There were issues for ssh key pairs.

I don't think that SKS in its current state is safe to use.

> [...]
>
> The noise provided by the webcam seems to be sufficient for
> initializing /dev/random so when the webcam is covered with
> plastic foil the command is still useful, maybe at boot/reboot
> time.

I don't think any of these methods produce good entropy. You
might want to look at modular entropy multiplier based hardware
RNGs like Inifinite Noise:

https://www.crowdsupply.com/13-37/infinite-noise-trng
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Todd Fleisher
On Nov 21, 2018, at 12:59 PM, Yegor Timoshenko <[hidden email]> wrote:

Do you happen to have a long-term patch also, or just the
hardcoded poison key?

I don't, and most importantly, I don't think a long-term patch is
even possible without completely overhauling SKS.

This may be true, but regardless I think we can all agree that a complete overhaul is not something that will just happen overnight. Furthermore, the SKS network of key servers is currently the best (and maybe only) game in town for mass public distribution of GPG keys so I think I speak for many people when I say let’s try to avoid introducing any more issues that could (and in my opinion should) be handled in isolated and controlled test environments vs. the actual network.

The first and more prominent one is
https://bitbucket.org/skskeyserver/sks-keyserver/issues/41, lack
of validation, closed as WONTFIX. That is also a critical UI flaw
that makes it easy to trick users who use HTTP interface.

I agree this issue (authenticity of data found on the key servers) is one many would like to see solved, but also agree it’s not what the SKS key server pool was designed for. Maybe SKS can be adapted to solve this problem or maybe it will require a new technology. Personally, I’ve solved for this issue on the client side by automating keyring management to some extent by checking for specific authority signatures (per domain) on keys found on the SKS network and then only import those that I deem “authentic". I know Micah (who reported that issue) has done something similar with GPGSync: https://github.com/firstlookmedia/gpgsync

It is very easy to test for vulnerabilities if you actually
install sks on your own machine first, and try to also fix it
before publishing/exploiting it. Many have tutorials on this
subject and all you need is a copy of a key dump.

Not really. This particular key poison vulnerability can only be
seen if you have a testing network of at least three keyservers.

Those two sentences appear to be in opposition of each other. It would have just required more effort on the part of the tester to setup at least 3 key servers to test with. 

I didn't know the extent of damage my attacks will have: I was
just poking SKS for basic attack vectors that, at that time, I
was sure would have no effect at the network at large. I haven't
looked at SKS source code while testing any of the attacks
whatsoever.

That first sentence really irks me. I personally would appreciate future testers taking heed of a proper testing approach vs. unleashing code/data containing unknown and/or unpredictable results onto the public SKS network that many people rely on every day.

I didn't even know these attacks had any pronounced long-term
effect on the network before ~3 weeks ago when I took a look at
sks-devel@ mailing list and found a huge discussion on the topic.
(I was never approached about this until recently.)

Not to beat a dead horse, but therein lies the problem. If you didn’t know what the impact would be, I feel you should not have injected test data into the SKS network without first doing due diligence in an isolated test environment.

Historically speaking, it would seem as if benevolently attacking
the network was the most effective way to have it evolve. Say,
consider Evil 32, which was an effort that included bruteforcing
a 32-bit fingerprint lookalike to every key in trusted set
(https://evil32.com) and uploading it to keyservers. By then, the
danger of 32-bit key fingerprints was known for a long time, but
no one did anything about it.

And while that could cause problems for folks using the trusted set of GPG keys and 32-bit fingerprints … I don’t think it caused instability in the SKS network by way of increasing usage of server & network resources - neither of which are “free" for everyone - nor did it compromise nodes on the network when they crashed as a result of the bogus keys being uploaded.

There are other ways of bringing an sks server down, and BDB
might not be the best idea for a server, still the network is
important for both free software and individuals using it.

There are likely other low-effort ways of bringing an SKS server
down :-(

You are right that SKS network is still important to a lot of
people, however I believe that this trust has been misplaced.
Hopefully these attack vectors (and potential mitigations) being
public will bring awareness to the issue and motivate someone to
create a more robust alternative to SKS, and users to prefer less
exploitable ways to share keys (or choose a different encryption
scheme entirely, say one that has forward secrecy, or pursue more
contained tools for signatures such as OpenBSD signify(1) or
minisign).

I believe the importance of the SKS network to people is mutually exclusive of whether or not said people “trust” it. Like I mentioned earlier, it is of tremendous importance & value to myself and many people I communicate with … but we know the limitations and take additional measures to authenticate the data it provides. Sort of a trust, but verify model if you will. I trust it to be available world-wide for people to query and find GPG keys for the vast majority of people who are capable of receiving GPG email. I think verify the data I download from the network on the client side to make sure it’s authentic. Is it perfect? No. Do I still use it regularly despite it’s faults because it serves an important & useful purpose? Yes. Hopefully we will be able to address some of the issues being discussed, but let’s know trash what we have now because it’s not perfect.

The SKS network is even more important after the recent privacy
incidents that everybody knows about, and I wonder how safe is
PGP done in javascript, or sks key generation on Raspberry PI:)
. There were issues for ssh key pairs.

I don't think that SKS in its current state is safe to use.

Then by all means, don’t use it. Just don’t simultaneously ruin it for the rest of us who are still using it.

In closing, this isn’t meant to call out or pick on you specifically. I wanted to provide some color/context on why your responses might rub people the wrong way. Especially some of the people responsible for maintaining the SKS codebase and operating the nodes that make up the network. Your reply is acutely focussed on the shortcomings of the SKS network to the point of drawing conclusions that nobody should “trust” it (which to me reads like nobody should “use” it) and that it should be replaced with something better that addresses everyone’s concerns. But in the absence of such a replacement, many people will continue to rely on it and would appreciate if we could continue to do so until such time as something else is available.

-T

P.S. Happy Thanksgiving to those of you who celebrate it!


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Yegor Timoshenko
> This may be true, but regardless I think we can all agree that
> a complete overhaul is not something that will just happen
> overnight. Furthermore, the SKS network of key servers is
> currently the best (and maybe only) game in town for mass
> public distribution of GPG keys so I think I speak for many
> people when I say let’s try to avoid introducing any more
> issues that could (and in my opinion should) be handled in
> isolated and controlled test environments vs. the actual
> network.

This is where I think most of disagreement down the message stems
from: you want a tool for GPG key distribution, I want people to
have safe, end-to-end encrypted comms and developers to be able
to authenticate themselves. Since this ecosystem increasingly
requires wizardly skills to do either safely, regularly has
fallouts like these, and does not promptly fix critical flaws,
maybe they should pick something else.

I'm sorry that sounds so heavy-handed and inflammatory, provoking
is not my intention. I'm trying to communicate solutions that
involve different toolchain are also valid solutions.

> I agree this issue (authenticity of data found on the key
> servers) is one many would like to see solved, but also agree
> it’s not what the SKS key server pool was designed for. Maybe
> SKS can be adapted to solve this problem or maybe it will
> require a new technology. Personally, I’ve solved for this
> issue on the client side by automating keyring management to
> some extent by checking for specific authority signatures (per
> domain) on keys found on the SKS network and then only import
> those that I deem “authentic". I know Micah (who reported that
> issue) has done something similar with GPGSync:
> https://github.com/firstlookmedia/gpgsync
> <https://github.com/firstlookmedia/gpgsync>
Yeah, GPG Sync has great UI!

> Those two sentences appear to be in opposition of each other.
> It would have just required more effort on the part of the
> tester to setup at least 3 key servers to test with.

Sure. However, since this particular outcome was not intended,
there was no way I would have wanted 3 nodes if I were to set up
an isolated test environment. Realistically, I think this
particular issue would have ended up being unknown.

> That first sentence really irks me. I personally would
> appreciate future testers taking heed of a proper testing
> approach vs. unleashing code/data containing unknown and/or
> unpredictable results onto the public SKS network that many
> people rely on every day.

This could've easily ended up with some user trying to attach
several photos of themselves to their key which might've lead to
a similar result. Or a malicious entity taking down the whole SKS
network on purpose. In both cases, we would know less about the
attack vector than we do now.

This sentence is intended to emphasize how easy it is for someone
to damage the whole network, so much so that they could've done
that by accident. These were not some intricate planned attacks
which, after reading archives, seemed to be how most operators
viewed it.

> I believe the importance of the SKS network to people is
> mutually exclusive of whether or not said people “trust” it.
> Like I mentioned earlier, it is of tremendous importance &
> value to myself and many people I communicate with … but we
> know the limitations and take additional measures to
> authenticate the data it provides. Sort of a trust, but verify
> model if you will. I trust it to be available world-wide for
> people to query and find GPG keys for the vast majority of
> people who are capable of receiving GPG email. I think verify
> the data I download from the network on the client side to make
> sure it’s authentic. Is it perfect? No. Do I still use it
> regularly despite it’s faults because it serves an important &
> useful purpose? Yes. Hopefully we will be able to address some
> of the issues being discussed, but let’s know trash what we
> have now because it’s not perfect.
Much of the point I was making is that you can't trust it to be
available worldwide. Keyservers are still being presented to
users as being a good tool in a very high-threat security model:
that government can't silence you if they want to. That was never
true.

> > I don't think that SKS in its current state is safe to use.
> Then by all means, don’t use it. Just don’t simultaneously ruin
> it for the rest of us who are still using it.

I meant users, not operators :-)

I believe that the vast majority of GnuPG users are not
tech-savvy enough to be protected from non-verified packets being
displayed as trustworthy on SKS web interface. I certainly wasn't
until I read that Bitbucket issue.

I believe most won't know what to do if their key is blocked from
recon via key poisoning technique. That could easily end up being
a life-threatening situation: imagine Alice compromised her key
to Eve and wants to tell Bob about it so that he doesn't send
messages encrypted for that key. In this case, Eve can block
Alice from ever uploading a revocation certificate.

I consider this to be a way worse outcome if that happens to any
single person than if the whole SKS network goes down. There are
alternative key distribution methods and encryption tools, but
there's no going back once adversary has someone's plain text.

It's great that you understand shortcomings of SKS, but most
people don't. I think those kinds of users are the kind that
should be protected the most. I don't believe SKS does good job
at that.

Source code of everything I've found is public as per full
disclosure. I think withholding those PoCs will harm the users
that need encryption the most, by tricking them into thinking
that they are safe, which they aren't and never were.

Unfortunately, this has a side effect: anyone can take down
keyservers or individual keys with very limited knowledge and
zero resources.

I truly don't want to break SKS for you or anyone else fond of
GnuPG ecosystem, but the alternative (withholding PoC attack
source code, testing only in isolation, limited disclosure, etc.)
is exactly what has been done during the last decade, i.e.
operators and developers talked about it, no one did anything,
users were never informed about attacks.

And so we ended up with a lot of users who use SKS keyservers and
consider them to be reliable (as in availability) and trustworthy
(as in, output can be trusted).

> In closing, this isn’t meant to call out or pick on you
> specifically. I wanted to provide some color/context on why
> your responses might rub people the wrong way. Especially some
> of the people responsible for maintaining the SKS codebase and
> operating the nodes that make up the network. Your reply is
> acutely focussed on the shortcomings of the SKS network to the
> point of drawing conclusions that nobody should “trust” it
> (which to me reads like nobody should “use” it) and that it
> should be replaced with something better that addresses
> everyone’s concerns. But in the absence of such a replacement,
> many people will continue to rely on it and would appreciate if
> we could continue to do so until such time as something else is
> available.
Sure! No offense taken :-)

I understand these messages are edgy enough to guarantee me
getting flak, but I believe I wasn't communicating enough about
those issues, so I'm making up for it.
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Tobias Mueller
In reply to this post by Todd Fleisher
Hi,

On Wed, 2018-11-21 at 15:42 -0800, Todd Fleisher wrote:
> onto the public SKS network that many people rely on every day.
do we have actual numbers here?

Cheers,
  Tobi


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Alin-Adrian Anton
In reply to this post by Todd Fleisher
Hello,

On 11/22/2018 01:42 AM, Todd Fleisher wrote:
On Nov 21, 2018, at 12:59 PM, Yegor Timoshenko <[hidden email]> wrote:

Do you happen to have a long-term patch also, or just the
hardcoded poison key?

I don't, and most importantly, I don't think a long-term patch is
even possible without completely overhauling SKS.

This may be true, but regardless I think we can all agree that a complete overhaul is not something that will just happen overnight. Furthermore, the SKS network of key servers is currently the best (and maybe only) game in town for mass public distribution of GPG keys so I think I speak for many people when I say let’s try to avoid introducing any more issues that could (and in my opinion should) be handled in isolated and controlled test environments vs. the actual network.

I agree with Todd here.


The first and more prominent one is
https://bitbucket.org/skskeyserver/sks-keyserver/issues/41, lack
of validation, closed as WONTFIX. That is also a critical UI flaw
that makes it easy to trick users who use HTTP interface.

I agree this issue (authenticity of data found on the key servers) is one many would like to see solved, but also agree it’s not what the SKS key server pool was designed for. Maybe SKS can be adapted to solve this problem or maybe it will require a new technology. Personally, I’ve solved for this issue on the client side by automating keyring management to some extent by checking for specific authority signatures (per domain) on keys found on the SKS network and then only import those that I deem “authentic". I know Micah (who reported that issue) has done something similar with GPGSync: https://github.com/firstlookmedia/gpgsync

It is very easy to test for vulnerabilities if you actually
install sks on your own machine first, and try to also fix it
before publishing/exploiting it. Many have tutorials on this
subject and all you need is a copy of a key dump.

Not really. This particular key poison vulnerability can only be
seen if you have a testing network of at least three keyservers.

Those two sentences appear to be in opposition of each other. It would have just required more effort on the part of the tester to setup at least 3 key servers to test with.

I think setting up 3 SKS key servers on computers @ home / virtual appliances for the purpose of testing the vulnerability is not much. Unless, the main goal of the poison key was not to test a virtual network, but to damage the real one. It is similar to hammering a window on the street just because there will be no unpleasant consequences and you feel that it is right to do so.  The constructive comments are appreciated, though, and also your support for free software.

Anyway, Yegor, think of somebody uploading a PLEASE_READ_THIS.TXT file on your website by injecting some code into a web application saying "This website has a vulnerabilty.. CVE... Disclaimer.." . It is much better than defacing it and replacing the main page with random data or who knows what.


I didn't know the extent of damage my attacks will have: I was
just poking SKS for basic attack vectors that, at that time, I
was sure would have no effect at the network at large. I haven't
looked at SKS source code while testing any of the attacks
whatsoever.

That first sentence really irks me. I personally would appreciate future testers taking heed of a proper testing approach vs. unleashing code/data containing unknown and/or unpredictable results onto the public SKS network that many people rely on every day.

If one does not trust the web of trust, by all means, one doesn't have to. One way of distributing your PGP key is via DNS:

"An OpenPGP DANE DNS record allows other users to download and validate your public OpenPGP key from your domain’s DNS server. In conjunction with DNSSEC this allows the users to know with a increased level of confidence that the key retrieved is the same public key that you published without modification."

from

https://www.keyserver.mattrude.com/guides/dns-dane-cert-records/

Maybe services like DynamicDNS / noip will support this at some point (https://en.wikipedia.org/wiki/Dynamic_DNS)


I didn't even know these attacks had any pronounced long-term
effect on the network before ~3 weeks ago when I took a look at
sks-devel@ mailing list and found a huge discussion on the topic.
(I was never approached about this until recently.)

Not to beat a dead horse, but therein lies the problem. If you didn’t know what the impact would be, I feel you should not have injected test data into the SKS network without first doing due diligence in an isolated test environment.

Well.. Todd.. if you read https://medium.com/@mdrahony/are-sks-keyservers-safe-do-we-need-them-7056b495101c it will make it all clear.


Historically speaking, it would seem as if benevolently attacking
the network was the most effective way to have it evolve. Say,
consider Evil 32, which was an effort that included bruteforcing
a 32-bit fingerprint lookalike to every key in trusted set
(https://evil32.com) and uploading it to keyservers. By then, the
danger of 32-bit key fingerprints was known for a long time, but
no one did anything about it.

I think that was different, Yegor:

"Someone downloaded our copy of the strong set and uploaded all of the keys to the SKS keyserver network. :( While we took on this project to help prompt GPG to build a more secure ecosystem, this mass clone made the keyservers harder for everyone to use. Of course anyone could use our tools to regenerate their own strong set clone and do this again, but we'd rather our keys not be used that way." (https://evil32.com)

If you actually know that it takes 3 SKS setups in order to test the vulnerability, it really shows that you are aware what the outcome could be when injecting the key into the public network supported by volunteers. That is not called "testing", it is explained as a deliberate attack on:

https://medium.com/@mdrahony/are-sks-keyservers-safe-do-we-need-them-7056b495101c  (same link as above)

nothing less.

And while that could cause problems for folks using the trusted set of GPG keys and 32-bit fingerprints … I don’t think it caused instability in the SKS network by way of increasing usage of server & network resources - neither of which are “free" for everyone - nor did it compromise nodes on the network when they crashed as a result of the bogus keys being uploaded.

There are other ways of bringing an sks server down, and BDB
might not be the best idea for a server, still the network is
important for both free software and individuals using it.

There are likely other low-effort ways of bringing an SKS server
down :-(

You are right that SKS network is still important to a lot of
people, however I believe that this trust has been misplaced.
Hopefully these attack vectors (and potential mitigations) being
public will bring awareness to the issue and motivate someone to
create a more robust alternative to SKS, and users to prefer less
exploitable ways to share keys (or choose a different encryption
scheme entirely, say one that has forward secrecy, or pursue more
contained tools for signatures such as OpenBSD signify(1) or
minisign).

Encryption is not yet ready for the masses. I may be wrong, but I do not know if there is any way of setting up a private Signal (signal.org) server for conferencing with family members. I know the client is freely available, but what about the server side? Signal is mentioned in the medium.com article.

Yegor, will you try something similar on the fediverse? https://mastodon.social/@yegortimoshenko

I think Facebook has more data on you than any of the SKS servers combined, not to mention Google. It is more efficient to actually poison their network first, to show that their business model is flawed/unethical by design. It would make more sense, but it would still be unethical and perhaps illegal to do so.


I believe the importance of the SKS network to people is mutually exclusive of whether or not said people “trust” it. Like I mentioned earlier, it is of tremendous importance & value to myself and many people I communicate with … but we know the limitations and take additional measures to authenticate the data it provides. Sort of a trust, but verify model if you will. I trust it to be available world-wide for people to query and find GPG keys for the vast majority of people who are capable of receiving GPG email. I think verify the data I download from the network on the client side to make sure it’s authentic. Is it perfect? No. Do I still use it regularly despite it’s faults because it serves an important & useful purpose? Yes. Hopefully we will be able to address some of the issues being discussed, but let’s know trash what we have now because it’s not perfect.

The SKS network is even more important after the recent privacy
incidents that everybody knows about, and I wonder how safe is
PGP done in javascript, or sks key generation on Raspberry PI:)
. There were issues for ssh key pairs.

I don't think that SKS in its current state is safe to use.

Then by all means, don’t use it. Just don’t simultaneously ruin it for the rest of us who are still using it.

In closing, this isn’t meant to call out or pick on you specifically. I wanted to provide some color/context on why your responses might rub people the wrong way. Especially some of the people responsible for maintaining the SKS codebase and operating the nodes that make up the network. Your reply is acutely focussed on the shortcomings of the SKS network to the point of drawing conclusions that nobody should “trust” it (which to me reads like nobody should “use” it) and that it should be replaced with something better that addresses everyone’s concerns. But in the absence of such a replacement, many people will continue to rely on it and would appreciate if we could continue to do so until such time as something else is available.

-T

P.S. Happy Thanksgiving to those of you who celebrate it!


In closure, please don't read this response as unfriendly or as criticizing, Yegor; your constructive comments are appreciated, however, the attack on the network is not, and later on you will probably agree it was unethical and it would have been a better idea to write a thorough paper on the subject after thoroughly testing it @ home.

I had to move from a VPS on a dedicated machine, which was meant for Mastodon (glad you are using the software), and it was partly because of the poison key. Thanks for pinpointing the blacklisting patch, I'll have to use it.

Best wishes,

-- 
Sl.univ.dr.ing. Alin-Adrian Anton
Politehnica University of Timisoara 
Department of Computer and Information Technology
2nd Vasile Parvan Ave., 300223 Timisoara, Timis, Romania


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: sks.daylightpirates.org is staying...again

Todd Fleisher
In reply to this post by Tobias Mueller
> On Nov 22, 2018, at 2:56 AM, Tobias Mueller <[hidden email]> wrote:
>
> Hi,
>
> On Wed, 2018-11-21 at 15:42 -0800, Todd Fleisher wrote:
>> onto the public SKS network that many people rely on every day.
> do we have actual numbers here?

An organization I work with has 600+ public keys published to the key servers. My total public key count is over 1000 and almost all of them were downloaded from the SKS network of key servers.

-T

> Cheers,
>  Tobi


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment