Request for feedback from server/client implementers using\n non-OpenSSL TLS stacks

Rohan Kumar seirdy at seirdy.one
Sun Nov 7 21:06:50 GMT 2021
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


Archive home | About this archive