Conversation
Notices
-
And while we're on the topic of #PGPday: I wish PGP were integrated into sites/services. Any time I post on sites like HN, Reddit, or even my own GNU Social instance, I don't assert my identity like I do with every e-mail I send. I could, but people would get rather annoyed with a lengthy hash and delimiters in each message. I was starting to maintain a separate repo at one point with copies of my messages, signed, but that was too much work.
So you can't really trust the authenticity of any message anywhere online except mail. Nothing's to stop HN/Reddit admins (or crackers) from pretending to be me or modifying my messages. Or forging messages from me on other GNU Social instances.
And even if you _do_ include a signature, the site might format the message differently than how you typed it (e.g. normalizing whitespace, formatting syntax), so when a user goes to manually verify it by copying the text in their browser, they may get a failure on a message that is otherwise valid.
-
And to clarify: having the site itself verify the message using a public key the user uploaded to a server is also half-useless---if the server is compromised or if the connection is MitM'd, you could be tricked. I'd argue that it might even be _worse_ than not doing signature verification, since it would provide a false sense of security.
So this would need collaboration with browser authors.
-
@mikegerwitz For what it's worth, cryptographic signing of messages is something I eventually want to add to my GNU social fork, postActiv.
-
@mikegerwitz Fellow dev @verius and I have gone back and forth a few times on how to implement it. The implementation details is where the hangup has been, since we would want it to degrade well on other instances or software that don't have the functionality.
-
@maiyannah It'd be nice if it could be incorporated into a W3C standard---a way to provide a signature on the content of some HTML element, that the browser could then verify using the user's keyring. If it were added as an e.g. data attribute and implemented by plugins in the meantime (perhaps using something similar to the SRI syntax), it'd be backwards-compatible with HTML5 and wouldn't be rendered by the browser.
...would be nice, anyway. As long as the web page did not have an API to access any information about this system; otherwise they could query the user's keyring by trying various signatures and checking for their validity.
-
@mikegerwitz This is definitely a consideration. One thing I would note is that GS has two canonical fields, a plaintext one and an html one, and the html one goes through an html cleanser to remove certain tags, attributes, etc. also unfortunately different servers may do their own processing (not least of which is plugins, my greentext plugin modifies the HTML.) Submitting content would have to either have a two-step process of submitting a post, then getting back the canonical representation so it could be signed, or making the the server's preferred canonicalization a publicly accessible spec so clients could conform before submitting. Likewise, servers, including remote ones, would have to have a way to regurgitate the canonical version of a notice so that clients could independently verify.
Some of us have had some discussion on this. I'm of the opinion that a simple elliptical curve sig with keys that don't implement web of trust, ala OpenBSD's "signify" tool for signing releases. But I'm still open to PGP. Just the default key created these days in enigmail is a 4096-bit RSA key, which has a lot of overhead. Then again, it's just text.
-
@mikegerwitz Yeah, unfortunately the W3C seems more interested in pushing digital handcuffs onto the web than they are in improving the protocols and security in means like this.
The thought I've had is maybe some microcode in the notice but I'm not sure there isn't an easy way to do that without increase the overhead of the message significantly. We could maybe use magic envelopes for something like this. I am unsure though. I actually don't have a lot of experience in cryptology programming so I'm uncertain what would be best here.
-
@maiyannah @verius unfortunately I know virtually nothing about the protocol to provide any advice. Despite what I said above, server-side signature verification is much less of a problem for self-hosted instances (I could trust the keyring on my server, but not someone else's), so I could still see use for something like that in federated protocols. A user could decide whether or not to trust the keyring of instance they're using, especially if the instance provided a way to manually verify it (e.g. copying the raw signed message).
-
@mikegerwitz trying to retrofit security onto gnusocial I think would be a mistake. Instead if folks want DMs or verified posts they should use existing secure apps which have been well tested. gnusocial should merely make it easy to look up your direct communication address. GPG key, Tox ID, xmpp, etc.
-
@mikegerwitz Perhaps the server could act something like a PGP keyserver, and then individuals could verify keys on that server and load it into a keyring. I'd have to give it some thought and would want to consult people who better know the domain than I do before I implement something. It's something I do want to do though, it would be a good addition to the software.
-
@moonman A web of trust would be essential to me (and others among us that go through the trouble of meeting up for keysigning) to verify someone's identity; signify wouldn't do that.
While EC does result in significantly smaller keys (and signatures), not all systems support them. My Nitrokey, for example, uses RSA.
-
@mikegerwitz I wish browsers had good integration for things like PGP sticks. Mozilla had a thing with browserid going for a while, but it was still really, really clunky.
-
@bob I'm suggesting retrofitting PGP into the entire Web, not GNU Social specifically; though that's what @maiyannah was referring to. I want to be able to assert my identity anywhere on the Web, where other people are looking; the fact that I am having this problem at all shows that I'm communicating a lot with people through unsecured channels.
@maiyannah If the user's browser isn't doing the signature verification using their own keyring, then the server would have to do it using it's own keyring (e.g. how GitHub is doing it today). But I can't trust what GitHub says: they could be malicious, they could be compromised, or the user's account could be compromised and someone could upload their own GPG key to that user's account.
-
@maiyannah unless you meant that the user would do the verification client-side using the server's keyring. Which would be essentially the same as the server doing it---while Mallory wouldn't be able to MitM the output form the verification (since it doesn't exist), he could MitM the keyserver request or replace the actual signature on the served request, or both. Relying on the server in any way relies on TLS to securely deliver the communication, which relies on a _second_ PKI, which has a host of problems.
-
@mikegerwitz Right, these are all concerns I share, and why I would want to solicit opinions from the crypto/security community that would probably have ideas on how to overcome these problems. It isn't something I have an immediately-evident answer to.
-
@maiyannah the verification part is easy, just fetch the user's public key from a public keyserver and do it (or have the user upload the public key in the first place); the signing part is the one that will give you headaches, because storing users' private keys on the server is a no-no, it makes you a big fat target for lots of people
Maybe something like https://addons.mozilla.org/en-US/firefox/addon/webpg-firefox/ could work? (never used it, found it now)
@mikegerwitz
-
@m0n5t3r Oh, interesting, I'll have to look into that addon. Using GPGME is the approach I would have hoped would be possible with an addon.
With regards to auto-fetching from a keyserver: if it's done on-demand, that'll effectively treat the signature as a checksum, in the sense that it will verify that the message has not been tampered with, but it won't necessarily assert the identity of the author. Unless it's persisted, e.g. TOFU model, then it'd be like the user uploading it, if they happen to post more than once.
-
@mikegerwitz @maiyannah In general the problem is not so much server validation vs client validation, once there's a mechanism for signing messages it's not all that difficult to have both.
The details where the devil is at is how to sign messages in such a way that all the information we want signed is signed but we don't impose undue restrictions on servers regarding how to handle messages.
-
@verius @mikegerwitz Yeah as I noted earlier in the thread the real devil in the details here is not having it break servers which do not implement signing and having it degrade gracefully.
Mike Gerwitz
Maiyannah Bishop
Hazukashii
Bob Mottram
m0n5t3r
Verius
All Mike Gerwitz's GNU Social Instance content and data are available under the