i'm working through a head-scratcher about https certificates, zerotier tunnels, nginx reverse proxies, iframes, cryptpad, and yunohost, if anyone feels nerd-sniped by these topics. I suspect I'm missing a detail about how https and reverse proxies actually work
@notplants why is there an iframe? Where is it defined
I think the problem is caused by the iframe, not the tunnel or the TLS.
These apps are just configured to refuse to run inside iframes, it looks like. So getting rid of the iframe should fix it
@forestjohnson the iframe seems to just be how the cryptpad software was written -- I didn't add anything to it.
you can see it by inspecting https://crypt.commoninternet.net
there is an iframe with the src of https://sandbox-crypt.commoninternet.net
if you go directly to https://sandbox-crypt.commoninternet.net then it says this sandbox app was not meant to be used directly
-
I'm not sure why cryptpad uses this iframe design, but maybe there is a reason?
the case with the onlyoffice iframe within nextcloud is also just part of how the integration is written
@notplants oh wtf. Interesting. Sorry, can't check out the sites rn, I'll take look later. Maybe browser origin issues then? Are they on different domains inside vs outside the tunnel ?
<3 @forestjohnson for both of my tests i've been using the same domain names on both sides of the tunnel
@notplants ugh wtf is this software doing. U really nerd sniped me here, I thought it would be simple but obviously its not
@forestjohnson im still head-scratching over here too
@notplants i think this header is the problem. maybe the tunnel is adding that ?
You can check by viewing the HTTP traffic at various different points. Its easy to do if its plain http with no tls. my favorite tool to do it: https://git.sequentialread.com/forest/httpflow
watch the response headers coming out of the http server and also watch the response headers on the VPS server.
httpflow should work on the app server.
If the tunnel connects to the app server via HTTPS, you might not be able to use httpflow there.
then in the browser you just use the network tab instead of httpflow.
@forestjohnson need to go now, but going to dig more into this later. ty for the ideas
@notplants btw for context, im just guessing again here, but i know that `X-Frame-Options: SAMEORIGIN` is a common "security hardening" header that a lot of things will just blanket apply to everything. It just happens to break cryptpad. IDK why the hell cryptpad uses an iframe tho. IMO thats probably a bad idea, it makes the software more complex. I guess maybe they have to in order to easily integrate onlyoffice or whatever it is ?
@notplants @forestjohnson @j12i ahhh, glad you got this figured out! that makes sense, and good to file away for next time i end up helping someone with yunohost :)
and fwiw i think cryptpad doing the iframe stuff is pretty reasonable, it's for sandboxing purposes (isolating the parts of the code that handle security sensitive crypto stuff and touch keys from the bigger "application" code that is more likely to have bugs). would be great if browsers provided better ways of doing that but alas, hosting on separate domains and using frames is the best there is at the moment.
@notplants @forestjohnson @j12i https://docs.cryptpad.org/en/dev_guide/basics.html#content-security-policy-csp-and-security describes the sandboxing and security model stuff in a little more detail
@alive @notplants @j12i right, that's kinda what I meant by "cryptpad has to use the iframe to integrate with onlyoffice",
Its cuz they don't trust onlyoffice, lol. They want to sandbox it, hence the sandbox domain name. Smart to do such a thing I guess, but as we can see, it significantly increased the complexity of the app and caused issues at the level of the http infrastructure, aka, page won't load, displays network error in browser.
So I'd say this should be a cryptpad feature request, to validate that x-frame-options is absent or set correctly before trying to load the iframe. If cryptpad wants to do weird indulgent things with http its their responsibility to handle errors with that as well...
And idk how much a sandbox like this really buys you in a web browser... I guess maybe they can stop it from phoning home by using a CSP? But it can still use things like webrtc based on what I'm reading.... So really this isn't a "seal", its just a relatively low fence. Is it worth it? Idk... I guess if you want onlyoffice, there's no substitute..
But I'd also argue that if you want security, there is no substitute for simplicity and usability, especially for the server admin. I focused on simplicity for my e2ee web app: https://git.sequentialread.com/forest/sequentialread-password-manager
And issue on yunohost repo as well
I think this issue might be a little unfair to yunohost because my setup is kind of unusual and maybe not entirely what they are building for
if you just install cryptpad on a yunohost server directly it will work
the issue is my setup was yunohost (vps) with a reverse proxy to a tunnel to cryptpad running on my homeserver
although could see this as not ideal (?) specifically for the "redirect_ynh application for yunohost" ... maybe the reverseproxy/redirect app shouldn't be adding any of those headers if they are explicitly set
but i've heard ynh say elsewhere they are not really trying to support "custom use cases" like mine, which I kind of get -- it seems like getting ynh to work smoothly for people using it in the standard way is already a huge task
for this reason, I still think at somepoint I should look into a different gateway solution, that is more fit-to-purpose and could have less unexpected complexities
mostly though for now, I'm happy its working, glad i got to learn a bit about reverse proxies, sandboxes, and http headers
and am generally appreciating the good will of y'all / /the internet / the fediverse. kind of crazy to go online and collaboratively solve a puzzle like this
> kind of crazy to go online and collaboratively solve a puzzle like this
IDK I don't think its weird at all. AFAIK this has been the norm since the beginning of the internet , web2.0 and platforms just kind of pushed it into the margins. But I'm 33 and I've been part of this kind of internet Puzzle-solving for 20 years now. So to me it's not weird at all.
I'll go and edit that GitHub issue maybe close it later.
@forestjohnson with cryptpad the iframe is not an external integration, but its own thing. so they have chosen this fate for some reason lol
with nextcloud+onlyoffice, yes the iframe probably was just a way to embed the integration
@forestjohnson your intuition about someone tacking on `X-Frame-Options: SAMEORIGIN` as a general security hardening thing was correct and enough for me to figure out the issue :)
I ran `grep -r "X-Frame-Options" /etc/nginx` on the VPS and found an additional nginx config in /etc/nginx/conf.d/security.conf.inc where this header was being tacked on
I commented this out, as well as a few other headers it was tacking on, and now cryptpad and nextcloud+onlyoffice are working just fine
I assume this security.conf.inc config is created by yunohost on the VPS, even though I don't actually want it for my usecase
I guess this a downside of my setup using yunohost on the VPS as the gateway, which is really more multi-purpose than my specific usecase and has extra junk
cc @j12i @alive