Neither Gemini nor the Internet Archive have access to the content through a channel other than the insecure HTTP endpoint, right?
All Gemini is signed. [0] It's mandatory. That's why the parent piped through openssl to connect.
For example, the page that we're looking at is signed. [1] (Using a bridge to show the certificate, but you can verify it yourself, as well.)
[0] https://gemini.circumlunar.space/docs/specification.html
[1] https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...
> CA/[email protected]
> CN=gemini.conman.org/[email protected]
> 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. 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).
> TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. 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. 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.
> This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
OpenSSH's TOFU works in its specific context primarily because SSH targets have been connected to beforehand and you can't place an evil proxy between. In order to prevent issues with TOFU, we've got SSHFP DNS records (so, trusting DNSSEC).
Now with the web, it's already rather ridiculous to suggest that it's not a terrible security model to not visit any new websites on untrusted connections. Plus the seeming lack of alternative methods (like SSHFP/TLSA + DNSSEC) to establish trust with untrustworthy networks (which well, most networks should be considered as).
If you're worried about key continuity issues, do what large SSH fleet deployers do, and use certificates. Key continuity was the motivating use case for SSH certificates, before they were used to do MFA/SSO logins for users.
I don't disagree with the analysis of Gemini's trust model; I think you're right that key continuity doesn't work on the scale of the public web. Of course, I don't think DNSSEC has any answers here, either; the Web PKI is probably the best thing we've got right now.
Though in theory, just using SSHFP+DNSSEC and those operators being malicious shouldn't degrade SSH's security, it should only hinder the same TOFU. In which case I suspect people would fall back to the Web PKI to look up the reason for the mismatch.
Regarding the issue of "integrity", i.e., not being modified in transit, ideally all www pages could have a hash (signature), or "digest", of the page content. As long as the www user can obtain the signature over a secure channel then, in theory, integrity can be verified. The content could be sent over an insecure channel and integrity could still be verified. This sort of verification has long been common (well before HTTPS became widespread) when downloading files, namely, software, e.g., as tarballs.
The problem with using an intermediary that has crawled the www, whether it is IA or Google or whomever, is that the www user has no way to know how the content was retrieved. How does every www user know that the pages in Google's index that they are purportedly searching were accessed via HTTP or HTTPS. The only people who would have firsthand knowledge of the retrieval are those who observed it. As such, there is some (misplaced) trust involved when people use IA, Google or other intermediaries.
Personally, if I am forced to use an intermediary, e.g., a web archive, a search engine, a third party DNS provider, etc., then I try to use multiple intermediaries to obtain the same data, then compare. This does not solve the problem, but it is arguably better than trusting any particular intermediary.
Ideally, web page authors and intermediaries could provide signatures for the web pages they serve. (The same way that software authors provide signatures for the archives of the software they publish.) For example, if one uses Common Crawl then one gets a "WARC-Payload-Digest" header. For example, the payload digest for example.com's index.html is currently
WARC-Payload-Digest: sha1:JI6OR3QR4CI526JD6TMMNZNV4QPMPQCH
If its signature was published by the original source, then there could be multiple sources for example.com's index.html across the web. Each copy would match the same signature published by the author of example.com's index.html. This practice has long been used in software distribution where multiple "mirrors" contain copies of the same files.
I still find there are numerous "insecure HTTP endpoints" in operation on the www. It seems to me that as long as these are concealed, no one complains about them. I recently commented about this with respect to podcasts. A surprising number of podcasts are being served over HTTP. But as long as the podcast listener is unaware of how their software is accessing them, no one complains about potential modification in transit or other issues with using an insecure channel.
That's the unfortunate reality of trust as a currency... On average, people are way more likely to trust Google, a household name, than Gemini, a three-year-old brand-new protocol with its own mystery set of new and exciting not-yet-discovered security issues.
Google does mis-crawl all the time (in fact, they have a whole division dedicated to confirming whether sites aren't detecting their crawler and actively lying to them; sites that do get penalized in search results). But it's Google, so people believe they have a vested interest in getting it right. There's no such guarantees in people's minds for data coming over Gemini protocol; it hasn't been earned yet.
IMHO, at best Gemini is a Gopher redux. No one is planning to run commerce over Gopher. It is no different for Gemini. It's a "people's protocol", not a corporate one. It does not even have an RFC. It's relatively easy to write clients and servers. No corporate vendor or advertising sponsorship is needed. No one needs to have a "business model" to publish data/information via Gemini.
The Gemini FAQ explicitly addresses critics who see the internet through web-tinted glasses:
1.6 Do you really think you can replace the web?
Not for a minute! Nor does anybody involved with Gemini want to destroy Gopherspace. Gemini is not intended to replace either Gopher or the web, but to co-exist peacefully alongside them as one more option which people can freely choose to use if it suits them. In the same way that some people currently serve the same content via gopher and the web, people will be able to "bihost" or "trihost" content on whichever combination of protocols they think offer the best match to their technical, philosophical and aesthetic requirements and those of their intended audience.
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. 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).
TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. 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. 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.
This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
Most ISP's can't be trusted, TOFU becomes basically useless. Ignoring that major issue with the model, it's also unusable in especially untrustworthy networks like Airport WiFi. I'm also going to preemptively say that suggesting not to visit new websites on those networks (because you can't TOFU) is just ridiculous.
"It is not awful" in this context is a very strong claim with little backing it up.
Why not just use HTTPS on the "untrustworthy" ISP's.
The use of the word "most" implies that there are some that can be trusted.
Assuming you are a trustorthy source for such information (and how do I know it's really you and not an "imposter"), then what are they. Please list the ISPs everyone can "trust".
The point that is being missed in this comment thread, and most others about TLS, HTTPS and CAs, is that there is a question of who decides whether something is "trustworthy" or not.
Personally I like to make these decisions for myself. Unlike an incredible number of internet commentators, I do not purport to tell anyone else who they should or should not trust. That decision is ultimately for each person to make on their own. We can provide information that may help a person with their decision, but it's still their decision, not mine.
But that's not how "chain of trust" works.
The concept of "chain of trust" itself does not even exist in the real world. It only exists in the imagination of socially inept persons hiding behind keyboards. In practice, for HTTPS, the cast of characters is a laundry list of third party intermediaries, all trying "cash in" on the use of the internet, a public resource we already pay ISP's to access. The idea that any of them would be sources of "trust" is comical.
Why trust "domain name registrars" as a source of useful information about people who run websites.
Why trust CAs issuing non-EV certificates. They only verify that someone rents a domain name from an "ICANN-approved" registry.
Why trust CAs issuing EV certificates. The people approving these CAs all have a vested interest in the web (browser) as a means of online advertising.
Why trust the people who "approve" CAs for inclusion in popular web browsers.
There are something like 75 CAs hardcoded into popular web browsers. If I want to remove one, what do I have to edit the source code and recompile. Inconvenient to say the least.
In all of this third party nonsense, there is no opportunity for an ordinary person, not invested in or benefitting from the "tech" company racket, to have any input on whether or not she wants to "trust" a website is being operated by a particular person. She is effectively locked out of the process. These third parties are often comprised of people I would never trust IRL. But they hide behind keyboards so we never get to see them for what they are.
At least with Gemini, clients and servers are smaller and simpler, and easy to edit and recompile. Gemini clients, written by anyone, not necesarily "tech" companies, are not designed with online advertising in mind. The protocol itself is not "advertising-friendly". It is little more than plain text.
The "threat model" for me in the majority of web use is the "business model" of so-called "tech" companies, i.e., surveillance, data collection and advertising, not "imposters". Nevermind that "tech" companies have pushed for a web that is 100% commercial/political, where even recreational use is monitored for insights useful to advertising. That only creates a greater incentive for "imposters". When I started using the internet it was still predominantly used for academic and military purposes.
If a "tech" company employee wants to choose to use HTTPS, DNSSEC, TOFU, etc., then that is their decision. But if they want to remove the ability of anyone else to make that decision for themselves, then I see a problem with that.
I don't know, ask the Gemini people.
> The use of the word "most" implies that there are some that can be trusted.
Only a Sith deals in absolutes. I'm sure someone out there is their own ISP and can trust themselves.
> Personally I like to make these decisions for myself.
Sure, you do you. That doesn't make it a widely viable neither mostly secure approach.
This blog can be read over TLS using gemini://.
Alsohttps://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...