Proton Mail may log IPs if Court Ordered

noko said:
If you encrypt your own data and then put it on a Cloud server (Centralized) does not matter who looks at it. Now if your system is not secure or you don't have a layered approach as in an offline system that creates the data and encrypt as an example which is then transferred through a connected system, meaning you can have a system that cannot be bypassed easily. Off course if your system is robbed, taken by someone, compromised etc. -> bypassed.

A decentralized database is not controlled by anyone nor can anyone control it. That is what makes Crypto ( the good coins so to speak) unique. Talking about blockchain technology. You can have a totally decentralized database where no one really knows where any of the data is or what is on it other then the owner(s).

https://coinmarketcap.com/alexandria/glossary/decentralized-database
Click to expand...
In the current scenario of this thread, no one know the content either (or the vpn traffic example either I think), what have been known and use was who talked to who, which in fully public decentralized system seem rip to happen has well, no ?

Securing the actual data was not compromised here.
 
LukeTbk said:
In the current scenario of this thread, no one know the content either (or the vpn traffic example either I think), what have been known and use was who talked to who, which in fully public decentralized system seem rip to happen has well, no ?

Securing the actual data was not compromised here.
Click to expand...
I would say that depends how it is set up if public or not. How the data keepers get paid and the protection would not be much different than Crypto consensus mechanism where you would have to have 51% of the network to be able to do an effective hack except the data would never be recoverable in this case since encrypted. Here are some examples, I have not really studied this at length:

https://cryptoverze.com/best-decentralized-cloud-storage-networks/

Filecoin is ranked #23 now on the Crypto charts:
https://filecoin.io/
 
Last edited:
Lakados said:
Yeah it fakes the security certificates and man in the middles the whole thing.
It’s a very common tool on corporate networks otherwise you couldn’t secure them. All sorts of viruses and keyloggers encrypt their network traffic to avoid detection and any bad actors who could be leaking sensitive data would just need to connect to a secure site and you couldn’t monitor any of their uploads or any number of other scenarios.
Short description from the Palo Alto site on the subject: https://docs.paloaltonetworks.com/p...w.html#idd71f8b4d-cd40-4c6c-905f-2f8c7fca6537

"Palo Alto Networks firewall decryption is policy-based, and can decrypt, inspect, and control inbound and outbound SSL and SSH connections. A Decryption policy enables you to specify traffic to decrypt by destination, source, service, or URL category, and to block, restrict, or forward the specified traffic according to the security settings in the associated Decryption profile. A Decryption profile controls SSL protocols, certificate verification, and failure checks to prevent traffic that uses weak algorithms or unsupported modes from accessing the network. The firewall uses certificates and keys to decrypt traffic to plaintext, and then enforces App-ID and security settings on the plaintext traffic, including Decryption, Antivirus, Vulnerability, Anti-Spyware, URL Filtering, WildFire, and File-Blocking profiles. After decrypting and inspecting traffic, the firewall re-encrypts the plaintext traffic as it exits the firewall to ensure privacy and security."
Click to expand...
That is interesting, as modern TLS/SSL certs along with HSTS are supposed to be able to prevent MITM attacks, and even if you spoofed a legitimate endpoint's public key, I don't understand how you would be able to decrypt the data without the endpoint's private key. Looking at the article, it seems that the client must accept the firewall certs as a trusted third party, so I assume it would proxy data through its own HTTPS endpoint. So if I attached a non-domain computer inside your network that didn't have a policy to explicitly accept your firewall's certificates as trusted, this technically shouldn't work (not taking into account your network ACL/authentication rules which should deny unauthenticated users access anyways)? I'm curious.
 
Anti-virus can do this as well, basically MITM. When you connect to a webpage (even HTTPS) you are creating a secure tunnel to the proxy/security device, and then that device connects via a secure tunnel to the actual website.

It does this by adding the proxy/security cert as trusted on your computer, so you are still connecting via HTTPS, but with the proxy in the middle that will be able to decrypt the data with their key, so they see everything.

