Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for gemini protocol (port 1965) #85

Open
emceeaich opened this issue May 17, 2020 · 3 comments
Open

add support for gemini protocol (port 1965) #85

emceeaich opened this issue May 17, 2020 · 3 comments

Comments

@emceeaich
Copy link

I'm part of a group of hobbyists working with a protocol, gemini, designed to sit between gopher and http.

See: https://portal.mozz.us/gemini/gemini.circumlunar.space/ (portal.mozz.us is a gemini to http proxy)

The protocol uses port 1965 and I'd like to be able to create pagekites on that port.

At the moment, I get error messages that tunneling that port is not allowed, would it be possible to support that?

@BjarniRunar
Copy link
Collaborator

Hello! Thanks for suggesting this.

I have one important question: Does the protcol's client announce the name of the server it is connecting to, when it connects?

In TLS this is done using an SNI header, in HTTP this is done using the Host: header. XMPP also has an equivalent. Protocols such as SSH, IMAP and POP3 however do not, which is why they cannot be natively supported by PageKite.

Which category does the Gemini protocol fall in?

(The separate issue, whether pagekite.net listens on port 1965 or not, depends on this one - there is no point listening on that port if the protocol itself cannot work.)

@emceeaich
Copy link
Author

emceeaich commented May 31, 2020 via email

@emceeaich
Copy link
Author

To answer your question, yes. Gemini uses an SNI header.

https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/spec-spec.txt

4 TLS

Use of TLS for Gemini transactions is mandatory.

Use of the Server Name Indication (SNI) extension to TLS is also
mandatory, to facilitate name-based virtual hosting.

4.1 Version requirements

Servers MUST use TLS version 1.2 or higher and SHOULD use TLS version
1.3 or higher.  TLS 1.2 is reluctantly permitted for now to avoid
drastically reducing the range of available implementation libraries.
Hopefully TLS 1.3 or higher can be specced in the near future.
Clients who wish to be "ahead of the curve MAY refuse to connect to
servers using TLS version 1.2 or lower.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants