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?
How would it be stronger than HTTPS?
What makes it stronger than HTTPS?What is the attack vector you are trying to protect against?
What about https is not strong enough for your application?
Unless you want to go with multiple layers of encryption, there is nothing significantly “stronger” than TLS 1.3 at the moment. And multiple layers are only used for anonymity, for example in Tor. Having multiple layers between just two endpoints without intermediary steps does not make anything significantly better.
Other examples include mega, which encrypts all files it stores for clients on the client side, and then never transfers the key. This way, the client’s data is E2EE in the sense that only the people with the link can read it, but the mega servers can’t.
HTTPS is already end to end encrypted. It’s literally what it’s for. TLS is everywhere: SMTP/IMAP (emails), even OpenVPN.
What about it are you trying to improve on? There ain’t much you can do on a website, if the connection is intercepted then everything falls apart because the attacker already has the ability to modify whatever your server is sending, so any encryption you’d do in JS is compromised before it even runs.
If you can make an app, then you can do something called certificate pinning which effectively gives the client the public key of the server to expect. It guarantees that the client will only talk to the right server, and if that is broken, then literally everything is broken and nukes are probably about to get launched.
Most encryption uses the same primitives: RSA/ECDSA/DH to derive a stream cipher and then it’s pretty much always AES these days, or sometimes ChaCha20, and usually SHA1 (broken) or SHA256 for message authentication.
E2EE makes senses when you’re building say, a messaging app. There the E2EE is that the user’s device holds the keys, so even the server can’t see the message even as it stores it and sends it to the other device.
I may at times only have access to HTTP only (No HTTPS) which is one of the reasons why I want another form of encryption.
Encryption with most VPNs are more secure than HTTPS. Yes, the connection between the VPN server and the web server is not encrypted with the VPN and only HTTPS. However the encryption between the VPN and personal device is superior, not because it is relayed. My understanding is that HTTPS is “secure” for basic use, just like Windows 11 is secure. But not secure from five eye agencies unlike VPNs and other like systems like Tor and I2P.
My goal is to have a user connect to a web server and have it not possible for the web server to know what is going on, nor can anyone snooping the packets in transit know what is going on. Not know the HTML structure, form field data, etc.
Why do you only have access to http? Knowing that would help guide answers.
I may not have a domain name, and therefore no HTTPS, just HTTP only and can only connect by knowing the IP address and port number.
Honestly I would rely on just using HTTPS if you can, it’s very easy to get crypto stuff wrong.
My old self-implemented encryption implementations were absolutely horrible. I did not understand what salting was, IVs, or any of that. Most of which I still don’t. The application I developed at the time was using AES, a symmetric encryption algorithm, which meant that if you were to decompile or take it apart, you’d have access to the same keys being used by the backend server - meaning that while data was technically “encrypted”, all the keys were freely accessible to decrypt any traffic that was intercepted. Thankfully the application (an offsite smartcard authentication client) has been long been put out of use, and the backing infrastructure no longer exists.
Aside from that, here’s an interesting write up of how Valve used a javascript RSA implementation prior to HTTPS being as widespread as it is now: https://web.archive.org/web/20210108003523/https://owlspace.xyz/cybersec/steam-login/ (provided archive link as original site no longer exists). RSA is not a symmetric algorithm so worked fine for this, at least for back then in that time period.
If you would still prefer to not use HTTPS, I would strongly recommend using something well known and popular, like Signal’s battle tested E2EE protocol (used for RCS messages and WhatsApp messages)