Also good to know if you run anti-virus that blocks malicious websites, they might use this technique meaning your privacy may be at risk (if you don't trust your security software).
 
cybereality said:
Anti-virus can do this as well, basically MITM. When you connect to a webpage (even HTTPS) you are creating a secure tunnel to the proxy/security device, and then that device connects via a secure tunnel to the actual website.

It does this by adding the proxy/security cert as trusted on your computer, so you are still connecting via HTTPS, but with the proxy in the middle that will be able to decrypt the data with their key, so they see everything.

Also good to know if you run anti-virus that blocks malicious websites, they might use this technique meaning your privacy may be at risk (if you don't trust your security software).
Click to expand...

Some browsers will not use the local certificates trusted on a PC, so if you use a browser that only uses it's internal cert stores (I believe Chromium on Linux may be one of them), or even a VPN provider application to connect with its specific cert only, wouldn't these apps not be forced to accept these MITM certificates used by antivirus / firewall applications (unless applied specifically by domain / local policies)?
 
unfortunateson said:
That is interesting, as modern TLS/SSL certs along with HSTS are supposed to be able to prevent MITM attacks, and even if you spoofed a legitimate endpoint's public key, I don't understand how you would be able to decrypt the data without the endpoint's private key. Looking at the article, it seems that the client must accept the firewall certs as a trusted third party, so I assume it would proxy data through its own HTTPS endpoint. So if I attached a non-domain computer inside your network that didn't have a policy to explicitly accept your firewall's certificates as trusted, this technically shouldn't work (not taking into account your network ACL/authentication rules which should deny unauthenticated users access anyways)? I'm curious.
Click to expand...
In the case of my network all machines we own have the certs pre installed via their MDM systems. Anything that doesn’t have the needed certs gets automatically pushed over to our guest network which has so few outbound permissions it’s not an issue security wise.
But the TLS 1.3 doesn’t prevent SSL decryption it prevents it from being accomplished via a passive proxy, so you need to use a terminating proxy server and not a non terminating one.
I’ve got that upgrade planned for next summer as I need a bit more hardware to prevent there from being a noticeable delay when loading pages.
But as the hardware exists as my outbound gateway it’s still physically there in the middle to intercept the required keys for decryption.

SSL decrypt is a long long topic, and I barely understand how it actually does what it does but I can say it works and works well and my licensing for it is in no way cheap.
 
unfortunateson said:
Some browsers will not use the local certificates trusted on a PC, so if you use a browser that only uses it's internal cert stores (I believe Chromium on Linux may be one of them), or even a VPN provider application to connect with its specific cert only, wouldn't these apps not be forced to accept these MITM certificates used by antivirus / firewall applications (unless applied specifically by domain / local policies)?
Click to expand...
Not quite, I won’t pretend to fully understand how it works but part of the process is to intercept the key. The needed hardware in this case functions as the inbound/outbound gateway so it can steal the keys as they are being broadcast out. The new systems make the entire process blind to the desktop device so no certificate is needed to be implicitly accepted by the client. But if you don’t have the network hardware configured correctly then you will introduce noticeable delays on page loads that will make everybody think the internet is not working.
 
Lakados said:
In the case of my network all machines we own have the certs pre installed via their MDM systems. Anything that doesn’t have the needed certs gets automatically pushed over to our guest network which has so few outbound permissions it’s not an issue security wise.
But the TLS 1.3 doesn’t prevent SSL decryption it prevents it from being accomplished via a passive proxy, so you need to use a terminating proxy server and not a non terminating one.
I’ve got that upgrade planned for next summer as I need a bit more hardware to prevent there from being a noticeable delay when loading pages.
But as the hardware exists as my outbound gateway it’s still physically there in the middle to intercept the required keys for decryption.

SSL decrypt is a long long topic, and I barely understand how it actually does what it does but I can say it works and works well and my licensing for it is in no way cheap.
Click to expand...

Lakados said:
Not quite, I won’t pretend to fully understand how it works but part of the process is to intercept the key. The needed hardware in this case functions as the inbound/outbound gateway so it can steal the keys as they are being broadcast out. The new systems make the entire process blind to the desktop device so no certificate is needed to be implicitly accepted by the client. But if you don’t have the network hardware configured correctly then you will introduce noticeable delays on page loads that will make everybody think the internet is not working.
Click to expand...
Thank you for the explanation, but I am curious if you install a browser or application that does not use system certificates, I very much doubt it would allow the connection through your firewall proxy. For example, a secure application going to a direct endpoint would not be secure any more if it read/allowed certs from the local machine to influence its communication. I would assume you've had to make at least a few exceptions for vendor applications/servers? Again, these are edge-case scenarios because, as you said, policies push out your certs, unauthenticated users get pushed to a guest net, and users shouldn't be able to install applications. Still, I'd be curious to test it...
 
unfortunateson said:
Thank you for the explanation, but I am curious if you install a browser or application that does not use system certificates, I very much doubt it would allow the connection through your firewall proxy. For example, a secure application going to a direct endpoint would not be secure any more if it read/allowed certs from the local machine to influence its communication. I would assume you've had to make at least a few exceptions for vendor applications/servers? Again, these are edge-case scenarios because, as you said, policies push out your certs, unauthenticated users get pushed to a guest net, and users shouldn't be able to install applications. Still, I'd be curious to test it...
Click to expand...
You can to some degree if you were to set up your own proxy server and you run Wireshark on it if you start monitoring your traffic going out through Wireshark the first part of the communication going out will have your part of the secure Key.

Something I need to check some time is if I try it on a machine that is on my domain and not on my guest network that doesn't have the security certificates if I inspect the certificate on the site will it show a spoofed one for the site or will it just show one of the certs from the Palo Alto appliance. I believe it is supposed to show it's key, though that key will still read as a valid key so the only way to see something was amiss would be to inspect the certificate and who it is issued to and compare it to who it should be issued to instead. But in either event, it should display as a valid key.
 
Yes, if you inspect the cert in your browser, it will show the proxy cert (still valid, but not the one for the real website).

This would be a sign that there is monitoring or a MITM is in place.
 
bigdogchris said:
But the questions remain - what's the difference between using a mail provider that logs your IP's vs one that only does when court ordered? The same information is given up. I'm not aware of mail providers handing over logged IP information without a warrant. You are really just "protecting" yourself from the ISP which you ultimately do not know if you can trust, anyways.
Click to expand...
Difference is one that does so when court ordered only has data from that moment forward, no history to provide.

Also it's still an encrypted email service, they can't get your emails from the provider.
 
cybereality said:
Yes, if you inspect the cert in your browser, it will show the proxy cert (still valid, but not the one for the real website).

This would be a sign that there is monitoring or a MITM is in place.
Click to expand...
Here is an example of a government attempt to MITM traffic by getting users to install its root CA: 🔓

MITM on all HTTPS traffic in Kazakhstan
https://bugzilla.mozilla.org/show_bug.cgi?id=1567114

Kinda creepy.
 
d3athf1sh said:
How does that make it any better? trash
Click to expand...

Realistically companies can't do much when they have a court order at their door. We say well how does it make it any better?

The observation is that no matter what you think, or someone says, if you have a connected device you are prone to being tracked. It may be harder in some cases than others but isn't that just reality?

I guess in terms of it (giving them the benefit of the doubt) they didn't track until their hand was forced. At that point it is a matter of how much is it worth to you to do business? Most of us are going to cooperate with them because we don't have the resources to fight it in court (even businesses) or we don't have the means to not be shut down by them.

You can hardly blame Proton for this. What we can attribute blame to and should be justly so is the way they are marketing their service. If that doesn't change then I would say trash all day long.

As it is, I think they are better than most in this respect. So I can cut some slack at this point.
 
Lakados said:
You can to some degree if you were to set up your own proxy server and you run Wireshark on it if you start monitoring your traffic going out through Wireshark the first part of the communication going out will have your part of the secure Key.
Click to expand...
I may set up a squid SSL inspection proxy and play around with this - as my understanding is that a public key for encryption is not meant to be "secure", meaning you would be able to get the public key and the encrypted data, but not be able to decrypt it without the private key on the server. To be clear, this is not describing your proxy scenario, where the client has a cert installed to believe the proxy is legitimate and then the proxy uses the public key to enact the transmission to and from the server. My belief is that, if the client's application does not validate a proxy certificate, then communication should simply fail, otherwise you'd have a worldwide cluster****, as SSL encryption could be bypassed for anyone, as long as a link in the chain could inspect the packets.

cybereality said:
Yes, if you inspect the cert in your browser, it will show the proxy cert (still valid, but not the one for the real website).

This would be a sign that there is monitoring or a MITM is in place.
Click to expand...

It may be a valid internal proxy cert, but it should ONLY be automatically accepted if the root authority has already been accepted on the client's workstation / application. Otherwise you should get the typical warning that the site is not secure, as it cannot validate it with a public authority.


ElementDave said:
Here is an example of a government attempt to MITM traffic by getting users to install its root CA: 🔓

MITM on all HTTPS traffic in Kazakhstan
https://bugzilla.mozilla.org/show_bug.cgi?id=1567114

Kinda creepy.
Click to expand...

That is creepy indeed, and seems to validate my previous sentence, that you must accept the proxy cert before the MITM can commence. How soon before they are able to spoof a public authority (or a public authority backed cert is/has already been given to governments for "safety" reasons) and/or systems in these parts of the world come pre-installed with these certs? It could already be happening AFAIK, and in that case, your data may be vulnerable unless you find a way to bypass the MITM proxy. Wipe your PC, pray that there is no hardware-based monitoring, smuggle in a starlink, good luck with that :hungover:
 
Last edited:
AaronGant said:
Difference is one that does so when court ordered only has data from that moment forward, no history to provide.

Also it's still an encrypted email service, they can't get your emails from the provider.
Click to expand...

Question - if Proton does not log IPs unless required to to do so with a court order, what is stopping them from logging user's credentials / decryption keys, if a court order tells them to do so? Logging user's credentials and/or data through the decryption process can be done on the backend through a bit of re-programming.
 
unfortunateson said:
Question - if Proton does not log IPs unless required to to do so with a court order, what is stopping them from logging user's credentials / decryption keys, if a court order tells them to do so? Logging user's credentials and/or data through the decryption process can be done on the backend through a bit of re-programming.
Click to expand...
Nothing at all, VPN's don't hide you they only change who is watching you, subtle difference but an important one.
 
Lakados said:
Nothing at all, VPN's don't hide you they only change who is watching you, subtle difference but an important one.
Click to expand...
Exactly, so if government reach gets to any website operator, there is absolutely no way to hide data, even claiming "we cant access data, it's encrypted" is a lie. Better have no backups and that instant meltdown button available for your db if you want real security in the face of pending exposure...
 
unfortunateson said:
Exactly, so if government reach gets to any website operator, there is absolutely no way to hide data, even claiming "we cant access data, it's encrypted" is a lie. Better have no backups and that instant meltdown button available for your db if you want real security in the face of pending exposure...
Click to expand...
I would probably go this route if you're worried about court issue subpoenas against your online activities.
 
obs said:
I would probably go this route if you're worried about court issue subpoenas against your online activities.
Click to expand...
For sure, although I referring to the service provider end. On the client end, you can torch everything, but your online presence, as exposed by the service providers you use (ISP, Microsoft, Facebook, Google, VPN, Protonmail, etc.), is only a warrant (or simple warrantless request from congress for some tech players who want to stay in their good graces) away from being exposed.
 
Nobu said:
If it was court ordered, and such orders are legal in the country they operate in, then there's not much they could have done aside from moving their HQ and/or servers.

Something else to keep in mind when choosing your "privacy oriented" company: even if they truly are putting in their best effort towards privacy, and doing a good job, if the jurisdiction they operate in allows courts to force them to do what they want, your data is only safe as long as they aren't interested in it.
Click to expand...
They imply their system was built so this isn't possible.
 
unfortunateson said:
Question - if Proton does not log IPs unless required to to do so with a court order, what is stopping them from logging user's credentials / decryption keys, if a court order tells them to do so? Logging user's credentials and/or data through the decryption process can be done on the backend through a bit of re-programming.
Click to expand...

I'm no expert in data encryption, but my understanding of public/private key & end to end encryption is that the people in the middle (eg. protonmail) never hold the keys to unlock the e-mails. The decryption process should only be possible on the recipients end. If all it took to undo encryption was a little 're-programming on the backend' then all encrypted communication would be a joke.
 
AaronGant said:
If all it took to undo encryption was a little 're-programming on the backend' then all encrypted communication would be a joke.
Click to expand...
Except for people that do their own programming for it (like big company and governement could or small expert individual)
 
Someone asked about VPN, I only use it to obviate regional blackouts for mlb.tv but NordVPN has worked for this for years after my friend in Canada that let me remote into his computer to watch it died.
 
AaronGant said:
I'm no expert in data encryption, but my understanding of public/private key & end to end encryption is that the people in the middle (eg. protonmail) never hold the keys to unlock the e-mails. The decryption process should only be possible on the recipients end. If all it took to undo encryption was a little 're-programming on the backend' then all encrypted communication would be a joke.
Click to expand...
Actually, it can take the simplest bit of reprogramming, at a base level. I write webpages and backend APIs that use password hashes and AES-encrypted data algorithms. When you log into any company's webpage, all that is required is for them to modify or create a different API endpoint and fetch your credentials you've entered from the webpage before verifying them with a hash and it's decryption key. Or, they can trivially intercept the data from the API before it returns to the webpage. Any company that claims they can't is lying. It may take a bit of re-engineering, but it is always possible, unless the company disposes all of its source code, didn't leave any back doors or vulnerabilities in its software, and completely forgets how to log into its webservers.

People can forget that encryption really is only "security" from third party interception, the server must know how to decrypt the data to show it to you on a webpage. Even if a company jumps through hoops and tries client-side obfuscation and encryption methods, they know the methods and the decryption roles from the backend, and can pull what they want.
 
Last edited:
Yes, at some point you have to trust the providers that they are doing what they say (and even if they've been audited, that they don't change the software or are forced to).

But, for email at least, you could PGP encrypt your messages (on your local machine, with open source tools) before entering them into the email client.

This would be pretty solid. No one could read the email, but they could still track metadata such as your IP or who you were communicating with.
 
AaronGant said:
I'm no expert in data encryption, but my understanding of public/private key & end to end encryption is that the people in the middle (eg. protonmail) never hold the keys to unlock the e-mails. The decryption process should only be possible on the recipients end. If all it took to undo encryption was a little 're-programming on the backend' then all encrypted communication would be a joke.
Click to expand...
Proton doesn't necessarily need to unlock the emails, emails have a sender and a destination. Proton may just be the middle man, if you have the IP's they came from or went to, then you can work on getting those machines through traditional means and problem solved. As much as IPs aren't people if you have proper hardware accounting and record-keeping on the ISP side of things you can very quickly narrow it down to a small grouping of people at the very least. And if Proton is both the sender and destination then it's just a matter of getting ahold of either end PC and you can walk it backwards, good chances those machines are heavily encrypted as well though so while they may not give any concrete evidence it very quickly narrows down a search.
 
Last edited:
unfortunateson said:
Actually, it can take the simplest bit of reprogramming, at a base level. I write webpages and backend APIs that use password hashes and AES-encrypted data algorithms. When you log into any company's webpage, all that is required is for them to modify or create a different API endpoint and fetch your credentials you've entered from the webpage before verifying them with a hash and it's decryption key. Or, they can trivially intercept the data from the API before it returns to the webpage. Any company that claims they can't is lying. It may take a bit of re-engineering, but it is always possible, unless the company disposes all of its source code, didn't leave any back doors or vulnerabilities in its software, and completely forgets how to log into its webservers.

People can forget that encryption really is only "security" from third party interception, the server must know how to decrypt the data to show it to you on a webpage. Even if a company jumps through hoops and tries client-side obfuscation and encryption methods, they know the methods and the decryption roles from the backend, and can pull what they want.
Click to expand...

Maybe I just don't understand, but I thought that if I encrypted something on my end with a private key then logged in and sent the encrypted data that someone couldn't just get my private key because I logged into a website and sent some data that wasn't the private key.
 
Lakados said:
Proton doesn't necessarily need to unlock the emails, emails have a sender and a destination. Proton may just be the middle man, if you have the IP's they came from or went to, then you can work on getting those machines through traditional means and problem solved. As much as IPs aren't people if you have proper hardware accounting and record-keeping on the ISP side of things you can very quickly narrow it down to a small grouping of people at the very least. And if Proton is both the sender and destination then it's just a matter of getting ahold of either end PC and you can walk it backwards, good chances those machines are heavily encrypted as well though so while they may not give any concrete evidence it very quickly narrows down a search.
Click to expand...

Yeah, I mean I guess if you've compromised all end points then what happens in the middle doesn't matter. I was trying to answer the question about what stops them from keeping encryption keys and just decrypting and storing the plain data. At the time I had thought I answered that correctly.
 
AaronGant said:
Maybe I just don't understand, but I thought that if I encrypted something on my end with a private key then logged in and sent the encrypted data that someone couldn't just get my private key because I logged into a website and sent some data that wasn't the private key.
Click to expand...

You are not wrong, if you were directly connecting to an uncompromised service/protocol from the client with your private key (maybe SSH as an example), but when you are going to a website, you login with a name and password that get verified via a company's API.

An example could be this: A bad actor duplicates the exact look of any webpage and sends you a link (these phishing campaigns happen quite often). Not checking the IP or other factors, you think it is legitimate so you click on it, try to log in, then their malicious API logs your username and password for the legitimate site. They now can log in to the legitimate site as you (if the legit site doesn't have geolocation IP checking / 2FA checking / etc., which can still be manipulated...but thats another topic). Now think of the actual company itself implementing this - no changes to the front end required, the IP and certs are all legitimate, but they change the backend API to do the same thing.

While Protonmail may be currently "secure" by not logging or reading any credentials as they pass through its APIs, it just takes a bit of alteration to no longer be this way.

To be clear, this is not breaking the crypto, it is getting the pertinent data either before or after the encryption/decryption process.
 
Last edited:
Lakados said:
Proton doesn't necessarily need to unlock the emails, emails have a sender and a destination. Proton may just be the middle man, if you have the IP's they came from or went to, then you can work on getting those machines through traditional means and problem solved. As much as IPs aren't people if you have proper hardware accounting and record-keeping on the ISP side of things you can very quickly narrow it down to a small grouping of people at the very least. And if Proton is both the sender and destination then it's just a matter of getting ahold of either end PC and you can walk it backwards, good chances those machines are heavily encrypted as well though so while they may not give any concrete evidence it very quickly narrows down a search.
Click to expand...
I assume that using the MITM proxy as you do in your company, you'd be able to see the unencrypted TCP/IP data through the HTTPS connection, then, if desired, take the time to piece together the HTML/JSON/JS bits and retrieve the data sent to a client workstation (unless your firewall can give you a direct preview)? That is pretty dang cool.
 
unfortunateson said:
You are not wrong, if you were directly connecting to an uncompromised service/protocol from the client with your private key (maybe SSH as an example), but when you are going to a website, you login with a name and password that get verified via a companies' API.

An example could be this: A bad actor duplicates the exact look of any webpage and sends you a link (these phishing campaigns happen quite often). Not checking the IP or other factors, you think it is legitimate so you click on it, try to log in, then their malicious API logs your username and password for the legitimate site. They now can log in to the legitimate site as you (if the legit site doesn't have geolocation IP checking / 2FA checking / etc., which can still be manipulated...but thats another topic). Now think of the actual company itself implementing this - no changes to the front end required, the IP and certs are all legitimate, but they change the backend API to do the same thing.

While Protonmail may be currently "secure" by not logging or reading any credentials as they pass through its APIs, it just takes a bit of alteration to no longer be this way.

To be clear, this is not breaking the crypto, it is getting the pertinent data either before or after the encryption/decryption process.
Click to expand...

Ok, yeah, they'll have your login and password information, you've got to send that to login. My understanding was that the text of the e-mail was encrypted client side and proton never gets the key, keeping the data secure. I've not used their service, but I thought the encryption / decryption was done client side. Maybe I'm wrong on that and they're storing the keys somehow.
 
AaronGant said:
Ok, yeah, they'll have your login and password information, you've got to send that to login. My understanding was that the text of the e-mail was encrypted client side and proton never gets the key, keeping the data secure. I've not used their service, but I thought the encryption / decryption was done client side. Maybe I'm wrong on that and they're storing the keys somehow.
Click to expand...
This may well be the case, but the only way a client would be able to decrypt the data is if the server gave it a decryption key in the first place (it could be something as simple as a mutated combination of backend decryption string with a unique identifier/timestamp generated on the client when you log in, for example). Nothing stops Protonmail from the ability to log this key at any point, especially considering they are the ones who write the methods that orchestrate how data passes between the client and server.

Any client side encryption / decryption is pure obfuscation, as this code can be viewed directly on the client.
 
Last edited:
unfortunateson said:
This may well be the case, but the only way a client would be able to decrypt the data is if the server gave it a decryption key in the first place (it could be something as simple as a mutated combination of backend decryption string combined with a unique identifier/timestamp generated on the client when you log in, for example). Nothing stops Protonmail from the ability to log this key at any point, especially considering they are the ones who write the methods that orchestrate how data passes between the client and server.

Any client side encryption / decryption is pure obfuscation, as this code can be viewed directly on the client.
Click to expand...

If they send you my public key and they send me your public key, we still only have our own private keys, right? Hasn't PGP been doing this for like 30 years?

or are we just as the point where the argument is that if you are decrypting the data on a device that isn't offline only then there's a possibility of the key and data on that device getting out?
 
AaronGant said:
If they send you my public key and they send me your public key, we still only have our own private keys, right? Hasn't PGP been doing this for like 30 years?

or are we just as the point where the argument is that if you are decrypting the data on a device that isn't offline only then there's a possibility of the key and data on that device getting out?
Click to expand...

I'm specifically referring to websites in this argument, and not to a direct protocol such as SSL / SSH. If websites did any client-side decryption, it would be through javascript, with the data first (re)encrypted and passed through a backend API. The client would not know how to decrypt the data without the key given to it at some point through the API. The API could encrypt the data in whatever format (PGP) it wanted, and the client could decrypt it (for example, through OpenPGP), but again, the client would require a decryption key given to it at some point in the process from the API.
 
Usually for websites that support E2EE, the private key is not stored anywhere (even on your local computer). It is generated on-the-fly by some method, typically using your password and running it through some sort of hashing algorithm.

This is why, for example, you can login on 2 different computers and still access your data (without having to manually copy a key file). However, this means that the private key is basically only as secure as your password.

And the password, as we know, can be compromised through keyloggers, phishing websites, etc. that blackhat hackers could use to intercept the communications.
 
You must log in or register to reply here.
Back
Top