This is non-news, like all tech companies, they are bound by law to do this. It happens more than 6000 times per year for Proton. However, this user just had bad opsec. Proton emails are all encrypted and cannot be read unless law enforcement gets your password, which Proton does not have access to. Even if Proton hands over all data.
Email in transit is not encrypted. At least not encrypted by anything that the government can’t compel the company to hand over. Your password as best can only lockdown the mailbox itself. Not the receipt/sending of emails.
Edit: The point being is that if you’re a person of interest, the government can just watch your activity until they get what they want. And Proton doesn’t really have anything they can do about it other than a canary page I suppose.
Edit2: to make it even more clear, I’m talking about MTAs communicating with each other. Proton being one party would have the keys to their side of the communication which is sufficient to decode the whole lot.
IF TLS is used AND configured optimally on both ends, THEN the in transit message contents should be very secure, in that transient session keys were used.
I would be interested to know how often those two preconditions hold true though.
Of course, this is only one small link in the chain. There aint no magic bullet.
Proton would have the key. A government that is already compelling them to hand over your account can simply be compelled to provide the TLS keys. The point is that government doesn’t have to compel proton for at rest storage, but can compel for in transit interception.
This whole discussion is about a government forcing Proton mail to take actions. Telling me to “read up on pfs” is irrelevant by your own admission. ProtonMail can be compelled to give up their keys, or to hand them over for all current/future transactions.
So once again…
“read up on pfs”
“Pfs doesn’t matter”
Literally this post.
You cannot rely on MTAs to transmit ANYTHING securely in the context of this discussion. Period. There is no E2E when there’s an MTA involved unless you’re doing GPG/PGP or S/MIME. Nobody does this though… Like literally nobody. I’ve got both setup and have NEVER had an encrypted email go through because nobody else does it. It doesn’t matter what Proton claims to support.
That’s it. Telling anyone to read up on anything when they’re 100% correct is asinine.
Email in transit is not encrypted. At least not encrypted by anything that the government can’t compel the company to hand over.
Edit:
Email in transit is not encrypted. At least not encrypted by anything that the government can’t compel the company to hand over.
This is what I originally said. It was clear. I don’t know why you’re arguing otherwise.
Yeah, OPSEC is really important and over the years many people got caught because of bad OPSEC. PomPomPurin, the guy who ran BreachForums is a pretty good example of this: https://youtu.be/1fZWHeHICws
This is non-news, like all tech companies, they are bound by law to do this. It happens more than 6000 times per year for Proton. However, this user just had bad opsec. Proton emails are all encrypted and cannot be read unless law enforcement gets your password, which Proton does not have access to. Even if Proton hands over all data.
Often they just need the user behavior data such as login date and time
Email in transit is not encrypted. At least not encrypted by anything that the government can’t compel the company to hand over. Your password as best can only lockdown the mailbox itself. Not the receipt/sending of emails.
Edit: The point being is that if you’re a person of interest, the government can just watch your activity until they get what they want. And Proton doesn’t really have anything they can do about it other than a canary page I suppose.
Edit2: to make it even more clear, I’m talking about MTAs communicating with each other. Proton being one party would have the keys to their side of the communication which is sufficient to decode the whole lot.
That there is what I call horse shite. SMTPS and STARTTLS are a thing and if you are using a provider who doesn’t use it you need to change.
That still requires the email to be in clear text before it gets re-encrypted by Proton mail. SMTPS gets terminated at your email provider’s boundary.
Unless it’s pgp
Pgp does not encrypt the whole email, only part of it.
IF TLS is used AND configured optimally on both ends, THEN the in transit message contents should be very secure, in that transient session keys were used.
I would be interested to know how often those two preconditions hold true though.
Of course, this is only one small link in the chain. There aint no magic bullet.
Proton would have the key. A government that is already compelling them to hand over your account can simply be compelled to provide the TLS keys. The point is that government doesn’t have to compel proton for at rest storage, but can compel for in transit interception.
Read up on perfect forward secrecy and TLS.
And yes, a jurisdiction could compel them to break their security, depending on laws and ability to threaten.
“read up on pfs”
“Pfs doesn’t matter”
Literally this post.
PFS matters where a party hasn’t already been compromised. Not so hard.
This whole discussion is about a government forcing Proton mail to take actions. Telling me to “read up on pfs” is irrelevant by your own admission. ProtonMail can be compelled to give up their keys, or to hand them over for all current/future transactions.
So once again…
You cannot rely on MTAs to transmit ANYTHING securely in the context of this discussion. Period. There is no E2E when there’s an MTA involved unless you’re doing GPG/PGP or S/MIME. Nobody does this though… Like literally nobody. I’ve got both setup and have NEVER had an encrypted email go through because nobody else does it. It doesn’t matter what Proton claims to support.
That’s it. Telling anyone to read up on anything when they’re 100% correct is asinine.
Edit:
This is what I originally said. It was clear. I don’t know why you’re arguing otherwise.
Yeah, OPSEC is really important and over the years many people got caught because of bad OPSEC. PomPomPurin, the guy who ran BreachForums is a pretty good example of this: https://youtu.be/1fZWHeHICws
Here is an alternative Piped link(s):
https://piped.video/1fZWHeHICws
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.