💾 Archived View for gemini.susa.net › cgi-bin › gemini-irc captured on 2022-04-28 at 17:39:18. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-01-08)
-=-=-=-=-=-=-
ok who wants to help me test my bouncer bcuz i'm suspicious of something
by "help me test" i mean i'm going to close my client and re-open it and i want you to tell me if it says that i left bcuz then the bouncer would be pretty obviously not working as intended
figbert: I've enabled all status messages now. I can check it for you
ew0k: ok i did the thingy, no disconnect?
figbert: no disconnect :)
oh yay that's good
just moved from thelounge to soju
figbert: does soju have a web interface?
nope! that's kind of the point of the move - i want to be able to use whatever frontend suits my needs at a given time
it's a general philosophy i've taken with self-hosted services
i use radicale, and hook it up to various frontends depending on my device
and so it goes: host a backend, use appropriate frontend depending on environment
I use thelounge specifically for the web interface, which means I can use it from any device without installing or configuring something else
also I just wrote "configurating" before correcting, and that should totally be a word
the ease of use of a web app is unbeatable for sure
but i like native apps that i can play around with
and also tui things that i can be productive and not feel distracted in
it's all a matter of preference at the end of the day tho
yup
I've found that I need the browser for a whole lot I do anyway. Having a tab with thelounge as well doesn't make much of a difference
Good $timezone gemini peeps. Working on any cool projects this week?
still waiting for my Gemini client to be accepted into Flathub :(
maybe I should just give up on that and supply a static executable that auto-updates itself over Gemini
I hope it gets accepted dimkr! Also the latter idea sounds cool too, tho
I really like the idea behind https://github.com/djpohly/dwl/wiki/Patches, a list of community-provided patches for a project that's easy to hack on
dimkr's link to 'https://github.com/djpohly/dwl/wiki/Patches,'
I might do something like that with my Gemini client, I think the ideas of a simple protocol and a client you can trust align well with dwm-style hackability
is there any small TLS library that supports 1.3?
i think either bear or wolf does, but i forget which
my client jumps from 100 K to 3 MB when linked statically
hey tomasino :)
yeah, wolf - https://www.wolfssl.com/docs/tls13/
tomasino's link to 'https://www.wolfssl.com/docs/tls13/'
hola
GPLv2, not nice
s2n is Apache licensed
so I was kind of ignoring it the other day, but how is using client-certs as a cookie-like thing a layer violation?
No worse than how HTTPS does it, but you're storing protocol state in the surrounding transport. Other people claim there's no such thing as a layering violation though, so ymmv
You're not really identifying a session like a cookie does either, as you're identifying a remote user
the 7 layers model is a lie, the top layers are one layer really
Client certificates are pretty much a crime against humanity anyway, and difficult to implement securely
the only 7 layers i like are part of a bean dip
if I can run two browsers with different client-certs at the same time, then the certs aren't actually identifying a user, they're identifying the sessions?
there's not really even a session concept in gemini
the CGIs running on the gemini servers probably will just use using the fingerprint as a session ID anyway
you could fluccuate certs per request if you wanted
yeah, and I could erase my cookies each request
How do you issue these certificates? You need some out-of-band system for transmitting certificate signing requests
and basically there's no trust anyway
they're self-signed
lol
it isn't needed
I don't even
not if we're just using them for cookies :P
not if you're using them as user ident either
my cookies aren't signed
trusting the server is TOFU for now, maybe DANE if that takes off and clients implement
Cookies are issued by the server your client is talking to though. If I can just self-sign a client certificate and the server is unable to verify it, you might as well not bother with any of it
It indicates a total misunderstanding of the point of mutual TLS
or at least a wild abuse of it
what cookies? that's not actually a thing
if you want to be able to actually trust the cert, yeah, you need some way of verifying it, but if I want to store the CN in the cert with its fingerprint
that's pretty close to username and password
so if the client-cert is signed by the server, it should be fine, or, if the server stores CN and fingerprint in a database, and they match, it should be fine too?
signed-client certs just prevent the server from having to store as much client data?
I... am not sure anyone has ever considered the security of doing that, because it's nuts
then I want to make something that does it so people can poke at it and hopefully break it
Signatures allow certificates to be cryptographically verified, which is what they're for
storing the fingerprint in a database is the method i recommend in my video on gemini inputs & gemini application building
(gotta make sure the fingerprint is a good-enough hash ofc. md5 of cert is bad idea)
When people say "don't roll your own crypto", this is precisely the sort of thing they're talking about
oh good. something I'm not supposed to do.
must be more fun.
gmniserv provides the sha:256 as the hash to cgi scripts
that's what i use
It's not that you're not supposed to do it, it's that the result is unlikely to be fit for purpose
If you want to be able to identify users or sessions within the protocol, it would be trivial to do that, but this awful mock crypto is an attempt to work around this ideology that users must not be identified pfor privacy reasons
It makes no sense
yeah
works fine
yeah
on gopher I used to identify sessions with the IP address
I figure a client-cert fingerprint is less layers to cross, so better?
You're just abusing the TLS layer to transmit information that Gemini has excluded for ideologicial reasons
astrobotany is still truckin' along 652 later
I'm not trying to use crypto properly in this case, I just want some identifier that persists between connections
If you were to just, say, use HTTPS and pinky swear that you wouldn't collect persistent information about your users, it would be far superior
it'd be less fun though
i don't agree even in principal
I'm not sure how using metadata from a client certificate is even an improvement on embedding a token in the URL query string either, as it's nominally carried securely over TLS anyway
would that require rewriting all the links presented to the user to contain the token?
we do embed tokens in URL query strings, with type 10
I remember seeing websites in PHP a long time ago doing sessions without cookies that way
a single server could do that, but it's unnecessary thanks to client certs. a server could be naughty and generate tokenized links on load to try and track user paths within their site, but it ends as soon as you navigate away
and the next visit to the site won't be connected to that first visit
so, still not a cookie
I too use a different IP address for each query
do session cookies normally stay around until browser-close, or site-close?
it's changed over the years, but now it's usually browser close or 30 min
they added the 30 min limit because people now leave their browsers open forever? :)
likely
gotta make that analytics data actionable, right?
anywho, i dig the client cert stuff. It's really neat
IMHO the spec isn't clear enough regarding client certs
right. there's that one part about scope of what they apply to
I'm still not sure how you can object to per-visit tracking by servers, but then propose the use of exactly that just using something out-of-band
it doesn't specify what fields are mandatory, CN should be mandatory
it is not, and it's actually not even in use by many people in practice either
hash is all you get! :)
I don't object to per-visit tracking, I object to using javascript being used to track where my cursor is, what I type into fields before submitting them (and maybe erasing)
there's a pseudo-standard of specifying CN, in all clients I looked at
and maybe serial number too
HTTP hasn't ever mandated that server certificates have a DN at all, so it may come from that, if anyone actually read any documentation as part of coming up with this abominable client cert stuff
Not having a DN in a client certificate would be peculiar
but pseudo standards are bad, they can break capsules tested only against browser x or y, when it sees browser z that does exactly what the spec says
ahh, there's the kiddo. time to cook dinner
My muddled understanding is that the Gemini decided to prohibit request headers owing to the fear that this would open the door to extensibility, and the strong desire to create a complete and *final* protocol specification. This left very few options for State Management. I guess the client-cert solution effectively tried to create single session slot and stick to the ideal of preventing protocol
extension/evolution.
100% solve the problem. It's important to remember that it's the behaviour of
While client-certs certainly improve privacy implications they probably don't
and privacy interests are maintained.
user-agents (Gemini browsers) that ultimitely determine how well our security
TomDotTom: not only that, but we prety much didnt want state management at all didnt we?
I'm fully aware of all the discussions that went on, but given that Gemini has the 6X response code range I can only assume that minimal state management was acknowledge to be wanted.
not fully aware *
You know, lagrange should really inform you what, fu*
Cause it's annoying having lagrange yell at you with terrible error codes
TomDotTom, arahael: client certs were added because they’re a pretty secure way of handling authentication. Clients are encouraged to make the process of creating and discarding client certs simple. Of course, using a client cert allows the server to handle state of the session. That’s sort of a side effect
TomDotTom, arahael: but it’s by no means a discouraged practice. If your capsule requires users to be authenticated it stands to reason that it’s also interactive, and interactivity may absolutely require state management
yay, my Gemini client should appear on Flathub within 3 hours
it's going to look so cheap compared to Lagrange :(
congratulations!
dimkr: that doesn't matter at all :D
Lagrange looks so professional to me, it's inspiring
I've understood that it's very beautiful and very big (in terms of memory)
it's hard to build a small client with C++, Go or Rust, especially if you use SDL
I can imagine
I've been tinkering with tkinter for python, hoping to eventually make a graphical client
but... ugh... GUI programming suuuuuucks
I think I've heard someone say that a big factor in the size of Lagrange is the fonts, as well
I have no idea if that's true
ew0k: Do you know if there's any record of the discussions surrounding the decision to use client certs?
Mailing list linked from the circumlunar.space appears to be down for the count.
TomDotTom: not that I've seen, but I've had a lot told to me from the people who were involved early on. I think mozz was one of those who pushed for it in the beginning. Is there anything special you'd like to know?
TomDotTom: the mailing list host has been down for some time. There's a clone of the mailing list archive somewhere in geminispace, but I don't remember where.
Just curious on the back and forth about the pros/cons. Wondering how they war gamed/threat modelled the decision.
Currently thinking about the broken state of the HTTP/HTML/User-Agent triad. Reading through the Gemini specs it appears that the authors gave a lot of thought to similar concerns. Given that client certs could open the door to disloyal user-agents, I'm just curious if this was ever addressed?
ew0k: Is gemini://rawtext.club/~sloum/geminilist/ what you where referring to?
TomDotTom's link to 'gemini://rawtext.club/~sloum/geminilist/'
yay, my client is unsafe https://i.imgur.com/1EgrGzz.png
dimkr's link to 'https://i.imgur.com/1EgrGzz.png'
it can read/write all the data!
huzzah
also unsafe: vim
all Gemini clients are safe for children but unsafe
(according to Flathub)
dimkr: do they flag up things that request full host filesystem access?
probably, but access to ~ is enough to flag a package
dimkr: ah, yeah. I guess that's fair, ~ is where the secrets are, on a normal end user computer
flatpak trying to be sandboxed isn't too meaningful if everything can read $HOME
wut, Firefox is "safe"
dimkr: probably because the flatpak can't read ~
ummm ... so I'll need to create a sub-directory of ~
Good $timezone geminauts. What's on the agenda for this week(end)?
Beating a dead horse at this point, but if you want user authentication for Gemini, client certificates for TLS are an ideal way of doing that. They would be signed by a certificate authority known to the server though, or you're not actually unambiguously authenticating the user
^
The TOFU stuff is more like "This is probably the same user as previously made a request here", but the statefulness question makes the difference between TOFU (if you maintain persistent state on the server between visits or even connections) and Trust On Every Single Use (if you don't). Really really needs a hard spec for that
antiphase: I don't disagree with your point, but it does imply that a username/password combination does not 'unambigously authenticate the user' as the combo has not been 'signed' by the server in some way.
That is true
i don't see a need for 3rd party authentication on client certs
the first time you see a cert you're creating an account
Reducing client certificates to what amounts to a very long unchangeable username/password combo seems bizarre though
once you have the account created a gemini app can provide methods to add secondary certs
for other devices, for expiring certs, etc
astrobotany has this in practice and i walk through it in my gemini app video
Bouncing of tomasino's point, this is why I view them as session ids and not a username/password.
they are IDs with key-based authentication
better than passwords! :)
You have to ensure no reuse between sites or we're back to tracking again, so every site needs a self-signed certificate issuing per client (because you wouldn't duplicate private keys)
a feature of many clients already, yep!
And is someone going to decide if it's actually a session key (and thus destroyed and the associated account lost after each visit or even TCP connection) or a persistent bearer token
also an option in many clients
key management, backups, and whatnot are a growth area for gemini
people aren't as used to that as passwords, but it's the same concept
Can one of you two fine gentleman help clear something up for me.
whats up?
How much custom metadata can a client embed in a client certificate when it creates it?
Basically, have client certificates worked around the non-extensibility principle of the gemini protocol?
oh, i see
There are no end of predefined extensions to X509 which allow various fields to be added to certificates; the best known of those might be Subject Alternate Name
and then there the DN itself
or subject if you prefer
so you're wondering could someone stuff some extra data in there, like content length, into metadata for the cert? i mean... technically it's possible if the server is set up to read it, but it's a weird thing since certs may be throw-away or they may be ident carrying.
It's a giant inbuilt tracking token, as you would expect the public key and its fingerprint to be globally unique, within reason
So, if I were to create a faithless user-agent, it could embed a unique user-id, user-agent-id, and other identifying information. Servers would then be able to read this. Is this right?
anitphase: I'm trying to determine if it's much worse than just fingerprinting.
if you wrote a naughty gemini client that shoved lots of extra identifying info into TLS that's sent to the server, and then wrote a custom gemini server designed to read that info and store it, then theoretically it's possible
but at that point you could also be sending non-standard meta info in the header
I think if people follow the idea that they get a temporary token that they use to create an account on a system when they first visit, then they can add their own certificate (akin to password reuse) for simplicity and to log in again later, you've created a perfect system for persistently identifying individuals if they aren't aware that keys must never be reused
Cookie's were never designed to be used the way they are. But that didn't stop servers, and clients driven by commercial interests.
https://ttm.sh/bKU.png
tomasino's link to 'https://ttm.sh/bKU.png'
here's Kristall's cert window
need a transient one? they expire after a short time
creating a new identity prompts to attach it to a domain by default
The one thing in favour of gemini is that it is relatively simple to create a new user-agent. At least for the usecase of navigating gemtext files. However, I do wonder if we get a repeat of the HTTP/HTML Browser were servers dynamically inform you that you client does support needed features to use the site, namely the addition of non-standard metadata in the client cert.
the plethora of clients and servers helps avoid the situation where one can demand a non-standard feature because of its dominance. that's the fastest pathway to ignoring the non-extensibility clause
I worry that it was an assumption that could also have been applied to HTTP/HTML browsers, and we all know how that turned out.
the browser wars led to an arms race that complicated things, which led ultimately to a place where a new entrant is nearly impossible. gemini's goal of actively avoiding that pitfall through enforced simplicity is a good one. how long it will work is a question. it doesn't have any other safeguards in place to enforce the rule
lagrange is a great example of the threat
In which way?
it's a run-away popular client. if it starts allowing non-standard things and people start adding those things to their gemini capsules, that's extensibility in exactly the way we're trying to avoid
its dominance gives it power
I see. If it adds support for it's own custom mimetype which happens to support scripting, then it's HTML/Javascript chaos all over again.
it doesn't even need to go that far. if it decides to allow inline links and renders them as clickable, or to bold things surrounded by asterisks, those little things can set new expectations in authors
Lagrange defaults to using one certificate for all pages of a capsule and I already see one capsule that assumes that
in some sense, popular clients are dangerous to the stability of the protocol
Rather than a pegging the cert to the full path and dirs below it.
gemini allows arbitrary mimetypes. you can serve html content over gemini. nobody has tested the line there yet. because it's on gemini should it respect the single document request and not also fetch stylesheets or javascript? what about inline images?
gemtext says no, but what about html? or markdown?
i use and promote Kristall instead of Lagrange to try and diversify the client choices
we have several good clients, but lagrange is sexy too and has a lot of bells and whistles people love
I prefer Kristall's customization options. Lagrange seems very... specific on how it wants to display pages
but anyway, i think our community threat vector is with the popular client rather than the sneaky one trying to abuse TLS certs
Jaakko doesn't seem to want to break things, thankfully
and the community still has pretty strong "don't break it" vibes
but we'll see in a couple years
he's done fantastic things with his client as a solo dev. if a small group or company went at it with a proper design team and put together a rockstar client that put lagrange to shame then we might face the issue again but with people that don't care to keep to spec
If protocols cannot guarantee the behaviour of user-agents, and community standards have shown not to scale (a la HTTP/HTML Browser), then what other options are there for preventing bad user-agents?
Wouldn't the only option be community pressure? There's no way of blocking only a specific browser (and no one wants a way of doing that either)
I think you're right in that the only way to add pressure would be for servers to refuse to serve content to bad actors.
This was done for HTTP/HTML browsers, which is why all user-agent headers where the same for a long while. Identification would have to be based on some cryptographic proof.
It does indeed sound horrible.
yeahhh
TomDotTom: could any protocol or standard ever guarantee compliant use by adopters?
Doubtful. I think at some point it will always come down to people working together to get the overall desired outcome. I don't know if there is any way to every completely guard against people behaving in an unexpected or unwanted way.
ew0k: A protocol is really just a data transport mechanism. I would say it defines very little that is standard and non-standard behaviour on part of the user-agent. A user-agent's behaviour can be codified and outlined in RFCs, but it's ultimitely takes the community of user-agent builders to adhere correctly to standards.
To drive home my point. Cookie's are not part of the HTTP spec, they are defined in their own RFC which covers standard HTTP headers and expected user-agent behaviour.
The early, and obsolete, RFC contained a dedicated section to privacy along with expected user-agent behaviour to allow a user to manage their privacy. I can't remember browsers ever implementing the privacy management recommendations. And in the newest 2011 RFC these privacy recommendations have almost completely disappeared.
The Host request header is a pretty fundamental part of HTTP/1.0+ but that wouldn't have been in the original I guess
You're right in that there are headers that are part of the protocol. Content-Length is another crucial header. But of the headers been passed in HTTP request not that many are needed for the accurate transport between server to client and vice-versa.
One of my biggest gripes about HTTP/1.{0,1} is that it mixed transport headers and client configuration headers.
HTTP/2 elevates some of these headers, but they are still just part of the same header key-value store.
"content-bmi-category: obese"
"content-rating: 3/5 would read again"
"content-emotion: stressed out"
"content-opinion: it's all your fault!"
Man... I would love if pandoc got a gemini conversion thing. Pandoc can already convert to so many other formats...
I hear great things about pandoc. I've had a couple uses for it but it apparently doesn't run on arm which is where I want to use it.
Are you trying to run it on a pi kelbot ?
Or some other ARM device?
pandoc is bloated
