This page permanently redirects to gemini://bbs.geminispace.org/u/asdf/24311.

Comment by 🚀 asdf

=> Re: "Thoughts on geminict://" | In: s/Gemini

Haven't had a look at what SIS server is yet but if you're going to implement the protocol in a server can you also implement it in a client, so that people can actually connect to the server with the protocol? Because to my knowledge no-one has implemented it yet.

=> 🚀 asdf [OP]

Jan 24 · 7 days ago

7 Later Comments ↓

=> 🚀 stack · Jan 24 at 18:12:

I kind of wish the opposite - a secure universal transport layer.

damn, I mean the same.

=> 👻 darkghost · Jan 24 at 18:41:

I'm with @stack on this one. My opinion: Security should be the default since there are so many malicious actors on the network.

=> 🚀 stack · Jan 24 at 19:53:

Yes, I wish the OS provided a secure socket service.

For Gemini you also need client certificate support.

=> 🦂 zzo38 · Jan 24 at 20:57:

I think that unencrypted Gemini should not need its own port number, because Gemini protocol is: client sends first, and the client sends a URL which cannot start with a control character; therefore, it can be distinguished. (I made Scorpion protocol to use the same port number for encrypted and unencrypted, for the same reason. Another consideration is 6x responses, but I did consider that too; I wrote that the client switches to encrypted mode once a certificate is provided by the user.) I agree that it should use a different URI scheme then "gemini:" though (I previously suggested "insecure-gemini:", but I suppose "geminict:" will do).

(One of the problems with Mercury protocol is that it does not seem to be well defined enough.)

(Another note, about Spartan: If you are only serving static files on Spartan and Gemini, then it should be good enough to use Spartan as the unencrypted protocol. (Although the Spartan protocol is only ASCII, the documents are UTF-8 and the same formt as Gemini; some people have been confused by this, so I mention it.) For dynamic files, the differences of the protocols may make it more complicated to handle, though.)

=> 🚀 sy · Jan 25 at 06:03:

+1 for security-by-default. I hope a gemini protocol update mandates TLS1.3 with ECH, too.

It took some time for me to notice that @clseibold’s server was not down on the server side, but was actively being blocked by my ISP on TCP level. I had to special-case it in my client to use IP and avoid sending SNI. That workaround won’t work for multiple servers on the same IP with the current specification.

=> 🚀 clseibold · Jan 25 at 13:54:

@sy Oh, weird! I wonder what is getting it blocked. I use ALPN (Application-Layer Protocol Negotiation), so maybe it's that. Or maybe it's something with my certificate? Does the non-tls (nex, gopher, or spartan) sites work for you?

=> 🚀 sy · Jan 25 at 14:13:

@clseibold Sorry for being not specific enough.

The whole ddns.net is being blocked, for unrelated reasons. HTTP is redirected to some other domain, and connection is reset for other protocols (by SNI sniffing if on TLS).

Edit: nex, gopher etc. plain protocols seems to work now. Previous problems probably were indeed server side. But I prefer eavesdropping- and tampering-resistant protocols nonetheless.

Original Post

=> 🌒 s/Gemini

Thoughts on geminict:// — My personal philosophy, is that protcols in the application layer shouldn’t implement encryption. I think encryption should be the job of the underlying network that the protocols run on. Take Yggdrasil or I2P for example, where addresses are cryptographic public keys and all traffic is encrypted. Running Gemini on such a network would mean encrypting traffic twice, which seems a bit unnecessary to me. If you simply implement encryption once, in the underlying network,...

=> 💬 asdf · 17 comments · 4 likes · Jan 24 · 8 days ago