A Call for a Gemini Without TLS

Opinion: the TLS encryption used in Gemini provides very little security, and should be removed. Some questions and answers:

What is TLS?

TLS is a key-exchange and an end-to-end encryption scheme used by HTTPS and Gemini clients and servers.

What does it accomplish?

• Encrypt all data in both the request and the reply, preventing casual eavesdropping and tampering;
• Guarantee that the server is in posession of the private key, and therefore, the same one you've talked to before.

What is wrong with TLS?

Encrypting data is pointless:

• There is no sensitive data on the Gemini network (largely due to non-commercial nature of Gemini users.
• Why deploy a complicated technology? Who is the probable attacker and why? What is the value of the data being protected? What is the likely attack vector? Has anyone really considered this?
• The encrypted data is readily available on the public-facing servers, TLS or not. Anyone can access it with their own browsers, so snooping will not reveal new information.

Is tracking still possible? (Yes it is)

• End-to-end encryption does not hide your request. DNS resolution, and the act of making a TCP connection to the server is still observable by anyone snooping on the wire;

https://kieranhealy.org/blog/archives/2013/06/09/using-metadata-to-find-paul-revere/

Questionable security or centralization?

• The TLS certificate must normally be signed by a trusted third party, which is a terrible idea if you like freedom. The alternative? A self-signed certificate is what pretty much everyone here uses. That only works because as I pointed out, trust does not matter here anyway. But even a paranoid anticentralization bastard like me would not put money into a self-certified bank or go to a doctor who signed his own freshly-printed diploma.

Mass-market encryption is likely compromised.

It is almost certain that widely-accepted and used cryptography is compromised and is not a threat to governments (otherwise we would see a serious push for other technologies which include backdoors). In fact it is very likely that NSA and other such players are actively introducing and supporting certain encryption technologies. Some even believe that bitcoin is an NSA creation, as the creator was never revealed, and bitcoin is _the most traceable_ method of transacting.

TLS assures 100% lack of deniability

• Accessing a server with a client certificate may open you to legal problems. It absolutely proves that you've connected to a server if machines are seized -- with scientific guarantees. There is no need to even eavesdrop for governments - just a compromised server and your confiscated machine are enough to establish guilt beyond any doubt.

Questionable authentication

• While you know that the server is still the same one you connected to (man in the middle cannot pretend to be the server you wish to connected to), you still don't know who you are talking to (because the initial contact requires you to accept the server as real: TOFU is 'trust on first use'). This may give you a false sense of security where you should be very cautious.

Complexity, risk and sluggishness

• TLS greatly complicates the clients and the servers, for no good reason.
• TLS support requires the use of third-party libraries. This means that implementors, who are not crypto experts, need to rely on third parties for security. The libraries (and libraries that libraries depend on) need to be kept up-to-date, both by software writers and often, by _every user_. Users are largely unaware of technological issues, and are often using insecure systems such as Microsoft Windows, often way out of date. There are several TLS libraries in C with confusing heritage and naming, and it is difficult to even figure out even which one to use. (I managed to compile a TLS client, but it took a lot of fiddling, downloading weird shit from god knows where, and messing around, and I am a competent [but impatient] C programmer with decades of experience). Other languages generally wrap around the C libraries, introducting additional risks.
• Using third-party libraries introduces security risks with consequences much more dire than snooping on Gemini communications -- such as back doors and full-system compromize.
• TLS connections are sluggish, as they require extra round-trips for authentication. TLS servers must keep more state to process the authentication and data transaction. Additional opportuinities for DOS and break-ins are introduced.
• TLS is complex. Without TLS (such as with Spartan protocol), a minimal TCP/IP stack allows you access to servers - your Commodore 64 or Apple ][ can do that. TLS pretty much assures that old machines will not be used for Gemini browsing, without proxying to Spartan.

What can be used instead of TLS?

• Digital signatures can be used as an option to ensure that the sender is in posession of their private key and the data is not tampered with;
• Client authentication can likewise be an option using public key cryptography;

But isn't it in the spec?

The spec, as I mentioned elsewhere, is really a manifesto. Gemini does not really need TLS to remain Gemini, just like it does not require gemtext.

To Summarize

TLS goes entirely against the grain of the core concepts of Gemini - simplicity, succinctness, ease of implementation, and the desire to rid ourselves of the stupidity of the mainweb.

It adds unnecessary bulk, complexity, delays, and a 'black box' that is not comprehensible, while offering pretty much nothing in return -- and a false sense of security for those who least understand the implications.

I am really surprised that everyone just went along with this without giving it much thought.

What can you do?

Even if you think I am a tactless moron, please consider that TLS may not be necessary, and consider the suggestions below:

• If you are writing or have written a _client_, make a provision for a simple socket connection to a server, or at least make your client modular enough that a different transport can be easily used;
• If you are writing or have written a _server_, likewise, consider making the data available as plaintext on another port, or make provisions for modularity;
• If you are a _content provider_, ask the makers of your server software to provide plain-text options.
• If you are a _user_, make your voice heard. Your browser includes incomprehensible black boxes to provide features you do not need. The rest of it is pretty obvious - rendering gemtext, following links, keeping bookmarks. Ask the makers of your favorite software to provide support for plaintext communications, and use non-TLS servers when possible. If nothing else, it reduces your traffic, power usage and carbon footprint by a small amount.

Consider switching to Spartan.

Spartan is basically Gemini without TLS (with a few enhancements and simplifications). It is Gemini the way God had intended, without the 'cough, never mind that black-box, cough' trickery. Your gemtext content may be served over Spartan - in parallel with your Gemini server.

Writing a toy Spartan client is a joy (and can be done in an evening) - you don't need to deal with any black magic - open a socket and get the file.

Why are you sabotaging Gemini? Are you a troll?

I am not, and no. I love the Gemini community, the (illusion of) simplicity, the terseness and quietness of Gemini. I've been an active contributor to the community with my games.

I think it is important to have an open conversation and think critically about technology and the problems it solves -- and introduces -- regularly and repeatedly. And if something is unnecessary, excise it as soon as possible because things like that grow as a cancer, and after a while it is no longer possible.

In short, I am invested, and I want Gemini to be there. Done right, if possible.

Is there a chance this will happen?

No. Being reasonable is hardly a driving factor for any technology or group.

index

home