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

121–130 of 197 posts

Re: SKS Keyserver Network Under Attack

#121

Post by ethbro »

tptacek wrote: post #103
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…

This is the difference between a soup kitchen and a neurosurgery clinic.

I believe an apt analogy might be "the lack of a neurosurgery clinic is not a reason to avoid building a health clinic."

Re: SKS Keyserver Network Under Attack

#122

Post by Arathorn »

tptacek wrote: post #52
cyphar wrote: post #18

Earlier quoted context omitted.

> What alternate projects are people excited about that are solving the problem of distributed cryptographic identity and messaging? I would argue Matrix is a good contender. The Matrix project is working on secure messaging, and they have a lot of really cool solutions for key distribution and federated communication. "Distributed cryptographic identity" is a slightly hard concept to pin down. In Matrix this is stil…

The best replacement to PGP would be a messaging network with opt-in, poorly supported encryption? https://www.reddit.com/r/privacy/comments/9avyen/sad_state_o... I don't know what it is with people and Matrix. It seems like a good project, hamstrung by its overzealous cheering section.

(Matrix project lead here.) The linked reddit post is 10 months old, and even then was riddled with bugs (it ignored or declared 'unclear' for some of clients which had E2E, and included loads of random alpha ones to make the situation seem way worse than it was). The topmost reply on that post tried to correct it at the time, but seems like people don't read the replies.

The current situation is that the following clients in Matrix have full E2E support:

* Riot/Web (JS) (aka Riot/Desktop)

* Riot/iOS (ObjC)

* Riot/Android (Java)

* RiotX/Android (Kotlin)

* Weechat (Python)

* Pantalaimon (Python)

* Seaglass (ObjC on macOS)

* Nheko (Qt) (other than file transfer)

Meanwhile, Quaternion (Qt) is currently getting support via GSoC 2019, and the purple-matrix plugin has working (albeit read-only) E2E support. I believe Pattle (pattle.im) is working on E2EE too. And the matrix-python-sdk (not an app) got support via GSoC 2018.

It's true that there are over 100 other Matrix clients out there which don't speak E2EE natively, but that's because "a matrix client" can be as simple as a curl one-liner, and so there are tonnes of experimental and toy and alpha ones as well as the more mature ones which you could use to pad out a list to make native E2EE support look bad.

