Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SKS Keyserver Network Under Attack

gist.github.com

Post reply on HN
Print view View original

141–150 of 197 posts

Re: SKS Keyserver Network Under Attack

#141

Post by rmrfrmrf »

tptacek wrote: post #106
danShumway wrote: post #104

Earlier quoted context omitted.

This is my reaction as well. This seems bad, but... what should I do? What's the alternative? I've seen multiple people say that PGP in general is kind of bad and it would be easy for the tech industry to write a secure alternative if it really wanted to. Cool, but that's not useful right now to ordinary people like me who aren't crypto experts who are trying to decide how we should sign/encrypt messages. I have no i…

To send messages, use a secure messenger, like Signal or Wire. Don't use PGP.

Proprietary messengers are never secure.

Re: SKS Keyserver Network Under Attack

#142

Post by danShumway »

lifeisstillgood wrote: post #138

My attempt to understand this - please correct liberally Things I know today that I did not know yesterday - The GnuPG (GPG) ecosystem seems to suffer from pre-heart bleed-OpenSSL levels of not enough investment and people - The GPG ecosystem has a trivial DOS attack that can be mounted against it, with bad actors able to append thousands of keys to any users "account" effectively making it impossible to read that ac…

This roughly aligns with my understanding as well. The additional takeaways I'd add (that may or may not be accurate):

