16 ms·

SKS Keyserver Network Under Attack

379 points by Spellman 7y ago

Havoc 7y ago
>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
amenghra 7y ago
SKS don’t implement any modern web security features (the whole thing does pre-date the web!) — as a result, you can (ab)use SKS as a free backend store for your JavaScript apps: https://www.quaxio.com/message_board_over_pgp_key_servers.html https://www.quaxio.com/message_board_over_pgp_key_servers.ht...
rasengan 7y ago
I think that decentralized services, like SKS, require a sort of fee mechanism (proof of effort, currency, or otherwise) that can prevent bad actors from inserting malicious material. I definitely think this is one of the cases that blockchain technology makes a lot of sense, and the disincentive of a fee would do very will to mitigate this.
- JoachimSchipper 7y ago
  How would a proof-of-work system, let alone a blockchain, work? Apparently, GnuPG breaks badly at 150 000 signatures. You want adding a signature to be doable on a really old laptop and/or low-end Android phone; a motivated attacker can just choose to expand 1000 000 times as much effort as a not-too-interested user on antiquated hardware. Of course you can make adding a signature more expensive the more signatures are already there, but that lets a motivated attacker make it impossible to vouch for certain users (keys.) Etc.
libeclipse 7y ago
The new keys.openpgp.org service is a mitigation: > keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence.
- paulfurley 7y ago
  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 (“secure”) pool, so in reality SKS is centralised too, as well as unmaintained. Source: I run a key server and a key expiry reminder service.
  - jlgaddis 7y ago
    Out of curiosity, which is more obscure: OCaml or Rust?
    - kchamplewski 7y ago
      Probably OCaml. While it's been around much longer, it's never really reached mass acceptance (though does get used here and there). Rust is newer but I'd estimate it's already more used, and its adoption in industry is growing quite quickly. This is probably to do with the fact that OCaml doesn't necessarily solve any problems that are apparent to businesses, whereas Rust solves the very apparent "manual memory management makes massive vulns trivial" problem. I'm not sure which language is actually more approachable for someone trying to learn it from scratch though.
      - AnaniasAnanas 7y ago
        OCaml is very popular in academia though, especially in the field of theoretical computer science and formal verification. Coq, Frama-C, Flow, CompCert, etc are all written in OCaml. Heck, if you are running a graphical GNU distribution chances are that you have installed FFTW, which is written in OCaml. The "industry" is not the only thing that matters when considering the adoption of a language.
        ghuntley 7y ago
Shoop 7y ago
> 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 obscure programming languages and strange programming customs. Looking at the code [0], it looks like fairly standard Ocaml. Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)? (It looks like the original author of the SKS Keyserver is Yaron Minsky, the guy who convinced Jane Street to use Ocaml.) [0] https://bitbucket.org/skskeyserver/sks-keyserver/src/default/ https://bitbucket.org/skskeyserver/sks-keyserver/src/default...
- xvilka 7y ago
  Yes, the code looks fairly simple, I would say.
  - ghuntley 7y ago
    Looks like fairly standard OCaml and usage of functional programming idioms. Q: Where's the CI and property tests? If you feel uncomfortable maintaining the code base, start there.
    - ghuntley 7y ago
      The author of the gist has his CV on his personal website and lists himself proficient in fsharp. :confused:
      - gravitas 7y ago
        https://rationalwiki.org/wiki/Argumentum_ad_hominem https://rationalwiki.org/wiki/Argumentum_ad_hominem
        cbsmith 7y ago
vermilingua 7y ago
To be clear: is this suggesting that it is currently entirely unsafe to update any operation-critical equipment? It seems that now that the PoC is out in the wild, it will be a matter of days/hours before someone hits a major contributor to the major Linux distros; and all package managers begin to fail.
- koolba 7y ago
  Yes this seems like it's going to range from very bad to outright terrible. In particular if the issue propagates prior to patching something like gpg as the package managers would be locked out from updates. Every time there's an article about IoT security there's a discussion about lack of (security) updates and an upcoming Armageddon. Interestingly it'll be those devices that do not update that are immune to this type of thing.
  - cyphar 7y ago
    Package managers don't use keyservers to get their keys (at least, not for the distro's repos). I believe Ubuntu might use them for PPAs, but openSUSE doesn't use them for any OBS projects (and I'm pretty sure this is the same for any RPM repo).
  - heavenlyblue 7y ago
    >> immune to this type of thing. The _only_ type of thing that they are immune to. This is like saying “a car with a broken engine is the safest car in the world - it never moves!”.
    - majewsky 7y ago
      I think the standard analogy for this sort of thing is "a broken clock shows the right time twice a day".
- hlieberman 7y ago
  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.
