💾 Archived View for lists.flounder.online › gemini › threads › CFJS29B7GMKD.K1Z8E66LYEEC@taiga.gmi captured on 2022-07-16 at 16:22:08. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
From: sir@cmpwn.com
Date: Sun, 07 Nov 2021 20:00:29 +0100
Message-Id: CFJS29B7GMKD.K1Z8E66LYEEC@taiga
To: <gemini@lists.orbitalfox.eu>
In-Reply-To: ab605efa69fce8be90c0fbd195c97eb1@posteo.net
--------------------------------------
Hi! We use BearSSL for gmni/gmnlm/libgmni, and intend to move to BearSSL
for gmnisrv at some point in the future. It does not presently support
TLS 1.3 and it's unclear when it will ship.
https://git.sr.ht/~sircmpwn/gmni
https://git.sr.ht/~sircmpwn/gmnisrv
From: seirdy@seirdy.one
Date: Sun, 7 Nov 2021 13:06:50 -0800
Message-Id: 20211107210650.azmw6sy6hevcgf7h@rkumarlappie
To: "Drew DeVault" <sir@cmpwn.com>
In-Reply-To: CFJS29B7GMKD.K1Z8E66LYEEC@taiga
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
TLDR: skip to the last paragraph ("In conclusion: ...").
On Sun, Nov 07, 2021 at 08:00:29PM +0100, Drew DeVault wrote:
Hi! We use BearSSL for gmni/gmnlm/libgmni, and intend to move to BearSSL
for gmnisrv at some point in the future. It does not presently support
TLS 1.3 and it's unclear when it will ship.
https://git.sr.ht/~sircmpwn/gmni
https://git.sr.ht/~sircmpwn/gmnisrv
I find the idea of using BearSSL for gmnisrv a bit concerning. As a popular Gemini server, switching to a TLS lib that doesn't support TLS 1.3 could make a lot of capsules TLS 1.2-only.
There are many good reasons people to use TLS 1.3 that are quite relevant to Gemini:
- TLS 1.3 can eliminate one or two round-trips. This does more than reduce latency: it can also improve connectivity in high-loss networks.
- TLS 1.3 supports Encrypted Client Hello. This does not yet have a lot of server-side implementations, but this will hopefully change. It eliminates a major source of information leakage (the hostname).
- TLS 1.3 supports record padding. For Gemini, this provides substantial privacy improvements: given that most pages are generally small, random padding will make it extremely difficult to draw conclusions about a user's traffic from content size.
Combine the second and third points together with the fact that fingerprinting is incredibly limited with Gemini and a real potential benefit to Gemini becomes visible: normalizing these features will make it nearly impossible to infer anything about a Gemini user's traffic besides the source+dest IP addresses. It's difficult to overstate just how useful narrowing traffic leakage to a *single vector* is. Public/shared hosting and grassroots CDNs[0] can make it nearly impossible to draw conclusions about people's traffic at scale, let alone implement wide-scale censorship.
[0]: A term I made up to describe a network of people hosting each others' content on each others' servers to achieve the equivalent of a CDN.
In conclusion: I think there is a real benefit to ensuring that all servers support TLS 1.3 with record padding (and optionally ECH); dropping TLS 1.2 is a good first step in that direction.
Drew: Do you plan to wait until BearSSL gets TLS 1.3 support before using it for Gmnisrv? LibTLS (an offshoot of LibreSSL) may be a good place to look in the meantime for a more simple alternative to OpenSSL. I understand that it is your project and not mine, so I make absolutely no demands and will respect your final decision. All I ask is that whatever decision you make in the end, please remember that Gmnisrv is used on a lot of capsules; decisions like this will have far-reaching impacts throughout the Gemini space. The same goes for any other maintainers of popular servers.
-- /Seirdy
From: tidux@sdf.org
Date: Mon, 8 Nov 2021 01:57:53 +0000
Message-Id: 20211108015753.GA16092@ma.sdf.org
To: <gemini@lists.orbitalfox.eu>
In-Reply-To: 20211107210650.azmw6sy6hevcgf7h@rkumarlappie
--------------------------------------
It looks like BearSSL is just waiting for the TLS 1.3 RFC to be
finalized, which is a totally reasonable thing to do. I would encourage
a similar level of patience for Gemini mandating TLS 1.3. Long draft
periods cause early adopters to have all kinds of wonderful broken
implementations that must then be worked around until the next revision
makes them all obsolete. Looking at you, 802.11n.
From: seirdy@seirdy.one
Date: Sun, 7 Nov 2021 19:47:02 -0800
Message-Id: 20211108034702.cldpweklx3wyc5iu@rkumarlappie
To: <tidux@sdf.org>
In-Reply-To: 20211108015753.GA16092@ma.sdf.org
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
On Mon, Nov 08, 2021 at 01:57:53AM +0000, tidux@sdf.org wrote:
It looks like BearSSL is just waiting for the TLS 1.3 RFC to be
finalized, which is a totally reasonable thing to do. I would encourage
a similar level of patience for Gemini mandating TLS 1.3.
TLS 1.3 was finalized in 2018:
https://datatracker.ietf.org/doc/html/rfc8446
This is acknowledged in the first sentence of BearSSL's TLS 1.3 status page:
https://bearssl.org/tls13.html
Long draft periods cause early adopters to have all kinds of wonderful
broken implementations that must then be worked around until the next
revision makes them all obsolete. Looking at you, 802.11n.
There's a balance to strike here. Early adoption at nontrivial scale provides valuable feedback and has thus emerged as a critical part of the collaborative process employed by the IETF. Of course, this doesn't mean we should treat drafts as finalized standards.
In the end, this isn't relevant to TLS 1.3 because TLS 1.3 has been finalized for over three years. Certain optional extensions aren't finalized, though; they make for a separate discussion.
-- /Seirdy
From: sir@cmpwn.com
Date: Mon, 08 Nov 2021 11:08:45 +0100
Message-Id: CFKBDO5SM3PF.1W540LF6GVSDN@taiga
To: "Rohan Kumar" <seirdy@seirdy.one>
In-Reply-To: 20211107210650.azmw6sy6hevcgf7h@rkumarlappie
Cc: <gemini@lists.orbitalfox.eu>
--------------------------------------
Off the bat, I'm not so sure that gmnisrv or gmni really is all that
popular. I use it myself, and I know several other who also use it, but
I suspect that we are in the minority. To be honest, it's not even that
great, it crashes fairly often and is pretty unreliable as a result. The
main appeal is that it is simple and has few dependencies, which are
traits that BearSSL directly contributes to.
Another goal of gmnisrv is to be easy to maintain and reliable over the
long-term, which is something that BearSSL offers and something that
pinning ourselves to bleeding-edge technology witholds. I am very busy
and I don't have the time to invest in, for example, overhauling the SSL
stack for my Gemini software. Gemini is designed to be simple to
implement, and my hope is that it is also simple to maintain.
The advantages of TLS 1.3 are fairly trivial in my opinion. Encrypting
the client hello is nice (though, as you pointed out, not broadly
supported), but what you call "grassroots CDNs" is just another word for
centralization - these are in conflict, and I tend to cast my lot with
decentralized governance more so than ideal privacy. This is fixing it
at the wrong level, anyway - overlay networks like yggdrasil or Tor
actually obsfucate who you're talking to properly (and provide transport
encryption, which is why I would have liked to see optional TLS for
Gemini under certain circumstances...).
As for the other two changes you mentioned: Padding is an improvement.
Performance is not important.
In short, the benefits are marginal, using BearSSL provides us with
greater advantages than disadvantages, and BearSSL better serves the
project's goals. What's more, I don't think I can easily spare the time
to make the necessary changes myself, and these projects are explicitly
designed to be low-maintenance. I can hardly find time for the
improvements I *want* to make, like automatic cert generation based on
Michael Forney's x509 library.
That said, if someone does feel strongly enough about this to put in the
work, I would be willing to accept patches which address the problem. I
very much do not want to use LibTLS, but maybe mbedTLS is a good option.
Any patch would have to provide justification that the alternate TLS
stack is simple, robust, and will be easily maintained in the long term
(and, for what it's worth, OpenSSL is not any of these!).
Also, in the long term, I plan on writing a Gemini stack in my new
programming language, which will probably make gmnisrv and gmni
obsolete. However, we have to make our own crypto stack from scratch
first, so I wouldn't expect to see that any time soon.
From: mbays@sdf.org
Date: Mon, 8 Nov 2021 18:47:12 +0100
Message-Id: YYlioFku5KNUPEAN@localhost
To: "Rohan Kumar" <seirdy@seirdy.one>
In-Reply-To: 20211107210650.azmw6sy6hevcgf7h@rkumarlappie
Cc: "Drew DeVault" <sir@cmpwn.com>, <gemini@lists.orbitalfox.eu>
--------------------------------------
There are many good reasons people to use TLS 1.3 that are quite
relevant to Gemini:
- TLS 1.3 can eliminate one or two round-trips.
- TLS 1.3 supports Encrypted Client Hello.
- TLS 1.3 supports record padding.
Another one I think is particularly important for Gemini:
TLS 1.2 sends client certificates in the clear, while with 1.3 they are encrypted.
Even if the spec doesn't end up mandating 1.3, it might be worth requiring it for servers which make use of client certificates.
Another big advantage of requiring 1.3 is that it would let us use ed25519 certificates (server and client). (I think in theory we could already do this, by choosing a certificate to send depending on which algorithms the remote party says they support, but that adds complexity and I don't know of any implementation which does this.)
From: neruvi[at]disroot[dot]org@
Date: Tue, 9 Nov 2021 08:17:33 +0000
Message-Id: 20211109081733.GA4051@host
To: "mbays" <mbays@sdf.org>
In-Reply-To: YYlioFku5KNUPEAN@localhost
Cc: <gemini@lists.orbitalfox.eu>, "Drew DeVault" <sir@cmpwn.com>
--------------------------------------
On Mon, 2021-11-08, mbays wrote:
Another one I think is particularly important for Gemini:
TLS 1.2 sends client certificates in the clear, while with 1.3 they are
encrypted.
This is the most important one, I think. Sending client certificates in
the clear can be really bad for privacy, especially as they may contain
your e-mail address, username and/or other sensitive information.
Even if the spec doesn't end up mandating 1.3, it might be worth
requiring it for servers which make use of client certificates.
Yep. Discussed here:
https://gitlab.com/gemini-specification/protocol/-/issues/12