💾 Archived View for rawtext.club › ~sloum › geminilist › 000912.gmi captured on 2020-09-24 at 02:14:57. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Dominik Dalek dominik.dalek at thaumatec.com
Wed May 20 17:20:25 BST 2020
- - - - - - - - - - - - - - - - - - -
Howdy!
I'm working on my own client and figured I'd write on the status codes.This is something that, I feel, can be simplified. My comments will bebased on two assumptions:1. Things should be as simple as possible, but not simpler2. Complexity is a source of bugs and exploits[1]
I understand that there may be some aversion to changing things thatare already pretty well established, but I hope it's not too late andmy arguments will be at least a little bit convincing. :)
Suggestion #0: Strengthen language around status codes
It is softly stated that the second digit is an extension to the statuscode. Then valid first digits are laid out. Upon first reading I foundthis confusing so I would welcome rephrasing this into something thatstates explicitly:1. All clients and servers must at the very least recognize status codes10, 20, 30, 40, 50 and 60.2. Any xy code not recognized by the client can be safely interpretedas x0 (e.g. 21 can be safely treated as 20, and 45 can be treated like40 w/o consequences)3. The status codes section shouldn't use single digits but the corecodes (10, 20, etc.) or as masks (1y, 2y, etc.)4. Replace the unique phrasing of "range of codes" in section 1.3.1 with"status code category" used elsewhere (range felt like a broader termthan category and caused me some time to figure out if I'm missingsomething important).
Suggestion #1: Remove proxy related codes
Current spec is already something that is likely to be two IETF RFCsin the future (protocol and document format). Adding proxy support intothe mix complicates things even further. Problems with proxy IMO startwith the fact that it's not clear (to me at least) what sort of proxygemini would benefit from; nor is it stated in the spec.
Classical reverse proxy roles of load balancing and caching are possiblebut I don't see how these can be implemented w/o expiration mechanismsadded to the spec. It could be done, but I think it should be tackledin a separate RFC. Forwarding proxy, anonymizing or otherwise isa possibility but, again, I think this should be an extension thatends up in a separate spec.
There's also a lot of work that has to be done for the proxy to supportclient certificates in various setups (when we want anonymity or not,where we deal with session certs or permanent ones, and so on), howvarious error paths should perform, etc. It's a lot of work and woulddefinitely need fairly stable clients and some reference proxyimplementation to validate assumptions about what could work.
How server and client certs are handled in the proxy scenario is alsosomething that I don't think is trivial and as such would require somelegwork to get up and running. So, yeah, I'd cut any mention of proxyat the moment and with that's codes 43 and 53.
Suggestion #2: Deduplicate client cert errors
Only a single client cert can be sent when establishing the communicationchannel. My mental model (correct me if I'm wrong!) is that transientcert is a session substitute and permanent cert is authenticationmechanism (roughly speaking at least).
Current spec has 3 cert request mechanisms, 3 rejection codes anda revocation code. This creates numerous corner cases for clientsto handle properly, e.g.* what do you do if you get 21 in response to a request that includedyour permanent key? I sure hope the browser doesn't actually deletethe permanent key from the store :)* what do you do if you get 64 but your cert is not from the future?* what do you do if you get 65 but your cert hasn't expired?
I'd like to see a single "client certificate rejected" code eliminatingresponses that would potentially make no sense.
I feel that differentiating between the types of rejection opens someopportunity for oracle attacks (i.e. rogue clients can inspect servercert processing bugs by observing how responses differ for variouscrafted requests). In essence I'd cut 64 and 65.
Suggestion #3: Change end of cert session (21) into a redirection
This will probably be a very controversial one but the way I see itthe end of session typically results in the redirection. This lets youchain requests on logout in a way that enables permanent client keydelivery or temporary key replacement. With current design you servea page in a response to a request that displays something and asksthe client to delete the transient cert. If you want to re-establishsome sort of validation from the client, you need a manual interventionfrom the user to do that. I'm not sure if my explanation is clear enough,I can try and expand upon it if needed.
Suggestion #4: Merge different types of server error to prevent leakingwhat happened under the hood
HTTP 500 is often seen as an indication of something wrong in the serverapplication logic. This would be the primary attack vector for someonetrying to compromise the server (even if only DOS it). I don't think itmakes sense to differentiate codes 40-42 with the exception maybe ofa planned maintenance. Basically I'm sort of allergic to disclosinginformation about the server state.
The counter argument is likely going to be: there's reason not to giveextra details.
To which I say ;) sure, but you can already do that with <META>.
Suggestion #5: A comment, really
5x codes are by design permanent errors but 51 (HTTP 404 equivalent) isactually a temporary problem according to the spec.In fact this is precisely what differentiates it from HTTP 410 GONE(gemini 52). So there seems to be a design error here but I don't reallyknow what the correct solution is. Either 5x aren't really permanenterrors (how would they be called then?) or 51 shouldn't be a 5x errorto begin with.
This sums up my thoughts about the status codes. I know this reads verymuch like "too complex, cut!" and that kinda is exactly that. But if youcan make things simpler, why not do it? :)
Thanks for reading this, cheers!-Dom
[1] There's a neat research on exploiting HTTP status codes:https://www.youtube.com/watch?v=4OztMJ4EL1s