jeffrallen 7y ago
This is why we can't have nice things.
JoachimSchipper 7y ago
It's always sad to see someone taking down a project that is run with the best intentions. However, it may be time to move away from the entire PGP ecosystem. Consider the post's "We've known for a decade this attack is possible. It's now here and it's devastating.". Consider also the final section, "PGP is bad technology and it’s making a bad community", of https://blog.cryptographyengineering.com/2018/05/17/was-the-efail-disclosure-horribly-screwed-up/ https://blog.cryptographyengineering.com/2018/05/17/was-the-... (by noted cryptographer Matthew Green.) My sympathies to the victims of this attack. [EDIT: reworked slightly at 7m to try to be as kind as possible]
- clarkmoody 7y ago
  The idea of Internet actors (human or machine) owning cryptographic identities in a distributed system is a good one. I don't think we should stray from this approach. From your Matthew Green link: > If PGP went away, I estimate it would take the security community less than a year to entirely replace (the key bits of) the standard with something much better and modern. It would have modern crypto and authentication, and maybe even extensions for future post-quantum future security. It would be simple. Many bright new people would get involved to help write the inevitable Rust, Go and Javascript clients and libraries. Those word were written a little more than a year ago. What if right now is the time to assume that PGP has gone away and start building the next thing? What alternate projects are people excited about that are solving the problem of distributed cryptographic identity and messaging?
  - cyphar 7y ago
    > 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 still an open problem, but that's just for the service which links third-party IDs (phone numbers, email addresses, etc) to Matrix IDs (@cyphar:cyphar.com, for instance). But if the problem is distributing keys, then that is a solvable problem. But then again, maybe a different solution is needed to fill the PGP niche.
philips 7y ago
I believe this is a project trying to replace the old school key servers. https://github.com/google/keytransparency/ https://github.com/google/keytransparency/
- majewsky 7y ago
  Is there any piece of distributed internet infrastructure that Google is not trying to replace?
  - mschuster91 7y ago
    Probably not, it does make sense for Google though that they do not want to be stuck with mission critical stuff they don't have the final authority on and which is ... obscure in both code and people.
dpc_pw 7y ago
Is the new berifing SKS from Sequoia PGP (written in Rust!) affected as well? https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/ https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/
- Valodim 7y ago
  It is not! That's why the author recommends using the running instance at keys.openpgp.org, as a replacement for the sks pool. Note that Hagrid is not an "sks in rust". It is different in a lot of ways, see https://keys.openpgp.org/about/news#2019-06-12-launch https://keys.openpgp.org/about/news#2019-06-12-launch (disclaimer: I maintain keys.openpgp.org)
dngray 7y ago
Isn't WKD supposed to help out with key distribution for email? * https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD * https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08 https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic... I'm thinking that's a better way to publish keys these days anyway. I have my own domain, so maybe OPENPGPKEY record in my domain as well DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929
- Valodim 7y ago
  It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath. The other contender is Autocrypt, which performs key exchange inline in emails in an automated fashion. It only depends on client support, and has gained at least some traction (enigmail, k9, mailvelope, gpgOL, delta.chat, and some others).
  - dngray 7y ago
    > It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath. Ah. > The objective of the project was to develop new mechanisms for the reliable and automatic public PGP key exchange between e-mail providers. The results have also contributed to the WKS/WKD standard that is part of the GnuPG project. https://mailbox.org/en/security https://mailbox.org/en/security I was looking at going with mailbox.org or possibly protonmail (though they don't have calendars at the moment and I use that), both apparently support it. As does Thundebird+Enigmail, K9/OpenKeychain. I have noticed the AutoCrypt method. Part of the reason I changed my email is because I had in the past submitted a few keys to the sks network which I lost the private keys to, they were also submitted with an infinite expiry. I was a stupid kid. So I am unlikely to submit my new keys to the sks network. Just store them in my domain, WKD, and on my blog.
    - Whatitat90 7y ago
      > Part of the reason I changed my email is because I had in the past submitted a few keys to the sks network which I lost the private keys to, they were also submitted with an infinite expiry. I was a stupid kid. That's why most recent versions of GnuPG automatically create keys with expiry set to 2 years.
snackematician 7y ago
The suggested mitigation (editing `gpg.conf` and `dirmngr.conf`) doesn't seem to work for me. In particular I created `~/.gnupg/dirmngr.conf` with a line for the `keys.openpg.org` keyserver (and don't have a `~/.gnupg/gpg.conf`), but `gpg --refresh-keys` still uses `hkps://hkps.pool.sks-keyservers.net` which the gnupg Info (section 3.2 Dirmngr options) says is the default.
- Valodim 7y ago
  Did you `killall dirmngr`? :)
  - snackematician 7y ago
    Thanks that solved my issue :)
