💾 Archived View for bbs.geminispace.org › u › mozz › 3257 captured on 2023-11-04 at 16:12:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
Re: "Reverse proxy for gemini vhosts"
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
2023-07-18 · 4 months ago
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?
2023-07-21 · 3 months ago
i as referred to this thread
@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)
— => Here's an NGINX config that uses SNI to do what you're asking. Cheers
relayd? hmmm... did anyone already configure some capsules like that? can i find some example configurations somewhere?
omg let me see!
@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
2023-07-22 · 3 months ago
@mediocregopher sorry that was mentioned somewhere else on the same topic, I confused the "channels"
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
2023-07-24 · 3 months ago
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.
2023-07-26 · 3 months ago
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
2023-07-27 · 3 months ago
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.
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.
Some final closure on this thread, thanks for all the input everyone!
— mediocregopher.com/posts/domani.gmi
2023-08-09 · 3 months ago
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?
2023-08-10 · 3 months ago
Reverse proxy for gemini vhosts — Reverse proxy for gemini 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...