3 ms·

Do either of these address the underlying problem that without https there's no guarantee that the blog content hasn't been modified in transit? Neither Gemini

Do either of these address the underlying problem that without https there's no guarantee that the blog content hasn't been modified in transit? Neither Gemini nor the Internet Archive have access to the content through a channel other than the insecure HTTP endpoint, right?

shakna 4y ago
> 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 https://gemini.circumlunar.space/docs/specification.html [1] https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/09/22.1?crt=1 https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...
- yardstick 4y ago
  Is that signature from the original author, or from an intermediary/Gemini proxy?
  - shakna 4y ago
    The authour. You can see their domain in the email that makes the signature. > CA/emailAddress=ca@conman.org > CN=gemini.conman.org/emailAddress=sean@conman.org
    - shadowgovt 4y ago
      This is a self-signed cert with no chain of trust to a cert issuer, which means we're back to square one... No way to know that whoever is providing the data to Gemini isn't lying about being Conman Laboratories.
      - deleted 4y ago
        [deleted]
      - shakna 4y ago
        Again, that's part of the Gemini spec. > 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.
        Avamander 4y ago
        That is a terrible security assessment and it is an awful model for the web. 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).
        4y ago
1vuio0pswjnm7 4y ago
The Gemini to WWW portal does have access to the content via TLS1.2 or greater, as that is the only way content is served under the Gemini protocol. AFAIK, Internet Archive (IA) does not crawl gemini://. I thought perhaps IA might have crawled https://portal.mozz.us https://portal.mozz.us, but I was mistaken. 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 Of course, that digest should be published by the author of example.com's index.html. 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.

shakna 4y ago

> 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 https://gemini.circumlunar.space/docs/specification.html [1] https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/09/22.1?crt=1 https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...

yardstick 4y ago
Is that signature from the original author, or from an intermediary/Gemini proxy?
- shakna 4y ago
  The authour. You can see their domain in the email that makes the signature. > CA/emailAddress=ca@conman.org > CN=gemini.conman.org/emailAddress=sean@conman.org
  - shadowgovt 4y ago
    This is a self-signed cert with no chain of trust to a cert issuer, which means we're back to square one... No way to know that whoever is providing the data to Gemini isn't lying about being Conman Laboratories.
    - deleted 4y ago
      [deleted]
    - shakna 4y ago
      Again, that's part of the Gemini spec. > 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.
      - Avamander 4y ago
        That is a terrible security assessment and it is an awful model for the web. 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).
        4y ago

1vuio0pswjnm7 4y ago

The Gemini to WWW portal does have access to the content via TLS1.2 or greater, as that is the only way content is served under the Gemini protocol. AFAIK, Internet Archive (IA) does not crawl gemini://. I thought perhaps IA might have crawled https://portal.mozz.us https://portal.mozz.us, but I was mistaken. 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 Of course, that digest should be published by the author of example.com's index.html. 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.