diafygi 7y ago
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/ https://sks.daylightpirates.org/ (currently down) [2]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/k... [3]: http://ipsit.bu.edu/documents/ieee-it3-web.pdf http://ipsit.bu.edu/documents/ieee-it3-web.pdf [4]: https://lists.nongnu.org/archive/html/sks-devel/2016-08/msg00072.html https://lists.nongnu.org/archive/html/sks-devel/2016-08/msg0... [5]: https://tools.ietf.org/html/rfc4880#section-5.2.3.25 https://tools.ietf.org/html/rfc4880#section-5.2.3.25
Sir_Cmpwn 7y ago
PGP and SKS are two entirely different technologies, and issues with SKS should not justify writing off PGP. "Efail" is a very stupid "vulnerability" used to smear PGP by jerks with ulterior motives.
- tptacek 7y ago
  Efail was one of the best crypto breaks of 2018, accepted into both Usenix Security (a top-tier academic venue) and BHUSA (the top tier industry venue), and virtually universally lauded by actual cryptography engineers and researchers. What you've said here is false, a personal attack on the researchers, and absolutely unacceptable on HN. Take this stuff somewhere else.
  - Sir_Cmpwn 7y ago
    Efail was a symptom of bad PGP implementations in email clients, not a flaw in PGP. It was overblown trash designed to bring fame to the "discoverers" at the expense of the reputation of PGP and its authors. If you think that this statement doesn't belong here, you can take it up with the mods, a group which spending lots of time on HN does not qualify you for.
    - tptacek 7y ago
      Adding a personal attack against me doesn't make your bogus, amoral argument any more acceptable.
      - xKINS 7y ago
        Internet point king here, but has done nothing in the last decade. Enjoy your meaningless fame.
    - AnaniasAnanas 7y ago
      As much as I believe that Efail was the result of badly implemented email clients it's not like the OpenPGP standard hadn't any involvement with it whatsoever. DJB for example suggests small authenticated and encrypted packets, something that OpenPGP does not have. See https://groups.google.com/forum/#!original/boring-crypto/BpUmNMXKMYQ/EEwAIeQdjacJ https://groups.google.com/forum/#!original/boring-crypto/BpU... Since I am apparently replying too fast and I need to slow down, here is my reply to the child post by Sir_Cmpwn: > I don't really see the link between the email you posted and efail GPG decrypts the whole message which might be gigaoctets long and throws it to the output. After it has been decrypted it checks the MDC (if it exists) and throws an error if the MDC does not match or if it is missing. Meanwhile if a OpenPGP message was composed of small authenticated packets GPG would be able to first authenticate if the MAC of the packet is correct and then return an error right away if it does not match. If it did match it would return plaintext and move on to the next packet. You can see now how efail would be prevented, right? > PGP Do people use PGP nowadays? I was under the impression that pretty much everyone used GPG ever since it was released.
xvilka 7y ago
A bit more[1] on consequences of this attack, gist from the same author. [1] https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...
- ComodoHacker 7y ago
  Wow, there's much more: >Special criticism goes to the Electronic Frontier Foundation, which paid Micah Lee to publish premade attack tools to exploit these design misfeatures in the keyserver network ... >January of last year — January 16, 2018 — one user threatened to do what pretty much happened this week.
- Forbo 7y ago
  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".
  - alasdair_ 7y ago
    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?
    - roywiggins 7y ago
      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.
