Currently at a very nice hotel, with a great breakfast but a WiFi networks which allows only ports 80 and 443. As a result, I need to tunnel all the Gemini traffic :-( (By the way, it seems there is currently no Gemini client with SOCKS support?)
I've experienced the same thing, very annoying. I made an issue for SOCKS in Amfora, it should be easy to implement. https://github.com/makeworld-the-better-one/amfora/issues/155 Another interesting way to solve this would be to have a Gemini proxy server running on port 443. That's easier to set up (once someone writes one, ha), and will work with Amfora today. Cheers, makeworld
Someone has written one. :) gmitohtml is a Gemini proxy server. https://gitlab.com/tslocum/gmitohtml
>Someone has written one. :) > >gmitohtml is a Gemini proxy server. > >https://gitlab.com/tslocum/gmitohtml Forgive me if I misunderstand, but I believe the idea is to run the Gemini protocol and serve gemini content, but just be able to do it on a port other than 1965 (In this case, proxying gemini over the https port). The proxy server you suggest appears to be one for translating gmi to html and serving it over a web interface. There are several such pieces of software in common public use (such as at mozz.us) but they are different from what is being discussed here. ~Stephen
> > Someone has written one. :) > > gmitohtml is a Gemini proxy server. > > https://gitlab.com/tslocum/gmitohtml > > Forgive me if I misunderstand, but I believe the idea is to run the Gemini > protocol and serve gemini content, but just be able to do it on a port other > than 1965 (In this case, proxying gemini over the https port). To clarify, I'm talking about Gemini server that accepts request URLs with other hosts. Like the server runs at example.com, and will accept requests for example.com, gus.guru, makeworld.gq, etc. And it will make the request on your behalf. And then that server could run on any port, port 443 for example. This would be a way to get around blocking. makeworld
> On Dec 24, 2020, at 04:45, colecmac at protonmail.com wrote: > > And then that server could run on any port, port 443 for example. This would be a > way to get around blocking. In other words, assuming some hypothetical proxy service at 'tunnel.xyz' running on port 443 over TLS: openssl s_client -quiet -crlf -connect tunnel.xyz:443 <<< gemini://mozz.us/ 2>/dev/null First connect to tunnel.xyz:443, then request the content at gemini://mozz.us/ . Nice use case. On that note, Merry Christmas and Happy Holidays.
On Thu, Dec 24, 2020 at 03:45:59AM +0000, colecmac at protonmail.com <colecmac at protonmail.com> wrote a message of 22 lines which said: > To clarify, I'm talking about Gemini server that accepts request > URLs with other hosts. Like the server runs at example.com, and will > accept requests for example.com, gus.guru, makeworld.gq, etc. And it > will make the request on your behalf. A bit like "domain fronting" <https://en.wikipedia.org/wiki/Domain_fronting>. > And then that server could run on any port, port 443 for > example. This would be a way to get around blocking. Indeed. I hope someone will volunteer. Do note that this requires trust in the proxy, which will see everything in clear text. With ALPN (RFC 7301 <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc7301.txt>), the same machine could even run HTTPS and Gemini on the same port. All it needs is registration of ALPN for Gemini <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp e-values.xhtml#alpn-protocol-ids> and its use by Gemini clients.
On 2020-12-24T03:45Z, colecmac at protonmail.com wrote:
>>> Someone has written one. :)
>>> gmitohtml is a Gemini proxy server.
>>> https://gitlab.com/tslocum/gmitohtml
>>
>> Forgive me if I misunderstand, but I believe the idea is to run the Gemini
>> protocol and serve gemini content, but just be able to do it on a port other
>> than 1965 (In this case, proxying gemini over the https port).
>
> To clarify, I'm talking about Gemini server that accepts request URLs with
> other hosts. Like the server runs at example.com, and will accept requests for
> example.com, gus.guru, makeworld.gq, etc. And it will make the request on your
> behalf.
>
> And then that server could run on any port, port 443 for example. This would
> be a way to get around blocking.
>
> makeworld
This topic has now been mentioned in another thread, but TOFU makes a "nice"[1]
proxy difficult:
The TLS certificate has to be sent before any content from the client is
transmitted (* remember this). This means that the proxy sends its own
certificate. Depending on how lax the client is on checking the certificates
contents, it cannot work differently.
Only after verifying the certificate is the requested URL transmitted.
Now the problem arises: How should the proxy handle the endpoint's certificate
under TOFU?
Idealy the certificate would just be forwarded by the proxy, but this is not
possible because of (*).
The proxy could do its own TOFU and allow its users to update the cert store,
but on a public proxy this could be exploited by an attacker.
The proxy could have its own "user sessions" but at that point the
implementation of the proxy would be considerably inflated IMHO.
It would probably be much cleaner to use a VPN or an SSH tunnel at that point
(and probably a zillion other ways).
[1] Whatever would be considered nice is a different point, i.e. what
Stephane Bortzmeyer wrote on 2020-12-24T13:06Z:
> Do note that this requires trust in the proxy [...]
Johann
---
You can verify the digital signature on this email with the public key
available through web key discovery. Try e.g. `gpg --locate-keys`...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201225/ef27
0839/attachment.sig>
---
Previous Thread: [user] macos client with a sense of aesthetics?