💾 Archived View for rawtext.club › ~sloum › geminilist › 000920.gmi captured on 2020-09-24 at 02:14:40. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Wed May 20 21:15:27 BST 2020
- - - - - - - - - - - - - - - - - - -
It was thus said that the Great Dominik Dalek once stated:
Howdy!
Hello.
[bit ol' snip]
Suggestion #1: Remove proxy related codes
[ snip ]
How server and client certs are handled in the proxy scenario is also
something that I don't think is trivial and as such would require some
legwork to get up and running. So, yeah, I'd cut any mention of proxy
at the moment and with that's codes 43 and 53.
There are at least two Gemini servers that handle proxying to variousdegrees (to my knowledge). I expect changes, but not removal.
Suggestion #2: Deduplicate client cert errors
Only a single client cert can be sent when establishing the communication
channel. My mental model (correct me if I'm wrong!) is that transient
cert is a session substitute and permanent cert is authentication
mechanism (roughly speaking at least).
Current spec has 3 cert request mechanisms, 3 rejection codes and
a revocation code. This creates numerous corner cases for clients
to handle properly, e.g.
* what do you do if you get 21 in response to a request that included
your permanent key? I sure hope the browser doesn't actually delete
the 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?
Both of those indicate either
1) a buggy server 2) a buggy client 2) the client clock is incorrect 3) the server clock is incorrect
I would only really expect to see these around the time of certificateexpiry (or certificate creation).
I'd like to see a single "client certificate rejected" code eliminating
responses that would potentially make no sense.
I feel that differentiating between the types of rejection opens some
opportunity for oracle attacks (i.e. rogue clients can inspect server
cert processing bugs by observing how responses differ for various
crafted requests). In essence I'd cut 64 and 65.
I don't agree. I don't have a fully fleshed out response to the "but muhsecurity!" argument (well, there is "security through obscurity" isn't) butit's rooted around the following story:
Ken Thompson [creator of C and Unix] has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gage, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong."
I've done tech support and have had to deal with "it's broke---fix it!"questions with nothing more than that. I'd rather not do that again.
Suggestion #3: Change end of cert session (21) into a redirection
This will probably be a very controversial one but the way I see it
the end of session typically results in the redirection. This lets you
chain requests on logout in a way that enables permanent client key
delivery or temporary key replacement. With current design you serve
a page in a response to a request that displays something and asks
the client to delete the transient cert. If you want to re-establish
some sort of validation from the client, you need a manual intervention
from the user to do that. I'm not sure if my explanation is clear enough,
I can try and expand upon it if needed.
It might help to test against a server that actually implements this. Ikind of see what you are getting at, and a "logout" mechanism is solelymissing from HTTP (if you are using the actual authentication mechanism andnot HTTP cookies), but I'm not exactly sure what your objection here is.
Suggestion #4: Merge different types of server error to prevent leaking
what happened under the hood
See above---we'll have to agree to disagree on this.
HTTP 500 is often seen as an indication of something wrong in the server
application logic. This would be the primary attack vector for someone
trying to compromise the server (even if only DOS it). I don't think it
makes sense to differentiate codes 40-42 with the exception maybe of
a planned maintenance. Basically I'm sort of allergic to disclosing
information about the server state.
Nothing to stop a server from just serving up '40' for everything.
Suggestion #5: A comment, really
The 40 range of codes map to HTTP 500 range (server errors), and the 50range of codes map to HTTP 400 range (client errors), and when I first wroteGLV-1.12556, I used HTTP status codes (because I felt the original statuscodes were ... less than optimal), but later solderpunk renamed "clienterrors" to "permanent errors" and "server errors" to "temporary errors" (Ithink he gave some justification for this, but I don't recall what it was).
5x codes are by design permanent errors but 51 (HTTP 404 equivalent) is
actually 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 really
know what the correct solution is. Either 5x aren't really permanent
errors (how would they be called then?) or 51 shouldn't be a 5x error
to begin with.
It starts to make sense when you realize they were originally server andclient errors.
But let me be fair, and report back all the errors that GLV-1.12556 canreturn (modulo what a CGI scripts and the torture test):
10 prompt for input 20 okay 30 temporary redirect 31 permament redirect 40 temporary error 51 not found 52 gone 59 bad request 61 transient certificate 62 authorized certificate 63 certificate rejected 64 future certificate 65 expired certificate
Even my CGI module only returns 40 (if it can't run a CGI script forwhatever reason).
This sums up my thoughts about the status codes. I know this reads very
much like "too complex, cut!" and that kinda is exactly that. But if you
can make things simpler, why not do it? :)
It broke. Fix it. 8-P
-spc