DyslexicAtheist 7y ago
that affects the onionbalancers as well then :( https://dev.gnupg.org/T3392 https://dev.gnupg.org/T3392
ComodoHacker 7y ago
>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?
- CameronNemo 7y ago
  Not sure how you could fix an OpenPGP client for this case without changing how the keyservers function.
  - viraptor 7y ago
    "You're trying to pull more than reasonably supported 1k signatures. Do you want to skip this step?"
    - maddyboo 7y ago
      This will protect your machine from being DoS’d, but what if your key is poisoned? Nobody will be able to use it.
  - ComodoHacker 7y ago
    Optimize to handle 150K signatures in reasonable time.
geofft 7y ago
It's fascinating that the conversation in the GitHub comments went to both personal attacks on the author of the post and defending child pornography in the span of like five responses. I feel like part of the problem is that anyone who's skilled enough to implement solutions has better things to do with their time than participate in a discussion of that quality.
- Waterluvian 7y ago
  Hmm. Has a site ever experimented with separate comment sections? Put simply: on vs. Off topic (or maybe "meta") . Our comments would be in the off topic section, for example. I regularly see people apologizing for being off topic. Clearly they have something they think is worth saying, but are afraid to pollute the discourse.
  - geofft 7y ago
    I think this falls into one of those social problems with no technical solution. The culture of PGP, as described in the post itself, is that anyone can participate, anyone can upload signatures, anyone can run keyservers, there's no way to remove uploaded keys or signatures ever, and there's no central authority for what is on the keyserver network. Given that culture, there's a social expectation that if you're not going to let the pedophile with the anime avatar have the rest of his arguments taken at face value, you're censoring people and might as well go use one of those corporate sell-out encryption systems like Signal. (To your actual question: meta.stackoverflow.com, Wikipedia talk pages, meta.wikimedia.org, etc. Also various email/chat communities have defined off-topic lists/rooms. When the participants do actually want to keep off-topic discourse to the side, and the off-topic discussion isn't an attack on the competence of someone reporting a problem or a desire to propagate child pornography, then it's merely a technical problem of enabling them to do it.)
despera 7y ago
The author sounds a bit over dramatic and with many logical jumps, ocaml might not be in the news and what cool kids use this days, that doesn't make it a bad language. The base code doesn't look impossible to restructure. The attack vector is know for long time. Also it's not like we haven't seen before important code being pretty much unmaintained written in far more popular languages e.g openssl.
perlin 7y ago
Now may be a good time to plug a project we worked on at my last gig. KeySpace uses IPFS to store PGP keys in a decentralized file system. We used a smart contract on the Ethereum blockchain to store an address-hash lookup. What this achieves is fully decentralized peer-to-peter encrypted communication. We used it to facilitate trustless OTC negotiation and trading. https://medium.com/fluidity/keyspace-end-to-end-encryption-using-ethereum-and-ipfs-87b04b18156b https://medium.com/fluidity/keyspace-end-to-end-encryption-u...
- chakalakasp 7y ago
  >peer-to-peter Ooh er, missus
tptacek 7y ago
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 apparently only hit the accounts of two maintainers – that is, two people who are, or should be, exquisitely capable of distilling signal from the attack, and making sensible decisions to mitigate it going forward. A serious attacker, on the scale of the adversaries this project has, again, deliberately selected for itself, wouldn't waste the vulnerability this way. They'd wait for the most opportune time and apply the attack broadly to accomplish their own state-level goals. This isn't the first time the GnuPG ecosystem has responded this way to attacks. They similarly (and dishonestly) attacked the Efail researchers, and in the same document I referred to above, Hansen attacked EFF and Micah Lee for publishing exploit code; "Academic freedom should not be construed as permission to publish attack tools against a critical service with known vulnerabilities". This is what you'd expect from one of the vendors posting about a tempfile race condition on the CORE clique list in 1992; it's preposterously out of step with how the field handles vulnerability research today. If you're relying on GnuPG for anything serious, you should be alarmed at the way they react to security setbacks. † Indeed, repeatedly predict-ed
- mzs 7y ago
  indeed: https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...
  - danShumway 7y ago
    A vulnerability in mission-critical software has been known for years, and they're mad that finally someone got fed up enough to publicly draw attention to it in a way that couldn't be ignored or dismissed by the maintainers? I don't think it's the EFF putting activists at risk here.
    - 7y ago
paulddraper 7y ago
> 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?
- literallycancer 7y ago
  There's at most hundreds of people writing OCaml for non-academic purposes at least once a week.
ggm 7y ago
Can somebody explain to me a legitimate use for a single key cross signed by e.g. 100,000 other keys? Is the goal group communications? I get that arbitrary limits are bad. And that an attack on a system can be converted to an attack on a key, I'm not seeking mitigation in this question. I just want to understand in some six degrees of Kevin bacon manner, if there is a real use for a single large sign set rather than eg a merkle tree of decomposed subsign sets?
lifeisstillgood 7y ago
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 account, thus making anything signed by that account impossible to verify - This may or may not mean that major distributions binary packages will simply stop being verifiable - it depends on who uses what key server in what chain of trust. We probably won't find out till more bad actors poison more wells - This has been "well known" for some time but the solution is not obvious - It seems that this is the reason keybase works like it does : if a user simply attests that key X is theirs in a second channel you can trust that as much as you trust the channel. it a key server is the only channel and for reasons will not delete the 150,000 bad keys - There are many alternatives to GPG it seems - or at least to the sub-functions under its "brand". Signal to send message or minisign to sign documents - it do they have the same "OpenSSL" lack of support in them? - Don't the million dollar companies like DocuSign use GPG? So that's me - trying to work out if this is the end of the world or a storm in a teacup - thoughts welcome :-)
- danShumway 7y ago
  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.
mirimir 7y ago
Wow, that is quite the KCF. This is the core problem: > The [SKS] software is unmaintained. Due to the above, there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the [OCaml] codebase. The solution is simple: don't use the SKS keyserver network. > High-risk users should stop using the keyserver network immediately. I used to use it, but mainly I just send people signed messages, and ask them to send me their public keys. I point them to my Keybase page, in case they prefer to encrypted key. But that isn't generally practical. So about the mitigation. > Users who are confident editing their GnuPG configuration files should follow the following process: > Open gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. This part makes sense. > Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it. I'm not sure whether that's necessary. For Debian users, adding keyring.debian.org makes sense. But otherwise, isn't it best to get keys from first-party sources?
deleted 7y ago
[deleted]

379 points by Spellman 7y ago

>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

amenghra 7y ago

SKS don’t implement any modern web security features (the whole thing does pre-date the web!) — as a result, you can (ab)use SKS as a free backend store for your JavaScript apps: https://www.quaxio.com/message_board_over_pgp_key_servers.html https://www.quaxio.com/message_board_over_pgp_key_servers.ht...

rasengan 7y ago

I think that decentralized services, like SKS, require a sort of fee mechanism (proof of effort, currency, or otherwise) that can prevent bad actors from inserting malicious material. I definitely think this is one of the cases that blockchain technology makes a lot of sense, and the disincentive of a fee would do very will to mitigate this.

JoachimSchipper 7y ago
How would a proof-of-work system, let alone a blockchain, work? Apparently, GnuPG breaks badly at 150 000 signatures. You want adding a signature to be doable on a really old laptop and/or low-end Android phone; a motivated attacker can just choose to expand 1000 000 times as much effort as a not-too-interested user on antiquated hardware. Of course you can make adding a signature more expensive the more signatures are already there, but that lets a motivated attacker make it impossible to vouch for certain users (keys.) Etc.

libeclipse 7y ago

The new keys.openpgp.org service is a mitigation: > keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence.

paulfurley 7y ago
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 (“secure”) pool, so in reality SKS is centralised too, as well as unmaintained. Source: I run a key server and a key expiry reminder service.
- jlgaddis 7y ago
  Out of curiosity, which is more obscure: OCaml or Rust?
  - kchamplewski 7y ago
    Probably OCaml. While it's been around much longer, it's never really reached mass acceptance (though does get used here and there). Rust is newer but I'd estimate it's already more used, and its adoption in industry is growing quite quickly. This is probably to do with the fact that OCaml doesn't necessarily solve any problems that are apparent to businesses, whereas Rust solves the very apparent "manual memory management makes massive vulns trivial" problem. I'm not sure which language is actually more approachable for someone trying to learn it from scratch though.
    - AnaniasAnanas 7y ago
      OCaml is very popular in academia though, especially in the field of theoretical computer science and formal verification. Coq, Frama-C, Flow, CompCert, etc are all written in OCaml. Heck, if you are running a graphical GNU distribution chances are that you have installed FFTW, which is written in OCaml. The "industry" is not the only thing that matters when considering the adoption of a language.
      - ghuntley 7y ago

Shoop 7y ago

> 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 obscure programming languages and strange programming customs. Looking at the code [0], it looks like fairly standard Ocaml. Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)? (It looks like the original author of the SKS Keyserver is Yaron Minsky, the guy who convinced Jane Street to use Ocaml.) [0] https://bitbucket.org/skskeyserver/sks-keyserver/src/default/ https://bitbucket.org/skskeyserver/sks-keyserver/src/default...

