5 ms·
Hi - crypto team lead here. I'll hijack this comment to try to explain what Proton Bridge is intended to do, and why it doesn't work the way OP wants. Bridge i
by twiss 3y ago
Hi - crypto team lead here. I'll hijack this comment to try to explain what Proton Bridge is intended to do, and why it doesn't work the way OP wants.
Bridge is a proxy which hosts a local IMAP and SMTP server, and takes "normal" unencrypted and unsigned messages from desktop MUAs like Thunderbird, signs and encrypts them, and then sends them out. Note that this requires changing the MIME message somehow.
OP writes:
> Everything was great until I decided the other day that I’d also like to do PGP signing on my outgoing messages.
The "intended" way to do this is enable the setting in Proton Mail that says "Sign external messages" :) That way, Bridge will sign them for you. (Internal messages are always signed.)
> Tough luck, bucko, we’re the SECURE email company, you’ll upload your private key to our servers and you’ll like it!
FWIW, private keys are stored encrypted on the server, we don't have access to them.
But yes, the entire goal of Proton is to handle PGP for you, without having to set up PGP encryption and signing manually on all of your devices. I know that the HN audience is fully capable of doing so, but our goal is to make it easier for everyone else :)
> It’s absurd that there’s no way to disable this, no option to tell Proton “if you see a multipart/signed or multipart/encrypted message, just leave it the hell alone.”
IMO, if we see a multipart/signed message, we should still encrypt it whenever possible, not leave it alone. But note that normally in OpenPGP, signing and encrypting is a single operation. It's possible in PGP/MIME to sign a message first and then encrypt it, but we don't support sending that way at the moment, though we could of course add that in the future. But in any case, that's the reason we currently recommend signing using Bridge rather than manually using gpg or similar.
- unconed 3y agoWhy can't you just detect that it was already signed with a valid signature, especially if you have the user's public key? PS: the lack of threading support in your mobile apps is embarrassing, it's been like this for years. No I will never use your web client. Stop trying.
- twiss 3y agoSee my last paragraph :) PS: yes, this is being worked on
- refulgentis 3y ago^ This is one of those customers you lose on purpose. The comments section in general is full of wonderful behavior, but this is top 5.
- unconed 3y agoCorrect. You lose customers on purpose when you don't have basic features that the competition has had for years, and when, after years of delays, you release a new version of your app that still doesn't have this feature. I don't know why you think this is some sort of gotcha. Other than you think having standards is too entitled.
- blitzar 3y agoCan we have a direct (encrypted) IMAP connection please, no bridge, just serve the encrypted messages into my email client.
- twiss 3y agoIt's not entirely trivial because for internal messages we don't store them in PGP/MIME format, for performance reasons (e.g. to make it possible to fetch the body separately from the attachments, or one attachment without the others, they are signed and encrypted separately, unlike PGP/MIME which signs+encrypts the whole message in one go). So, if we serve the messages "as-is" it's unlikely that the email client would display them correctly. We're considering trying to standardize (something similar to) our internal format at the IETF, to enable other clients to implement such a format, but again it's not something we can ship overnight.
- blitzar 3y agotbh the reason I expected this to not be a thing is the reason you have given (consequences), hopefully a standard that suits everyones needs comes through at some point. Appreciate the work.
- deleted 3y ago[deleted]
- 8organicbits 3y ago> FWIW, private keys are stored encrypted on the server, we don't have access to them. I'm always bothered by statements like this because it appears to be skimming over if the provider can perform cryptography with the key. My understanding is that those keys are only decrypted in the users apps/web browser, not server-side. Is that right? You need to trust that the provider doesn't perform additional operations along side legitimate user triggered actions, which I believe PM handles. https://proton.me/blog/encrypted-email https://proton.me/blog/encrypted-email
- twiss 3y agoCorrect, private keys can only be decrypted client-side, the server doesn't have access to the password that they're encrypted with. Otherwise it wouldn't be end-to-end encryption, IMO :)
- e12e 3y agoBut you distribute the js that accepts the passphrase - so you could trivially exfiltrate the password - and so access the private key. "Don't have access" is a little too strongly worded IMNHO. (I understand the reasoning - and I don't necessarily think it's bad - I just think it overpromises a bit)
- twiss 3y agoSure, fair enough. I've edited it to "the server doesn't have access". Also, see https://news.ycombinator.com/item?id=36643922 https://news.ycombinator.com/item?id=36643922.
- cuteboy19 3y agoThe app ultimately shows you your decrypted email. If client side code is compromised then I don't think this is the thing you worry about
- e12e 3y agoSending signed and encrypted emails is worse than just reading.
- pxc 3y ago> > Tough luck, bucko, we’re the SECURE email company, you’ll upload your private key to our servers and you’ll like it! > FWIW, private keys are stored encrypted on the server, we don't have access to them. This is frankly fucking ridiculous. Users (including me) have been requesting a change to this for years. It's thanks to this bullshit that ProtonMail's key feature for me is just 'isn't Google'.
- bigfishrunning 3y agoprivate keys, ideally, aren't stored on the server at all