- Many security researchers disagree with the core idea of SKS servers in general (they're essentially just undeletable online storage that anyone can write to). The distributed "Web of Trust" model itself is considered untrustworthy.

- The vulnerability is triggered by the usage of the SKS servers. This is very bad for any piece of infrastructure that relies on them, but if you're only using local keys that you imported and verified yourself, this particular attack doesn't effect you.

- The PGP format itself is cumbersome and has problems (people want shorter keys, and they want a simpler format with less variability). So while this particular vulnerability only effects SKS servers, there's still a strong movement to get rid of PGP in its entirety.

- The fact that the people behind the SKS servers are reacting negatively and angrily may be reason to be worried about GPG in general, since we don't know if the maintainers would respond the same way to other vulnerabilities that aren't restricted to SKS servers.

Similarly, thoughts or corrections welcome.

Re: SKS Keyserver Network Under Attack

#143

Post by steveklabnik »

jlgaddis wrote: post #23
paulfurley wrote: post #19

Earlier quoted context omitted.

I know the folks behind this and I think they’ve approached it thoughtfully and realistically. It’s using a modern OpenPGP implementation and language (Sequoia, Rust) which is a big win. Despite it being centralised, I’d encourage folks to have a look. On that issue, SKS has become so troublesome to run that the number of peers has steadily decreased to the point where there are only 2 entities running the HKPS (“sec…

Out of curiosity, which is more obscure: OCaml or Rust?

Fun fact: Rust’s initial implementation was in OCaml.

Re: SKS Keyserver Network Under Attack

#144

Post by maddyboo »

viraptor wrote: post #128
CameronNemo wrote: post #105

Earlier quoted context omitted.

Not sure how you could fix an OpenPGP client for this case without changing how the keyservers function.

"You're trying to pull more than reasonably supported 1k signatures. Do you want to skip this step?"

This will protect your machine from being DoS’d, but what if your key is poisoned? Nobody will be able to use it.

Re: SKS Keyserver Network Under Attack

#145

Post by viraptor »

diafygi wrote: post #84
giomasce wrote: post #79

Earlier quoted context omitted.

I don't think that the base issue lies in the implementation: you can make it as scalable, parallel and document as you wish, but if what you are doing is basically receive data from whoever sends you something, store it, pass it to other server and do not offer any form of accountability over who can store such data or who can delete it, it will always be trivial to write a script that just sends lots of data and bl…

Hmmmm, isn't that an inherent property of any for-public-use database? By your definition, any public pki (keybase.io, keys.openpgp.org, etc.), social network (Twitter, Facebook, Mastodon, etc.), and more are vulnerable to someone just writing a script and bloating their database. What mitigation strategies do other ecosystems use? Why can't they be tried in the keyserver pool?

They certainly are vulnerable. The solutions for social networks are in client/behaviour analysis: Are you trying to create 10th account from the same IP? Are you creating multiple accounts with the same browser fingerprint? Have you got any personal details attached? (That's one reason they started pushing phone verification) Is the action automated? (CAPTCHA) Is your friend graph a clique of fresh accounts?

A lot of these can't be applied to SKS unfortunately.

Re: SKS Keyserver Network Under Attack

#146

Post by rphlx »

diafygi wrote: post #84
giomasce wrote: post #79

Earlier quoted context omitted.

I don't think that the base issue lies in the implementation: you can make it as scalable, parallel and document as you wish, but if what you are doing is basically receive data from whoever sends you something, store it, pass it to other server and do not offer any form of accountability over who can store such data or who can delete it, it will always be trivial to write a script that just sends lots of data and bl…

Hmmmm, isn't that an inherent property of any for-public-use database? By your definition, any public pki (keybase.io, keys.openpgp.org, etc.), social network (Twitter, Facebook, Mastodon, etc.), and more are vulnerable to someone just writing a script and bloating their database. What mitigation strategies do other ecosystems use? Why can't they be tried in the keyserver pool?

This is not a complete, imperfect, optimal, uncontroversial or always-trivial-to-implement list, but some common ways to increase attacker costs are to:

0. Put a CAPTCHA on expensive/abused functionality.

1. Rate-limit costly transactions to 1 per hour/day/etc (whatever's appropriate) per IPv4 address.

2. Limit total amount of data added to the db per time period per IPv4 address.

3. Iff you get a lot of abuse from VPS/cloud providers, block or even-more-severely-limit their published IPv4 ranges. Generally speaking a normal user will not write to a pubkey db from a cloud IP.

4. Iff you get a lot of IPv6 abuse, either go IPv4-only (no doubt this will make some people super-mad.. but when it's the only way to keep the service operational..). Sometimes treating every /64 as roughly equal to one IPv4 address is a sufficient defense.

5. If you don't like using IPv4 as the scarce good, then use some other primitive such as SMS verification of a phone number (that may be unacceptable for sks due to obvious privacy and highjacking concerns.. but it's basically what Signal does..)

6. Users (and environmentalists) will hate it, but if all else fails, require proof-of-work/hashcash. Periodically expire keys that didn't submit a $1-10 POW ticket each year, etc. Or an equivalent minable cryptocurrency payment.

Re: SKS Keyserver Network Under Attack

#148

Post by nh2 »

tptacek wrote: post #106
danShumway wrote: post #104

Earlier quoted context omitted.

This is my reaction as well. This seems bad, but... what should I do? What's the alternative? I've seen multiple people say that PGP in general is kind of bad and it would be easy for the tech industry to write a secure alternative if it really wanted to. Cool, but that's not useful right now to ordinary people like me who aren't crypto experts who are trying to decide how we should sign/encrypt messages. I have no i…

To send messages, use a secure messenger, like Signal or Wire. Don't use PGP.

@tptacek

I have seen various endorsements of Signal from you, Bruce Schneier, Edward Snowden and so on.

I am honestly curious about how this aligns with the fact that Signal

* has no tests [1],

* has no CI [2].

How can the security of a software like Signal be asserted so thoroughly when on the engineering side, basic best practices are not followed and there is no automation that ensures that the important code paths work as expected?

Many Signal features like voice calls, video calls, reliable message delivery, or running-wihtout-crash, break regularly in daily use and with new updates. They have bugs.

What gives us (or you) confidence that the safety-critical aspects of Signal are magically exempt from such frequent bugs?

This is a serious question that concerns me.

Thanks!

(8-years Signal user with upstreamed patches.)

[1] There is a "test" directory, but it is negligible: 900 lines of actual test code in Signal-Android, vs >100k lines Java app source code.

[2] At least I could not find any; tests on `master` did not even compile; see https://github.com/signalapp/Signal-Android/issues/7458#issu...

Re: SKS Keyserver Network Under Attack

#149

Post by yegortimoshenko »

tptacek wrote: post #76

I'd like to gingerly suggest that this is not the way a project that has deliberately set as its adversaries hostile world governments should respond to a trivial, predictable† vandalism attack. Rather, if they're serious about what they're doing – Hansen, in a related document, talks about the "good advice" he gave to dissidents in Venezuela about using GnuPG – they should thank whoever did this. This attack apparen…

Can confirm, I've reported a similar attack [1], along with a few other vulnerabilities, and also published exploit tools. I ended up getting legal threats from two people that I see frequently posting to sks-devel@ mailing list.

Additionally, Robert (GnuPG maintainer who wrote this Gist) has attacked [2] another person who wrote a proof-of-concept filesystem on top of SKS that was intended to highlight how broken the design is.

I have not seen a single open source community that would treat full disclosure with such contempt.

At this point SKS network continues to run exclusively on community goodwill. This attack seems to be specifically targeted on GnuPG maintainers, if attacker were to deliberately try to break SKS, they would target someone like Linus Torvalds.

Alternatively, there are other published vulnerabilities with exploits that allow to take the whole SKS network down within half an hour, which were published more than a year ago. And yet, those have not been used, so far.

[1]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/57

[2]: https://twitter.com/robertjhansen/status/1017863443356020738

Re: SKS Keyserver Network Under Attack

#150

Post by diafygi »

tedunangst wrote: post #108
diafygi wrote: post #101

Earlier quoted context omitted.

> The fact that it is simultaneously a "hobby" and an "attempt to help activists communicate securely" is emblematic of the whole problem here. Isn't that the way it usually gets done for most non-profit altruistic efforts, though? If I'm a church and run a soup kitchen for the homeless, the volunteers who come in an prepare meals and serve patrons are probably not going to be trained professional chefs. They are goi…

Soup kitchens rarely position themselves as being secure against CIA poisoning attacks.

Can you please explain a bit more about these CIA poisoning attacks? As far as I know, the vulnerability here is just flooding keys with spam signatures so much that the public keys crash sks keyservers and gpg when downloaded. That seems like just a basic DoS attack. Where is the CIA poisoning?
Post reply on HN