xvilka 7y ago
Yes, the code looks fairly simple, I would say.
- ghuntley 7y ago
  Looks like fairly standard OCaml and usage of functional programming idioms. Q: Where's the CI and property tests? If you feel uncomfortable maintaining the code base, start there.
  - ghuntley 7y ago
    The author of the gist has his CV on his personal website and lists himself proficient in fsharp. :confused:
    - gravitas 7y ago
      https://rationalwiki.org/wiki/Argumentum_ad_hominem https://rationalwiki.org/wiki/Argumentum_ad_hominem
      - cbsmith 7y ago

vermilingua 7y ago

To be clear: is this suggesting that it is currently entirely unsafe to update any operation-critical equipment? It seems that now that the PoC is out in the wild, it will be a matter of days/hours before someone hits a major contributor to the major Linux distros; and all package managers begin to fail.

koolba 7y ago
Yes this seems like it's going to range from very bad to outright terrible. In particular if the issue propagates prior to patching something like gpg as the package managers would be locked out from updates. Every time there's an article about IoT security there's a discussion about lack of (security) updates and an upcoming Armageddon. Interestingly it'll be those devices that do not update that are immune to this type of thing.
- cyphar 7y ago
  Package managers don't use keyservers to get their keys (at least, not for the distro's repos). I believe Ubuntu might use them for PPAs, but openSUSE doesn't use them for any OBS projects (and I'm pretty sure this is the same for any RPM repo).
- heavenlyblue 7y ago
  >> immune to this type of thing. The _only_ type of thing that they are immune to. This is like saying “a car with a broken engine is the safest car in the world - it never moves!”.
  - majewsky 7y ago
    I think the standard analogy for this sort of thing is "a broken clock shows the right time twice a day".
hlieberman 7y ago
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.

jeffrallen 7y ago

This is why we can't have nice things.

