News for hackers. Stuff that matters.

A comment on SKS Keyserver Network Under Attack.

Re:SKS Keyserver Network Under Attack by diafygi on Saturday June 29, 2019 @01:33PM (#20313734)
I have maintained keyserver in the pool for many years[1], and attacks like this are, in theory, able to be easily mitigated. I mean, we're only talking about appending spam to public keys. It's not like the attackers found some flaw in OpenPGP that breaks public keys or valid signatures. In theory, all these attacks to do is cause bloat on keyservers.

So why can't we deal with these types of attacks? IMO, the main reason is the the server code.

The author mentions that the sks keyserver is "written in an unusual programming language called OCaml", but IMO the language isn't the main issue. Here's a rundown of what I think the main issues are:

* Non-scalable database - SKS keyserver uses Berkeley DB as the database for storing keys, and bdb can't handle more than one connection at time. So, when huge keys with lots of spam signatures are being written to the database, it blocks all other transactions, including serving web requests (see issue #61[2]). The server needs to be re-written to use a database that can handle multiple connections (e.g. Postgres) so spam writes won't affect the web responses for unrelated keys. Unfortunately, the server is currently single-threaded and synchronous so it would have to be heavily re-written to add this kind of async scalability.

* Undocumented gossip protocol - The gossip protocol used is a very efficiency syncing algorithm that lets servers fill in the gaps for their databases from other servers. Unfortunately, the only documentation I can find on the gossip protocol is an academic paper[3]. This is a huge barrier for someone wanting to write a sks-compatible keyserver. You basically have to read the OCaml code (which doesn't have comments) to figure out how it works. For years I have wanted to try to write an alternative sks-compatible keyserver that could handle attacks like these better, but as it stands now, I'd have to spend a huge amount of time learning OCaml and reverse engineering the code just to understand how to write a compatible gossip implementation. Every once in a while I ask the mailing list for a mentor in helping teach me the gossip protocol[4], but so far either no one knows it or wants to teach it to me.

* Few validation and revocation features - OpenPGP is very flexible for how you can build public keys and signatures. I think there's a lot of creative things you can do with signature packets to let keyservers and public key owners clean spam out of their signatures. For example, OpenPGP signatures let you specify a "Signature Target"[5] in a signature, which could be used to let public key owners denote other signatures on their public key they wish to revoke, which the keyserver could then stop serving up to public requests. However, since the current server code is largely unmaintained, we can't implement some of these cleanup options.

Overall, I really love the idea of having a public, open, decentralized keyserver pool. Unfortunately, sks-keyserver wasn't written with much ability to scale (which was totally appropriate at the time), so it's in desperate need of being re-written. I'd love to do it, but simply haven't found the time to reverse engineer the gossip protocol. If someone out there wants to mentor me through it, I'd happily write an sks-compatible keyserver that could operate in the pool and also deal with these types of attacks.

[1]: https://sks.daylightpirates.org/ (currently down)

[2]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/k...

[3]: http://ipsit.bu.edu/documents/ieee-it3-web.pdf

[4]: https://lists.nongnu.org/archive/html/sks-devel/2016-08/msg0...

[5]: https://tools.ietf.org/html/rfc4880#section-5.2.3.25

[ Parent | on HN ]
Re:SKS Keyserver Network Under Attack by giomasce on Saturday June 29, 2019 @03:15PM (#20314225)
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 bloats your service. The problem lies in the architecture itself.
[ Parent | on HN ]
Re:SKS Keyserver Network Under Attack by diafygi on Saturday June 29, 2019 @03:36PM (#20314341)
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?

[ Parent | on HN ]
Re:SKS Keyserver Network Under Attack by rphlx on Saturday June 29, 2019 @08:03PM (#20315605)
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.

[ Parent | on HN ]
Re:SKS Keyserver Network Under Attack by viraptor on Saturday June 29, 2019 @07:53PM (#20315573)
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.

[ Parent | on HN ]
Re:SKS Keyserver Network Under Attack by thejohnstone on Sunday June 30, 2019 @03:28PM (#20319976)
You should create multiple account with different browser fingerprint for each account. I usually use Kameleo software to load different profiles with manipulated browser fingerprint https://support.kameleo.io/article/what-is-browser-fingerpri...
[ Parent | on HN ]