Hello,
On 11/22/2018 01:42 AM, Todd Fleisher
wrote:
On Nov 21, 2018, at 12:59 PM, Yegor Timoshenko
< address@hidden>
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.
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
|