JoachimSchipper 7y ago

It's always sad to see someone taking down a project that is run with the best intentions. However, it may be time to move away from the entire PGP ecosystem. Consider the post's "We've known for a decade this attack is possible. It's now here and it's devastating.". Consider also the final section, "PGP is bad technology and it’s making a bad community", of https://blog.cryptographyengineering.com/2018/05/17/was-the-efail-disclosure-horribly-screwed-up/ https://blog.cryptographyengineering.com/2018/05/17/was-the-... (by noted cryptographer Matthew Green.) My sympathies to the victims of this attack. [EDIT: reworked slightly at 7m to try to be as kind as possible]

clarkmoody 7y ago
The idea of Internet actors (human or machine) owning cryptographic identities in a distributed system is a good one. I don't think we should stray from this approach. From your Matthew Green link: > If PGP went away, I estimate it would take the security community less than a year to entirely replace (the key bits of) the standard with something much better and modern. It would have modern crypto and authentication, and maybe even extensions for future post-quantum future security. It would be simple. Many bright new people would get involved to help write the inevitable Rust, Go and Javascript clients and libraries. Those word were written a little more than a year ago. What if right now is the time to assume that PGP has gone away and start building the next thing? What alternate projects are people excited about that are solving the problem of distributed cryptographic identity and messaging?
- cyphar 7y ago
  > 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 still an open problem, but that's just for the service which links third-party IDs (phone numbers, email addresses, etc) to Matrix IDs (@cyphar:cyphar.com, for instance). But if the problem is distributing keys, then that is a solvable problem. But then again, maybe a different solution is needed to fill the PGP niche.

philips 7y ago

I believe this is a project trying to replace the old school key servers. https://github.com/google/keytransparency/ https://github.com/google/keytransparency/

majewsky 7y ago
Is there any piece of distributed internet infrastructure that Google is not trying to replace?
- mschuster91 7y ago
  Probably not, it does make sense for Google though that they do not want to be stuck with mission critical stuff they don't have the final authority on and which is ... obscure in both code and people.

dpc_pw 7y ago

Is the new berifing SKS from Sequoia PGP (written in Rust!) affected as well? https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/ https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/

Valodim 7y ago
It is not! That's why the author recommends using the running instance at keys.openpgp.org, as a replacement for the sks pool. Note that Hagrid is not an "sks in rust". It is different in a lot of ways, see https://keys.openpgp.org/about/news#2019-06-12-launch https://keys.openpgp.org/about/news#2019-06-12-launch (disclaimer: I maintain keys.openpgp.org)

dngray 7y ago

Isn't WKD supposed to help out with key distribution for email? * https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD * https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08 https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic... I'm thinking that's a better way to publish keys these days anyway. I have my own domain, so maybe OPENPGPKEY record in my domain as well DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929

Valodim 7y ago
It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath. The other contender is Autocrypt, which performs key exchange inline in emails in an automated fashion. It only depends on client support, and has gained at least some traction (enigmail, k9, mailvelope, gpgOL, delta.chat, and some others).
- dngray 7y ago
  > It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath. Ah. > The objective of the project was to develop new mechanisms for the reliable and automatic public PGP key exchange between e-mail providers. The results have also contributed to the WKS/WKD standard that is part of the GnuPG project. https://mailbox.org/en/security https://mailbox.org/en/security I was looking at going with mailbox.org or possibly protonmail (though they don't have calendars at the moment and I use that), both apparently support it. As does Thundebird+Enigmail, K9/OpenKeychain. I have noticed the AutoCrypt method. Part of the reason I changed my email is because I had in the past submitted a few keys to the sks network which I lost the private keys to, they were also submitted with an infinite expiry. I was a stupid kid. So I am unlikely to submit my new keys to the sks network. Just store them in my domain, WKD, and on my blog.
  - Whatitat90 7y ago
    > Part of the reason I changed my email is because I had in the past submitted a few keys to the sks network which I lost the private keys to, they were also submitted with an infinite expiry. I was a stupid kid. That's why most recent versions of GnuPG automatically create keys with expiry set to 2 years.

snackematician 7y ago

The suggested mitigation (editing `gpg.conf` and `dirmngr.conf`) doesn't seem to work for me. In particular I created `~/.gnupg/dirmngr.conf` with a line for the `keys.openpg.org` keyserver (and don't have a `~/.gnupg/gpg.conf`), but `gpg --refresh-keys` still uses `hkps://hkps.pool.sks-keyservers.net` which the gnupg Info (section 3.2 Dirmngr options) says is the default.

Valodim 7y ago
Did you `killall dirmngr`? :)
- snackematician 7y ago
  Thanks that solved my issue :)

