đž Archived View for bbs.geminispace.org âē s âē Gemini âē 3233 captured on 2024-08-25 at 10:30:34. Gemini links have been rewritten to link to archived content
âŦ ī¸ Previous capture (2024-07-09)
-=-=-=-=-=-=-
I'm looking into writing a reverse proxy server which supports Gemini. ideally I'd like it to work like an HTTP reverse proxy like nginx or caddy, where it directs requests to different backend servers depending on the hostname.
The problem is... is this even really possible, given that client certs are a thing? How can the proxy serve the connection long enough to figure out a hostname, and still proxy it to the backend server with the original TLS session intact. The proxy can't fake that it has the client's cert key, after all.
2023-07-18 ¡ 1 year ago
đšī¸ skyjake [mod...] ¡ 2023-07-18 at 11:33:
The real client certificate of the requestor would only be available at the proxy. However, the proxy could generate a new, privately stored certificate of its own that represents each unique requestor, and make its reverse requests using those. So basically man-in-the-middling the connections. This should be generally fine if the generated certificates use the same subject/issuer fields, and these are your locally-run proxied services that only talk to the outside world via the proxy.
However, if the proxied service displays client certificate fingerprints, like many do, the user might be worried that they don't match the clientside fingerprints.
When it comes to the TLS sessions, the time it takes to do the reverse requests shouldn't be an issue. Clients will generally tolerate a delay of multiple seconds.
đ¤ alexlehm ¡ 2023-07-18 at 13:03:
I have considered that a bit since I have a go-based gemini server and wanted to access another server running in java on another port, but i don't think this is feasible when actually accepting the connection on the proxy. a nginx style forwarding before the full tls protocol is done might be possible to forward different vhosts to different backends. this will not work for path-based rules (similar to mod_rewrite) unless the backend connection uses a different protocol and passes the client cert has as a header or environment var, that would be more something like fcgi, not actual gemini
đģ mediocregopher [OP...] ¡ 2023-07-18 at 13:03:
MITM all connections would _technically_ work, but I think at that point I would just not support it. That would essentially tie the backend to the proxy permanently, if the backend does anything with client certs, which wouldn't work for my case.
But luckily, after a bit of research, it seems it's possible to do it transparently. Since the TLS Client Hello message is sent plaintext at the start of the message, the server should be able to read just that, parse it, then forward it and the rest of the connection to the correct backend.
â https://jean.ribes.ovh/gemini-reverse-proxy-using-traefik/#navbar-end
If traefik can do it, I can do it.
đ¤ alexlehm ¡ 2023-07-18 at 13:04:
I should say that a HTTPS reverse proxy would have the same problem if a client cert is used
đšī¸ skyjake [mod...] ¡ 2023-07-18 at 15:07:
Forwarding the connection does sound like a much better solution. It is beyond my level of expertise to evaluate whether it's a good idea, though... A reverse proxy that forwards TLS connections without modifying them seems like something that is pretty much protocol-agnostic?
đģ mediocregopher [OP...] ¡ 2023-07-18 at 15:48:
An HTTPS reverse proxy _would_ have the same problem if client certs were used, but fortunately (for http proxies) http client certs aren't really a thing.
And @skyjake yeah, it's a pretty protocol agnostic solution, which I guess is why traefik supports it despite almost certainly not deliberately supporting gemini. But it also precludes modifying HTTP headers on requests and such (like adding X-Forwarded-For), which I guess is why it's not more common in http proxies.
âī¸ mozz ¡ 2023-07-18 at 18:20:
Peaking the TLS SNI is the best way to go. The disadvantage is that if the client doesn't send the SNI, or if the SNI doesn't match the actual URL inside the gemini request, you're kind of screwed.
Also check out the PROXY protocol, which allows you to attach client information like the true IP address in the absence of having access to HTTP headers. I added support for this to jetforce although I'm not using it currently.
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
đ norayr ¡ 2023-07-21 at 12:24:
hello, i am trying to understand, if we have such a solution now?
based on what i read (and hopefully understand) i would prefer a server that forwards requests to different ports depending on domain name. but without doing mitm, i guess it can just forward everything back and forth?
đ norayr ¡ 2023-07-21 at 12:25:
i as referred to this thread
đ¤ alexlehm ¡ 2023-07-21 at 14:30:
@norayr the problem is that the proxy has to determine the hostname in the unencrypted part of the TLS protocol, which apparently works, but it unusual (the solution provided by relayd seems to work)
đ Addison ¡ 2023-07-21 at 18:06:
â => Here's an NGINX config that uses SNI to do what you're asking. Cheers
đ norayr ¡ 2023-07-21 at 20:39:
relayd? hmmm... did anyone already configure some capsules like that? can i find some example configurations somewhere?
đ norayr ¡ 2023-07-21 at 20:45:
omg let me see!
đģ mediocregopher [OP...] ¡ 2023-07-22 at 06:16:
@norayr I'm not sure why relayd was brought up, but both the link about traefik that I posted earlier and the nginx config that Addison posted should be able to help
đ¤ alexlehm ¡ 2023-07-22 at 09:40:
@mediocregopher sorry that was mentioned somewhere else on the same topic, I confused the "channels"
đģ mediocregopher [OP...] ¡ 2023-07-24 at 17:32:
To follow up: I wasn't able to do transparent TLS proxying in rust+tokio due to the tokio_rustls crate not supporting it, ended up implementing it myself
â https://github.com/rustls/tokio-rustls/issues/6
đ norayr ¡ 2023-07-26 at 06:42:
thank you for sharing. i looked at your code and issue comments and tried to understand it all. it looks like you have made a significant effort with a relatively new to you language, thank you for that too.
let's see how it continues. we need a reverse tls proxy tool.
i perhaps would use such a tool with more enjoyment if i knew it is written in go, since i percieve it as more simple and modernistic language (from what we have in the mainstream) just like i perceive gemini to be simple and modernistic. but rust is fine.
đģ mediocregopher [OP...] ¡ 2023-07-27 at 06:14:
As someone who primarily writes go, I totally agree with you :) but the project I'm working on is in rust, to help me expand my skillset a bit. I think the same strategy I've employed here could be done in go even easier, using a TeeReader
đ norayr ¡ 2023-07-27 at 10:25:
oh so nice to hear it. well, let's see if they accept your changes, and if not then i am glad there is a go project you can contribute to.
đ norayr ¡ 2023-07-27 at 21:59:
i am following the issue and i see you created another branch. waiting to get the solution, hopefully it'll compile for me, and configure several virtual hosts for gemini on my server.
then i would move everything possible to gemini, and proxy with kineto.
đģ mediocregopher [OP...] ¡ 2023-08-09 at 15:01:
Some final closure on this thread, thanks for all the input everyone!
â mediocregopher.com/posts/domani.gmi
đ norayr ¡ 2023-08-10 at 21:33:
so what happened in issue #6 of tokio-rustls? how did it end? did they accept your changes?
what is the solution if i want to do the same, i. e. host several of my gemini domains on one machine?
đ norayr ¡ 2024-01-04 at 23:12:
@mediocregopher, i tried the traefik configuration inspired by what you linked:
i struggled to understand your configuration actually. my understanding is that traefik should listen on 1965 and redirect based on SNI to let's say 1966 or 1967 - to other ports where gemini servers that serve different domains are listening.
so i tried this:
entryPoints:
gemini:
address: ":1965"
tcp:
routers:
capsule1:
entrypoints:
- "gemini"
rule: "HostSNI(`norayr.am`)"
service: "norayr"
tls:
passthrough: true
capsule2:
entrypoints:
- "gemini"
rule: "HostSNI(`xn--y9a5bft.xn--y9a3aq`)"
service: "sona"
tls:
passthrough: true
services:
norayr:
loadBalancer:
servers:
- address: "127.0.0.1:1966"
sona:
loadBalancer:
servers:
- address: "127.0.0.1:1967"
i have properly configured norayr.am on 1966, and it works if i go to it separately.
however when i enter just gemini://norayr.am, Lagrange sees that Traefik is providing its own default certificate ("CN = TRAEFIK DEFAULT CERT") instead of allowing TLS passthrough.
how would you recommend to change my configuration?
đģ mediocregopher [OP...] ¡ 2024-01-05 at 07:58:
@norayr The post I linked to wasn't written by me, I've never used traefik personally, so I don't think I can be much help here. Maybe you're using a newer/older version of traefik that expects a different configuration?
đ norayr ¡ 2024-01-05 at 14:14:
@mediocregopher would you suggest using tokio-rustls you patched? would you feel comfortable to mention a configuration example for my usecase?
đģ mediocregopher [OP...] ¡ 2024-01-05 at 17:04:
@norayr the tokio-rustls patch is for a rust library, it's not an actual application which can be used as-is. You would need to code your own which incorporates it.
I used that library as part of this project:
_Technically_ you could use Domani in the way you're wanting to, given a specific configuration. I've been using Domani myself to serve my HTTP(s) and gemini sites for a few months now and haven't noticed any issues, but I wouldn't say it's stable yet. There's still quite a few changes I want to make to it, and I haven't gotten around to generating release binaries for it yet so you'd need to compile it yourself.
đ norayr ¡ 2024-01-09 at 13:53:
ok i used gmid for reverse proxy and was able to redirect to 2 different molly browns for a test.