š¾ Archived View for bbs.geminispace.org āŗ s āŗ Gemini āŗ 21544 captured on 2024-12-17 at 15:10:19. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
The Gemini protocolās minimalist, privacy-focused design is a refreshing alternative to the traditional, often bloated web. Its reliance on Trust on First Use (TOFU) brings much-needed decentralization and reduces dependence on Certificate Authorities (CAs). However, as Daniel Stenberg and others have pointed out, TOFU has inherent vulnerabilities. Specifically, it requires users to implicitly trust a certificate on the first connection, a model that some believe could benefit from a supplementary validation system.
One promising approach to address this without compromising Geminiās core values is to integrate the Convergence project. Originally designed as a decentralized method for validating certificates, Convergence allows users to check certificates against multiple independent "notaries" instead of relying on a single CA. By implementing Convergence into Gemini, each Gemini server could act as a notary, and Gemini browsers could include a Convergence client. This approach would provide additional verification without introducing a centralized authority, aligning with Geminiās privacy-centric and distributed ethos. Hereās a breakdown of how this could work and why it might be worth considering.
TOFU allows users to pin a certificate the first time they connect to a server, creating a trusted relationship for future connections. However, this initial trust is inherently vulnerable to man-in-the-middle (MITM) attacks, particularly on public networks. Integrating Convergence as an optional validation layer could bolster TOFU by allowing users to verify that the certificate presented by the server matches what is seen by other notaries. Each Gemini server could act as a notary, which would ensure that certificate verification remains decentralized and community-driven.
One of the main appeals of TOFU is that it bypasses the traditional CA system, which can be compromised or co-opted by powerful entities. Convergence offers a way to preserve this CA-free model while adding an extra layer of validation, allowing users to select trusted notaries based on their preferences. This would let Gemini users maintain control over who they trust and reduce reliance on any single organization or authority.
One of Stenbergās criticisms of TOFU is the lack of a certificate revocation or management system. With Convergence, users could benefit from community-verified certificates without sacrificing Geminiās decentralized ethos. If a serverās certificate changes (e.g., due to a compromised key), the notary network could detect this discrepancy, alerting users before they automatically trust the new certificate. While not a complete solution to revocation, this system would offer Gemini users a practical middle ground.
One of the advantages of integrating Convergence into Gemini is the collaborative, community-driven model it could foster. By allowing each Gemini server to act as a notary, Gemini users would contribute to a collective security system, making the protocol stronger as it grows. This approach could help address concerns about scalability, as each additional server strengthens the notary network.
As with any protocol change, there are valid concerns and potential counterarguments to this proposal. Here are some common objections and responses:
Response: While adding Convergence would introduce additional layers, it could be designed as an optional feature for users and servers who seek added security. For users who prioritize simplicity over additional security, they could choose to bypass the Convergence layer and rely on TOFU alone. Moreover, since each Gemini server could function as a notary, the complexity of setting up external notary infrastructure would be minimized, preserving Geminiās straightforward deployment model.
Response: To address this, notary requests could be anonymized or limited to avoid disclosing which servers a user is connecting to. Additionally, users could select trusted notaries based on their own preferences, allowing them to avoid any servers they deem untrustworthy. This would let users maintain privacy while still benefiting from added certificate validation.
Response: While TOFU is effective for low-stakes, content-driven browsing, many users might appreciate an optional added layer of verification, especially in sensitive environments or on untrusted networks. The Convergence layer wouldnāt replace TOFU; rather, it would supplement it, offering more choices for users who need it without disrupting the experience for those who donāt.
Response: Convergence allows users to choose multiple independent notaries, mitigating the risk of a single compromised notary. Users can update their trusted notaries as they see fit, avoiding dependence on any one entity. This distributed model offers resilience against centralized attacks while giving users more control over their security setup.
Response: While there would be an initial setup to act as a notary, maintenance requirements could be minimized by automating notary tasks or offering opt-in participation. This approach allows only those who wish to operate as notaries to do so, ensuring that the system remains voluntary and accessible.
Incorporating Convergence into Gemini could offer a novel way to enhance TOFU without compromising the protocolās fundamental principles. This approach could provide Gemini users with added security options without introducing a centralized authority, enabling Gemini to scale and evolve while remaining true to its decentralized, privacy-focused roots. By allowing each Gemini server to act as a notary and integrating a Convergence client in Gemini browsers, the Gemini protocol could establish a flexible, community-driven trust model.
While this approach would require collaboration and careful consideration, it represents a promising path forward for Geminiās security model. It leverages the best of TOFUās simplicity and Convergenceās collaborative verification to create a protocol thatās both resilient and responsive to user needs.
https://en.wikipedia.org/wiki/Convergence_(SSL)
https://moxie.org/2011/04/11/ssl-and-the-future-of-authenticity.html
https://github.com/moxie0/Convergence
Nov 04 Ā· 6 weeks ago Ā· š CitySlicker
š¦ zzo38 Ā· Nov 05 at 00:18:
I also had a idea for decentralized validation, where anyone could sign anyone else's certificate; a DER file could be available by any protocol (TLS is not needed, although it is OK if you have it) or disk, which lists with certificates you approve and the details of the approval, including which extensions of the certificate you understand and which you don't, and what details you trust (e.g. the Common Name). It could also be used with what you describe. I wrote on a paper about the schema, and I will mention it here later when I write it on the computer.
Additionally, I also had a idea about superseding self-signed X.509 certificates. This is currently mentioned in the Scorpion protocol specification (in the section about X.509 extensions), but I think there might be a problem with it. I will post a separate message with my comments about how it is now and what I think it might be changed to.
ā Superseding X.509 certificates
š¦ CarloMonte Ā· Nov 05 at 06:54:
Please don't resurrect GPG. Joke apart, the proposed scheme lacks transparency and simplicity, which Gemini explicitely promotes at the expense of security.
š» mediocregopher [...] Ā· Nov 05 at 07:21:
All "problems" with TOFU can be solved with DANE. It would require no changes to Gemini servers or their certificates at all, and can be an optional check performed by clients. It relies on existing infrastructure (DNS, DNSSEC), and is already a standard with many different implementations existing and wide-usage as a security mechanism for email.
There's no need to introduce something new. I'm not even sure there's need to introduce something at all; TOFU works fine for gemini, it's not like we're doing our banking here.
šŗ daruma Ā· Nov 05 at 07:22:
Are there really users out there that want more secure Gemini? Or is this just a tech/programmer desire to expand the protocol? I think the idea of security also depends on the use case of a technology; if I use technology for the fun of it, why would it need to be secure? For me Gemini is enjoyable because it doesn't need to be secure, there aren't countless password, 2fa, captcha etc..
š zeerooth Ā· Nov 05 at 08:44:
I agree with @mediocregopher - we already have DANE, which is decentralized as well, and actually already a part of gemini spec as a recommendation for clients as an additional security measure for validating certificates.
š mbays Ā· Nov 05 at 22:18:
Is there a spec for this Convergence scheme? From the information in the links, I expect that it's too complicated to have a chance of being adopted by gemini developers (and the same probably goes even for the simplest notary schemes).
š mbays Ā· Nov 05 at 22:18:
I did find Moxie's criticisms of DANE in the second link interesting, by the way.
āļø tenno-seremel Ā· Nov 06 at 07:28:
@daruma Because otherwise an ISP can MitM you and censor or add any data (which youād think comes from someone elseās mouth), or feed your system a 0-day exploit to monitor you better. Although I donāt think the thing that OP suggests is a solution Iād want.