diafygi 7y ago

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/ https://sks.daylightpirates.org/ (currently down) [2]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/k... [3]: http://ipsit.bu.edu/documents/ieee-it3-web.pdf http://ipsit.bu.edu/documents/ieee-it3-web.pdf [4]: https://lists.nongnu.org/archive/html/sks-devel/2016-08/msg00072.html https://lists.nongnu.org/archive/html/sks-devel/2016-08/msg0... [5]: https://tools.ietf.org/html/rfc4880#section-5.2.3.25 https://tools.ietf.org/html/rfc4880#section-5.2.3.25

Sir_Cmpwn 7y ago

PGP and SKS are two entirely different technologies, and issues with SKS should not justify writing off PGP. "Efail" is a very stupid "vulnerability" used to smear PGP by jerks with ulterior motives.

tptacek 7y ago
Efail was one of the best crypto breaks of 2018, accepted into both Usenix Security (a top-tier academic venue) and BHUSA (the top tier industry venue), and virtually universally lauded by actual cryptography engineers and researchers. What you've said here is false, a personal attack on the researchers, and absolutely unacceptable on HN. Take this stuff somewhere else.
- Sir_Cmpwn 7y ago
  Efail was a symptom of bad PGP implementations in email clients, not a flaw in PGP. It was overblown trash designed to bring fame to the "discoverers" at the expense of the reputation of PGP and its authors. If you think that this statement doesn't belong here, you can take it up with the mods, a group which spending lots of time on HN does not qualify you for.
  - tptacek 7y ago
    Adding a personal attack against me doesn't make your bogus, amoral argument any more acceptable.
    - xKINS 7y ago
      Internet point king here, but has done nothing in the last decade. Enjoy your meaningless fame.
  - AnaniasAnanas 7y ago
    As much as I believe that Efail was the result of badly implemented email clients it's not like the OpenPGP standard hadn't any involvement with it whatsoever. DJB for example suggests small authenticated and encrypted packets, something that OpenPGP does not have. See https://groups.google.com/forum/#!original/boring-crypto/BpUmNMXKMYQ/EEwAIeQdjacJ https://groups.google.com/forum/#!original/boring-crypto/BpU... Since I am apparently replying too fast and I need to slow down, here is my reply to the child post by Sir_Cmpwn: > I don't really see the link between the email you posted and efail GPG decrypts the whole message which might be gigaoctets long and throws it to the output. After it has been decrypted it checks the MDC (if it exists) and throws an error if the MDC does not match or if it is missing. Meanwhile if a OpenPGP message was composed of small authenticated packets GPG would be able to first authenticate if the MAC of the packet is correct and then return an error right away if it does not match. If it did match it would return plaintext and move on to the next packet. You can see now how efail would be prevented, right? > PGP Do people use PGP nowadays? I was under the impression that pretty much everyone used GPG ever since it was released.

xvilka 7y ago

A bit more[1] on consequences of this attack, gist from the same author. [1] https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...

ComodoHacker 7y ago
Wow, there's much more: >Special criticism goes to the Electronic Frontier Foundation, which paid Micah Lee to publish premade attack tools to exploit these design misfeatures in the keyserver network ... >January of last year — January 16, 2018 — one user threatened to do what pretty much happened this week.
Forbo 7y ago
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".
- alasdair_ 7y ago
  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?
  - roywiggins 7y ago
    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.

DyslexicAtheist 7y ago

