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?
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.
That’s a completely different use case then, and the solution is Tor, proxies, ShadowSocks, vpn-ws.
But if you can’t HTTPS, it’s weird that you’d be able to do a VPN in the first place. HTTP only is super rare outside of China, and most places HTTPS would be blocked, VPNs are even more blocked
I mean technically you could encrypt most of the stuff client-side but you have to keep in mind the browser loading JavaScript over HTTP is still insecure and it would be easy to modify the script to also send the key to your attacker. There’s nothing you can do that would be better than what the browser can do.
The only way to make it safe is to not have a web application. The code must already be on your device in a state you trust to be able to trust anything else that depends on it.
An easy fix might be to configure your browser to use your server as a plain HTTP proxy, which will issue CONNECT commands for HTTPS automatically, and now you’re in HTTPS world and you’re good.
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.
I may at times only have access to HTTP only (No HTTPS)
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.
My understanding is that HTTPS is “secure” for basic use … But not secure from five eye agencies
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.
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
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.
nor can anyone snooping the packets in transit know what is going on
This is what HTTPS and VPN connections provide already.
Not know the HTML structure, form field data, etc.
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.
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.
I feel like you should just use a reverse proxy tbh.
Is it internal? Because otherwise this is a super bad plan
And you cant use self signed certificates because?
They provide the same level of encryption. The benefit of a domain and a trusted CA issued cert is that browsers/os will automatically trust that the server is who its said it is (ie you dont get a warning).But if you import your servers root CA to your OS, then your OS (and browser) will automatically trust any cert issued using that root cert, thus you dont get a warning.
With or without a warning, it will still encrypt at TLS1.3
How would it be stronger than HTTPS?
What makes it stronger than HTTPS?What is the attack vector you are trying to protect against?
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.
Mega is a good example of what I want to learn to create. Not just to transfer files, but for what text is displayed on the page and the form field values and have it so that the server admins cannot decrypt and is encrypted this data in transit.
I mean, the server would need to have the private keys in order to encrypt the data right
The idea is that the keys are client-side. You send them to the server encrypted, and it serves it back to other clients who have the password entirely client-side as well, and decrypts it.
It’s basically what encrypted chat apps do: all they have is metadata but the payload is completely opaque to the server. It could just be a file of
/dev/urandomfor what it knows.
I had no idea mega did that, that’s awesome. The whole idea that the server doesn’t have the key, like – it’s so simple, but it never occurred to me. Why would the server ever need to decrypt it?
This shit is wrinkling my brain.
And I’m even more mad at every cloud provider. Why you decrypting my shit, Google?
So I guess the question is, for your site idea, where does the encryption start? Like, you want the text on the page and the form data encrypted, but, is the text on the form’s submit button encrypted? If it is, your user has to be a developer to some extent, or you needs to build like a WordPress style wysiwyg editor that also encrypts everything – and, like, that’s kinda cool, but actually writing that code sounds like torture. I’d rather spend all that development time giving myself papercuts and squirting lemon juice into them.
So an encryption “barrier” has to exist. The Mega server doesn’t decrypt your file, but it knows that it’s getting a file of some kind for you, and it knows the shape of the data. It’s not completely ignorant – and, like the WordPress problem above, you could prevent that – keep the server from even knowing what it’s doing – again, kinda cool, but it sounds like torture to actually write.
So the question is, where are you putting that barrier? It seems like, wherever that barrier is, is also how deep a non-developer user can get into using it. To put that another easy: the more of the site’s content that’s encrypted, the more development skills the user has to have.
Or I’m just misunderstanding your project entirely, which I will attribute to the fact that it’s 1am.
Mega uses your account password to decrypt a master key, they only store the encrypted master key on the servers. And all the files you upload and download are decrypted with the same key, and the password never leaves your browser. Thus Mega doesn’t have any visibility in the contents of the files and doesn’t have the ability to decrypt the key nor the files.
It’s fully transparent to the user, no skills required. It pretty much just works. The only downside is if you lose your password your files are gone, there’s no password recovery. And of course if your password leaks, 2FA doesn’t get you very far.
And it’s an extremely bad customer experience to be unable to restore your user’s files, so it doesn’t get used that often because users don’t care. They trust the company and don’t care how safe or unsafe it is, but they want their files to be there without hassles.
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)
What about https is not strong enough for your application?
