everything wrong with free software

 "obedience breeds foolishness"

### [generate-title] by Gavin Rebeiro => gnew-wiki.html gnew-wiki *originally posted:* feb 2021 I'm going to quote and write out some of my thoughts on the TLS portion of the Gemini spec. > 4 TLS > Use of TLS for Gemini transactions is mandatory. Interesting. So this basically means that we have to consider TLS a part of every Gemini implementation (Note 0). > Use of the Server Name Indication (SNI) extension to TLS is also mandatory, to facilitate name-based virtual hosting. I had to ask Wikipedia about this: => https://en.wikipedia.org/wiki/Server_Name_Indication The opening paragraph was enough to get an idea of what's going on: > Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. Okay. Semantics here are clear. The reasoning for desired functionality: > This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other service over TLS) to be served by the same IP address without requiring all those sites to use the same certificate. I guess this is so that you can have "separation of concerns" when it comes to authentication for different "pipelines". Makes sense. Now an analogy is provided to us: > It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. I don't think their use of the phrase "virtual hosting" is semantically as accurate (or relevant) as what I said: separation of concerns wrt authentication pipelines. Then we are told: > This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. They're boxing themselves into a specific use-case here. Again, it would be better if they said the more abstract version I provided (separation of concerns wrt authentication pipelines). Finally, the last sentence: > The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. Makes sense because you have to send cleartext before any authentication can be done. The only way to get around this is to have exchanged encryption keypairs beforehand. Nothing standing out here. It's interesting that the Gemini spec doesn't abstract the whole "to facilitate name-based virtual hosting" either. That example is confusing to me and I don't get why they went with it. Back to the Gemini spec: > 4.1 Version requirements > Servers MUST use TLS version 1.2 or higher and SHOULD use TLS version 1.3 or higher. Nothing out of the ordinary there. > TLS 1.2 is reluctantly permitted for now to avoid drastically reducing the range of available implementation libraries. Again, seems alright. > 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. This is a bit concerning. I don't like the whole "newer is better" argument they go for here. The TLS spec is notorious for being inflated and kidnapped by GIAFAM; I'm surprised the Gemini spec team don't exercise more caution here. Avoiding cargo culting is the whole point of Gemini; this is cargo cult behaviour. Libressl was established to move away from the cargo cult behaviour seen in SSL/TLS. > 4.2 Server certificate validation > Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. So what happens when a client doesn't validate a TLS connection? There's no "else" clause here. Does the client just keep accepting the traffic? Kind of defeats the purpose of what we see in (Note 0). TOFU seems alright. Self-signed certs being first-class citizens is definitely a step in the right direction. > This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go). Makes sense. TOFU is used in a lot of other places as well. It's simple, stupid, and works. Lowering barrier to entry is a good sign. Self-signed certs should always be first-class citizens; I'm glad there's repetition of emphasis on that point here. > TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. Yep. And OpenSSH has withstood the test of time and will never die. > The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. Bit confused here as they don't say what happens to TLS certs a client rejects. The spec implies you accept every cert by default. I think they need to iron out this sentence with some conditional clauses. Maybe they mean "The first time a Gemini client connects to a server, it MUST accept whatever certificate it is presented". This is a clear imperative statement and removes ambiguity from the spec. It would help if they used RFC2119 explicitly to help alleviate these sorts of issues. > That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. Good analogy. Relate to the familiar; I like it. > On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA. Kind of like OpenSSH, again. The only different is that they have a similar operational pipeline to WWW in the second sentence. The first sentence is more akin to OpenSSH. > This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally. Fair enough. I think they've done an alright job. They just need to add some clauses about what happens when a client rejects a cert. How is a server supposed to respond to a cert rejection? Does a client send data about a cert rejection to a server? Someone needs to bring this point to the attention of the spec authors. > 4.3 Client certificates > Although rarely seen on the web, TLS permits clients to identify themselves to servers using certificates, in exactly the same way that servers traditionally identify themselves to the client. Yes. It's called mTLS (mutual TLS). But this is usually limited to programmers who've built both the server and the client. Because you need both sides to agree on things beforehand in a "mutual authentication" pipeline. > Gemini includes the ability for servers to request in-band that a client repeats a request with a client certificate. Makes sense. I guess they mean a server can ask a client for a cert from said client to provide a bit more security. Helpful for operational pipelines where we need to make sure arbitrary clients can't "spoof" their identity to make it look like another unsuspecting client; this kind of hijacking is a common attack vector. > This is a very flexible, highly secure but also very simple notion of client identity with several applications: Go a bit easy on the adverbs and adjectives there. lol > Short-lived client certificates which are generated on demand and deleted immediately after use can be used as "session identifiers" to maintain server-side state for applications. In this role, client certificates act as a substitute for HTTP cookies, but unlike cookies they are generated voluntarily by the client, and once the client deletes a certificate and its matching key, the server cannot possibly "resurrect" the same value later (unlike so-called "super cookies"). God. Talk about drinking from a fire hydrant. Let me try to break this down and make sense of it. 0) Short-lived client certs can be generated on-demand. Okay. So I'm guessing this demand is coming from the server? 1) and deleted immediately after use. Okay. 2) can be used as "session identifiers" to maintain server-side state for applications. Ah. I see. So this is about server-side state and "session identifiers". So, basically, "cookies". However, unlike ordinary cookies, we are dealing with mTLS here (Note 1). So it's kind of cookies but with mutual authentication. Let's stick to "session identifiers" though because that's a more meaningful term than "cookies" (I don't know which idiot came up with this term but it's dumb). Okay. Gemini can do session identifiers with mTLS. Again, we'll keep track of this as (Note 1). 3) In this role, client certificates act as a substitute for HTTP cookies, More or less what I already said. 4) but unlike cookies they are generated voluntarily by the client, Can be generated "voluntarily". What if a client rejects an mTLS request? What then? Undefined behaviour, it seems. (Note 2) 5) and once the client deletes a certificate and its matching key, the server cannot possibly "resurrect" the same value later (unlike so-called "super cookies"). What do they mean by "a certificate and its matching key"? Certificates correspond to asymmetric encryption keys; you have a public key and private key for any given "certificate". And "resurrect" what "value"? Undefined stuff here. Never heard of "super cookies" before. They need to be more rigorous with their statements; this is a specification. (Note 3) > Long-lived client certificates can reliably identify a user to a multi-user application without the need for passwords which may be brute-forced. Even a stolen database table mapping certificate hashes to user identities is not a security risk, as rainbow tables for certificates are not feasible. Okay. So basically mTLS where the connection lasts for a long time. They need to be careful with this and any client/server TTL options in action. Because of this: > Connections are closed at the end of a single transaction and cannot be reused. So there we have (Note 4) > Self-hosted, single-user applications can be easily and reliably secured in a manner familiar from OpenSSH: the user generates a self-signed certificate and adds its hash to a server-side list of permitted certificates, analogous to the .authorized_keys file for SSH). Fair enough. Good use of analogy and good analogy. > Gemini requests will typically be made without a client certificate. Yeah. Most implementations will not bother with mTLS; like is the case with HTTP(S). > If a requested resource requires a client certificate and one is not included in a request, the server can respond with a status code of 60, 61 or 62 (see Appendix 1 below for a description of all status codes related to client certificates). This answers (Note 2). This is where they really need to up their game with presentation. Nobody (including the spec authors) is going to be able to follow this spec unless they use dynamic section handling. They need a lesson in (La)TeX. > A client certificate which is generated or loaded in response to such a status code has its scope bound to the same hostname as the request URL and to all paths below the path of the request URL path. Okay. So if a client responds to a 6x status code from the server, the client can't change the hostname; seems reasonable and secure. i.e., the "session identifier" that mTLS gives us here is locked to the original hostname requested by the client. (Note 5) > E.g. if a request for gemini://example.com/foo returns status 60 and the user chooses to generate a new client certificate in response to this, that same certificate should be used for subsequent requests to gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, etc., until such time as the user decides to delete the certificate or to temporarily deactivate it. These people need to learn how to write short sentences. Also, this seems quite irrelevant to what they said before. Look at my (Note 5). What they should say here is that a client that: 0) Generated a cert for mTLS cert in response to a 6x status code 1) Can't request a different hostname 2) i.e., if client requested: gemini://example.com/foo, then the client can't subsequently request gemini://badexample.com/foo during the lifetime of the "session identifier". 3) "session identifier" here being the client cert that we get in (0) > Interactive clients for human users are strongly recommended to make such actions easy and to generally give users full control over the use of client certificates. I guess they mean something like "web browsers" when they say "Interactive clients". I get the motivation but they should focus more on ironing out the kinks in their spec before they go down the "UX" rabbit hole. Well. That's my thoughts on this. You can forward it to the spec authors and say Gav sends his regards. => https://wrongwithfreesw.neocities.org