Is there a way to develop and website using JS (and perhaps PHP) to create an E2EE website. Were all packets sent between the server and the userw device are E2EE, wrapped in a layer of encryption?
I know there is HTTPS but I am looking for something stronger than HTTPS.
By using some JS or PHP E2EE package, would I have to write or structure the website code very differently than you normally would?
You’re really kinda conflating a bunch of different problems here, so I think you need to focus down what you’re really interested in accomplishing.
If you don’t have access to HTTPS, you can maybe make something to fill that gap through JS, but it’s gonna involve hijacking and re-implementing MOST of the functionality of the browser. There is almost certainly a more-effective solution to solve the lack of HTTPS.
I think the point you’re trying to get at here is that the encrypted connection is only as secure as its endpoints. Traffic encrypted over HTTPS is no less “secure” in itself than traffic over a VPN, but the security ends at the HTTP server, and you may or may not trust the owner of that server to keep your data secure from outside parties. There really isn’t any difference between an HTTP server and a VPN server in this context, except that VPN providers tend to care about privacy more than general-purpose web host providers, because that’s kinda the selling point of VPNs for most people. A VPN provider could still be vulnerable to a legal request to collect and/or hand over data they have on you.
Sure, you’re basically describing an E2EE messaging app, and this is different than HTTPS and VPNs, because the server sitting between two clients isn’t an endpoint of the encryption, only the two clients are. Private keys are stored on client devices, public keys are exchanged, and all “data” moving out of the client is encrypted to be only decryptable by the client intended to receive it. The server doesn’t have any of the private keys, so can’t decrypt anything.
This is what HTTPS and VPN connections provide already.
In theory, you could accomplish this by delivering an initial payload of a mostly-empty HTML document, and some JS capable of bootstrapping an encrypted “connection” to the server, using only low-level browser network APIs. You likely wouldn’t be able to encrypt most of the traffic, just the HTTP data payloads. Once the initial “connection” is established, then the server delivers the rest of the app itself, mainly JS SPA that renders everything locally.
In practice, you’ve basically just re-invented HTTPS, but worse.
And it’s useless anyway because if the connection is unsafe, the script that does the client side encryption is already assumed compromised as well. It could be altered in transit to use a weak or known key. Or send back the keys to the attacker.