that affects the onionbalancers as well then :( https://dev.gnupg.org/T3392 https://dev.gnupg.org/T3392

ComodoHacker 7y ago

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

CameronNemo 7y ago
Not sure how you could fix an OpenPGP client for this case without changing how the keyservers function.
- viraptor 7y ago
  "You're trying to pull more than reasonably supported 1k signatures. Do you want to skip this step?"
  - maddyboo 7y ago
    This will protect your machine from being DoS’d, but what if your key is poisoned? Nobody will be able to use it.
- ComodoHacker 7y ago
  Optimize to handle 150K signatures in reasonable time.

geofft 7y ago

It's fascinating that the conversation in the GitHub comments went to both personal attacks on the author of the post and defending child pornography in the span of like five responses. I feel like part of the problem is that anyone who's skilled enough to implement solutions has better things to do with their time than participate in a discussion of that quality.

Waterluvian 7y ago
Hmm. Has a site ever experimented with separate comment sections? Put simply: on vs. Off topic (or maybe "meta") . Our comments would be in the off topic section, for example. I regularly see people apologizing for being off topic. Clearly they have something they think is worth saying, but are afraid to pollute the discourse.
- geofft 7y ago
  I think this falls into one of those social problems with no technical solution. The culture of PGP, as described in the post itself, is that anyone can participate, anyone can upload signatures, anyone can run keyservers, there's no way to remove uploaded keys or signatures ever, and there's no central authority for what is on the keyserver network. Given that culture, there's a social expectation that if you're not going to let the pedophile with the anime avatar have the rest of his arguments taken at face value, you're censoring people and might as well go use one of those corporate sell-out encryption systems like Signal. (To your actual question: meta.stackoverflow.com, Wikipedia talk pages, meta.wikimedia.org, etc. Also various email/chat communities have defined off-topic lists/rooms. When the participants do actually want to keep off-topic discourse to the side, and the off-topic discussion isn't an attack on the competence of someone reporting a problem or a desire to propagate child pornography, then it's merely a technical problem of enabling them to do it.)

despera 7y ago

The author sounds a bit over dramatic and with many logical jumps, ocaml might not be in the news and what cool kids use this days, that doesn't make it a bad language. The base code doesn't look impossible to restructure. The attack vector is know for long time. Also it's not like we haven't seen before important code being pretty much unmaintained written in far more popular languages e.g openssl.

perlin 7y ago

Now may be a good time to plug a project we worked on at my last gig. KeySpace uses IPFS to store PGP keys in a decentralized file system. We used a smart contract on the Ethereum blockchain to store an address-hash lookup. What this achieves is fully decentralized peer-to-peter encrypted communication. We used it to facilitate trustless OTC negotiation and trading. https://medium.com/fluidity/keyspace-end-to-end-encryption-using-ethereum-and-ipfs-87b04b18156b https://medium.com/fluidity/keyspace-end-to-end-encryption-u...

chakalakasp 7y ago
>peer-to-peter Ooh er, missus

tptacek 7y ago

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 apparently only hit the accounts of two maintainers – that is, two people who are, or should be, exquisitely capable of distilling signal from the attack, and making sensible decisions to mitigate it going forward. A serious attacker, on the scale of the adversaries this project has, again, deliberately selected for itself, wouldn't waste the vulnerability this way. They'd wait for the most opportune time and apply the attack broadly to accomplish their own state-level goals. This isn't the first time the GnuPG ecosystem has responded this way to attacks. They similarly (and dishonestly) attacked the Efail researchers, and in the same document I referred to above, Hansen attacked EFF and Micah Lee for publishing exploit code; "Academic freedom should not be construed as permission to publish attack tools against a critical service with known vulnerabilities". This is what you'd expect from one of the vendors posting about a tempfile race condition on the CORE clique list in 1992; it's preposterously out of step with how the field handles vulnerability research today. If you're relying on GnuPG for anything serious, you should be alarmed at the way they react to security setbacks. † Indeed, repeatedly predict-ed

mzs 7y ago
indeed: https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...
- danShumway 7y ago
  A vulnerability in mission-critical software has been known for years, and they're mad that finally someone got fed up enough to publicly draw attention to it in a way that couldn't be ignored or dismissed by the maintainers? I don't think it's the EFF putting activists at risk here.
  - 7y ago

paulddraper 7y ago

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

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

ggm 7y ago

Can somebody explain to me a legitimate use for a single key cross signed by e.g. 100,000 other keys? Is the goal group communications? I get that arbitrary limits are bad. And that an attack on a system can be converted to an attack on a key, I'm not seeking mitigation in this question. I just want to understand in some six degrees of Kevin bacon manner, if there is a real use for a single large sign set rather than eg a merkle tree of decomposed subsign sets?

lifeisstillgood 7y ago

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 account, thus making anything signed by that account impossible to verify - This may or may not mean that major distributions binary packages will simply stop being verifiable - it depends on who uses what key server in what chain of trust. We probably won't find out till more bad actors poison more wells - This has been "well known" for some time but the solution is not obvious - It seems that this is the reason keybase works like it does : if a user simply attests that key X is theirs in a second channel you can trust that as much as you trust the channel. it a key server is the only channel and for reasons will not delete the 150,000 bad keys - There are many alternatives to GPG it seems - or at least to the sub-functions under its "brand". Signal to send message or minisign to sign documents - it do they have the same "OpenSSL" lack of support in them? - Don't the million dollar companies like DocuSign use GPG? So that's me - trying to work out if this is the end of the world or a storm in a teacup - thoughts welcome :-)

danShumway 7y ago
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.

mirimir 7y ago

Wow, that is quite the KCF. This is the core problem: > The [SKS] software is unmaintained. Due to the above, there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the [OCaml] codebase. The solution is simple: don't use the SKS keyserver network. > High-risk users should stop using the keyserver network immediately. I used to use it, but mainly I just send people signed messages, and ask them to send me their public keys. I point them to my Keybase page, in case they prefer to encrypted key. But that isn't generally practical. So about the mitigation. > Users who are confident editing their GnuPG configuration files should follow the following process: > Open gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. This part makes sense. > Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it. I'm not sure whether that's necessary. For Debian users, adding keyring.debian.org makes sense. But otherwise, isn't it best to get keys from first-party sources?

deleted 7y ago

[deleted]