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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211107/73698652/attachment.sig>


More information about the Gemini mailing list