However, and most importantly, Pantalaimon (https://github.com/matrix-org/pantalaimon) makes any Matrix client (including all the ones in that FUDdy Reddit post) speak full E2EE - by running as a clientside daemon which acts as a friendly MITM for your Matrix traffic and offloads all the hard E2E encryption (and E2E indexing and search, and in future multiplexing multiple local Matrix apps onto one connection to your server - thus acting almost as a general comms daemon which can even be used as a self-sovereign encrypted push service).

That said, I agree that sometimes the enthusiasm of the Matrix community can be overzealous. For instance, there are some bits which we haven't solved yet, for instance:

* Cross-signing keys for one-hop web-of-trust is 1-2 weeks away from landing. It's implemented in Synapse and matrix-js-sdk, but we're in the middle of adding it into the UI for Riot/Web currently. You can see demos at the SDK level at https://matrix.org/blog/2019/06/14/this-week-in-matrix-2019-... if interested. We also need to figure out how to use cross-signing for limited transitive web-of-trust (e.g. within an closed organisation where WOT metadata leakage isn't a concern)

* We don't turn on E2E by default yet for private chats. This is because we want cross-signing to land first, for usability, and also because we don't want to lock out non-E2E-capable clients, and pantalaimon is only a few weeks old. We also want to better solve e2e-search first (by taking the tantivy-powered FTS indexer from pantalaimon and putting it into Riot). Also, we are still chasing down a few edge cases where session keys aren't available - see https://www.youtube.com/watch?v=WgikPxIjsWE for our approach to that, and https://github.com/vector-im/riot-web/issues/6779 for the overall bug.

* We don't have any equivalent of key-servers at all yet.

So yeah, we definitely don't claim to be perfect, but please don't disregard our progress thanks to a confused/malicious Reddit article.

Re: SKS Keyserver Network Under Attack

#123

Post by roywiggins »

alasdair_ wrote: post #118
Forbo wrote: post #61

Earlier quoted context omitted.

This seems a bit "shoot the messenger" to me. If anything I think those efforts should be applauded as the signal flares they are: "this is broken and it's only a matter of time until it has real world consequences".

Seriously. The original post states at least three times they knew about the issue for over a decade. At what point does "full disclosure" become valid if not after over a decade of warning?

The fact that the chosen keys in this attack were not Mozilla or whoever and instead maintainers suggests to me that this "attack" is someone who, having seen this vulnerability left unresolved for a decade, decided to force the issue before someone used it for really nefarious purposes.

It's a black hat solution and not a nice thing to do at all. It's probably the wrong thing to do. But, is this really worse than waiting for someone to use this in earnest? I'm not sure.

Re: SKS Keyserver Network Under Attack

#124

Post by Arathorn »

tptacek wrote: post #62
cyphar wrote: post #58

Earlier quoted context omitted.

> opt-in Device cross-signing (from my understanding, the last must-have feature before e2ee is considered ready to be the default) is very close to being merged now that Matrix 1.0 is out. Yes, it took several years to get there, but I think its fair to say that the e2ee design now looks much better than anything else available (and had to solve many more technical problems than [for instance] Signal, due to the nee…

"All newer clients either do or will support e2ee" is my favorite thing I've ever heard someone say about Matrix.

well, it's true - if you run a daemon like pantalaimon, even one-liner Matrix requests via curl can speak full E2EE. So arguably the older clients now support E2EE too :)

Re: SKS Keyserver Network Under Attack

#125

Post by rlpb »

sirn wrote: post #15
hlieberman wrote: post #11

Earlier quoted context omitted.

I don't think this is correct. Debian and its derivatives, at least, use a separate keyring for apt than the rest of the system uses. Though Debian does have a keyserver, pushes aren't automatically added to the user-facing keyring; they are manually moved over by a keyring maintainer who would presumably notice someone with a multi-megabyte key.

Ubuntu runs its own SKS keyserver (keyserver.ubuntu.com) and apk-add-repository use it when adding a PPA repository. I think in theory it's still possible to break package manager in Ubuntu if someone decide to poison a popular PPA repository/key.

PPA repository keys are generated by Launchpad; mere Launchpad users cannot inject arbitrary PPA repository keys.

Re: SKS Keyserver Network Under Attack

#126

Post by literallycancer »

paulddraper wrote: post #114

> unusual programming language called OCaml > obscure programming languages Huh, I knew OCaml was less popular; I did not know it was "obscue". Doesn't Facebook use OCaml?

There's at most hundreds of people writing OCaml for non-academic purposes at least once a week.

Re: SKS Keyserver Network Under Attack

#127

Post by Havoc »

>unlikely to be discovered until it breaks an OpenPGP installation.

Why can’t you just brute force this? ie rest all of them vs a pgp install and see which keys break it.

At least you can quantify and pinpoint the poisoned ones then

Re: SKS Keyserver Network Under Attack

#128

Post by viraptor »

CameronNemo wrote: post #105
ComodoHacker wrote: post #65

>Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt. So the SKS software is only a part of the problem. Another part is GnuPG, which is unable to deal with a public key with many signatures attached. GnuPG is written in C (not OCaml) and seems to be well maintained. Looks like fixing it can be an effective mitigation against this attack. Or do I miss something?

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?"

Re: SKS Keyserver Network Under Attack

#129

Post by lifeisstillgood »

tptacek wrote: post #117
danShumway wrote: post #113

Earlier quoted context omitted.

This is not a realistic solution. SMS-sized messages are the least hard part of this for me. What I want is to be able to point at a file or folder on my computer and say, "sign that with a public key so I can prove I wrote it" or "encrypt that with someone else's public key so only they can read it". At that point, I don't necessary care all that much about how the file gets sent over the network. It doesn't need to…

You asked (among other things) how to send messages securely without PGP. Don't use PGP to send secure messages; use a secure messenger, like Signal or Wire. Someone else asked how to email securely without PGP. Email isn't secure with PGP. Don't use PGP to send encrypt emails, and don't use email to send secure messages; use a secure messenger, like Signal or Wire. I acknowledge there are use cases not well covered…

I am not disagreeing with any particular technical point here, but I am struck reading the thread that there are two sides of a debate - one that is "Gosh GPG has had a fundamental problem for a decade and its terrible we as the internet have not solved it and now the bill comes due" and the other side is "Where the hell did that come from"

I am on the WTF side - GPG is synonymous in my mind with Public / Private keypairs and now this needs re-evaluating.

Tl;dr I need more context before I can understand the blast radius before I can evaluate the solutions

Some of us have a lot of running to do to catch up

Re: SKS Keyserver Network Under Attack

#130

Post by literallycancer »

xvilka wrote: post #13
Shoop wrote: post #5

> It's written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that's deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obs…

Yes, the code looks fairly simple, I would say.

It looks like other OCaml code bases. Hardly a good thing.
Post reply on HN