anything to worry about

* * * * *

It's not a “security hole,” it's a “privacy hole” and I don't think it's
anything to worry about

I found a reference to the following in my notes from May this year—I suppose
better late than never. Anyway …

> The Potential Security Hole
>
> …
>
> Imagine a scenario where Big Tech does a massive marketing campaign in an
> attempt to mainstream the protocol. As part of their marketing, they could
> try to sell the idea of a Big Proprietary browser, or even add Gemini
> support directly into their existing web browser. Then they start a
> disinformation campaign to demonize the wide range of existing clients.
> Normies, naturally, would buy that without question, as they do. At that
> point, Big Tech could simply have their browser automatically generate a
> client certificate for every user and attach it to every request.
>
> Couple this with some server side analytics aggregators, and we have the
> same privacy problems on Gemini that the web has.
>

“Security Hole in Gemini Protocol? [1]”

I feel this is more of a “privacy hole” than a “security hole” but that's
could be me being pedantic. Honestly, I don't feel like this is anything that
needs to be worried about. Gemini [2] is much too small to worry about. I
suppose a Gemini server could generate client certificates and a compliant
Gemini client could accept them for later use to reference a Gemini site, but
that's not now client certificates are specified as working— it's the client
that generates the certificate and the server can accept or reject it (odd, I
know, and not how I would envision them working).

But it's not like there aren't other ways for tracking a user in Gemini. A
Gemini server could conceivably generate unique links for a given client from
a given IP (Internet Protocol) address. It's not perfect, and it really only
kind of tracks a single user. And let's not forget just logging every request
and <gasp!> not anonymizing IP addresses! Oh the horror! But such “tracking”
is only limited to one server. It seems silly that such tracking could be
done Internet wide, especially given that automatically displaying of images
is considered scandalous in the Gemini community.

> Notice that all of these codes are described in way that implies that the
> server is already expecting a client certificate for that request. What if
> there is a certificate attached when not expected? Unless I have missed or
> misinterpreted something, the spec does not account for this.
>
> 61 comes close, but that implies that a cert was indeed expected, it's just
> the wrong one.
>
> Proposed Solution
>
> Add 4th certificate status code, let's call it 63, to be returned in this
> scenario. It would not stop malicious or corporate servers from refusing
> ever to return this code, but it would at least allow users to see which
> sites are not trying to stalk them, because someone using Flashy
> Surveillance Browser would be shown this error anytime they visit an indie
> capsule.
>
> Could this itself be exploited, though? I think so. Proprietary browsers
> could show a 'security warning' that the capsule they are attempting to
> access is … insert scary corporate buzzword … and that proceeding would be
> 'dangerous'. This, of course, would be total horseshit but the normies
> wouldn't know any better.
>

“Security Hole in Gemini Protocol? [3]”

I have two responses to this: One, just do it! Add the check to your Gemini
server and return the undocumented response code 63. Yes, it's not part of
the standard. Yes, it's extending the protocol (“The horror! The horror!”).
But on the gripping hand, it just might help. My own Gemini server [4] serves
up a custom error code when it receives an empty request which is expressly
not allowed by the specification! I used to serve up a response code of “59
Bad Request” but it never seemed to do anything. I then changed it to return
“58 Not a gopher server!” and while it hasn't stopped such requests, they
have been slowly going down over the past year or so. So go ahead, just do
it! Add the “63 Why are you forcing an unwanted certificate on me?” response.

My second response is—client certificates are dead on the web, what makes you
think “proprietary Gemini browsers” will go to this trouble? If anything, I
would think a “propriatary Gemini browser” would insist on using a real
secure certificate, and not a self-signed one or one using a custom
certificate authority, long before it would attempt to force known client
certificates on users.

[1] gemini://ainent.xyz/gemlog/2022-02-16-security-hole-in-gemini-
[2] https://gemini.circumlunar.space/
[3] gemini://ainent.xyz/gemlog/2022-02-16-security-hole-in-gemini-
[4] https://github.com/spc476/GLV-1.12556
---

Discussions about this page

Thoughts on Privacy Exploits in Gemini
gemini://jsreed5.org/log/2022/202212/20221228-thoughts-on-privacy-exploits-in-gemini.gmi

Email author at [email protected]