That's not necessarily specific to iOS. Certificate pinning is usually done inside an app, not at the OS level. An app can choose to ignore the system certificate store and, for example, pin the cert used to talk to its private API. This is possible both on iOS and Android.
iOS is even easier than Android to add system certificates and can be done without rooting or jailbreaking the device unlike android. cert pinning is done by the apps not the system.
Android apps could also do certificate pinning with the same effect though? In this case there isn't any difference between Android and iOS in functionality.
Open source does not magically make your software more secure.
Community needs to audit the code if they are going to use it instead of trusting blindly.
Code should be self-documented.
And editor should have a good mechanism to help you understand the source code.
Emacs does better in this angle than Vim by far.
You can find the documentation for every variable (describe-variable) and functions (describe-function) easily and jump to their source codes.
Use a low entropy things (I guess user's password would be not larger than 20 characters nowadays even using password managers) to encrypt a high entropy strings (PGP key).
We derive a (key-encryption-)key from the password using a password hashing function / key derivation function (bcrypt, although we're planning to switch to Argon2) before using it to encrypt the PGP key. This is fairly standard practice, it's what password hashing / key derivation functions are designed for.
The crypto refresh of the OpenPGP standard also has Argon2 built-in, exactly for this purpose, so that you don't have to do it manually. (RFC4880 also has "string-to-key" functions built-in but they are fairly weak so we don't rely solely on them.)
All of that being said, it's still important to choose a strong password or passphrase, of course; if you choose "123" then it's gonna be guessed instantly no matter how strong the hashing function is (well, unless it's so strong that even logging in becomes too expensive...)
The main goal of password hashing functions is to tip the balance towards making it too expensive for an attacker to guess your password (as long as it has let's say "medium entropy") while still making it cheap to log in.
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.
> 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.
Even if all the decryption resides in the app/web browser side, they can just silently change the code and inject some scripts to hijack the encryption routine.
Although they are open-source and can be scrutinized by anybody, it does not means that's what is run on the server side.
(Just say they have the capability; no accusation)
So at the end of the day, the question is whether you trust Proton or not. Encryption might not help in that case.
Yeah. For web, I've been advocating for something like "Source Code Transparency" (somewhat analogous to Certificate Transparency) in the WebAppSec WG at the W3C. The idea would be that if you could verify that the source code you're getting is the same as what everyone else is getting for a given version of the web app (and has been published in an append-only log of sorts), it would be much more difficult for us to try to compromise any given user without detection.
On mobile, to do such an attack we'd have to collaborate with Apple or Google to do it, which IMHO seems infeasible - but nevertheless also there a "Binary Transparency" feature of sorts might be valuable.
> I've been advocating for something like "Source Code Transparency"
Thank you for moving the web forward. Proton mail does a lot of things well, and there's more to do. I was auditing DANE support and PM was one of the few I found with support.
Correct, 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 :)
> > 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'.
It'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.
tbh 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.
Why 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.
Correct. 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.
> 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.”
which, as I said in my response, I disagree with the first half of that. Our goal is to (automatically) encrypt messages whenever possible, and leaving multipart/signed messages alone doesn't reach that goal. So I proposed two different solutions to what OP wants, one of which is already built into Proton Bridge, and one which we could add in the future (but which would be more effort than the one OP proposes).
It was good enough for Snowden. Apparently not good enough for the people here who want a centralized server that requires phone numbers run by a hip guy with a cute name.
Ya, either the parent post is troll, or he read the Vice article from 5 years ago and thinks it nullifies PGP? Not sure, but is it perfect? No. But I don’t think Snowden is a security LARPer.
The only thing I miss is the official API for the scheduled sending feature.
That's the only thing I would open the webpage app to do.