~adnano/gemini

13 11

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

Details
Message ID
<ab605efa69fce8be90c0fbd195c97eb1@posteo.net>
DKIM signature
missing
Download raw message
Howdy all,

When I started Gemini I dearly wanted to specify that TLS 1.3 be the 
minimum allowed version of TLS.  However, I didn't because at that time 
TLS 1.3 was still not very widely implemented and I did not want to 
basically make it a requirement that all Gemini implementations rely on 
OpenSSL.  In particular, I didn't want to exclude the possibility of 
using LibreSSL instead.  So, instead I required 1.2 or above and left 
lots of caveats in the spec to make my feelings clear.

I have checked in on this issue for the first time in a while, and at 
least according to the English Wikipedia's "Comparison of TLS 
implementations", TLS 1.3 is now supported by OpenSSL, LibreSSL, GnuTLS 
and wolfSSL, and is "experimentally" supported by Mbed TLS (these last 
two are of somewhat special interest/appeal as they target embedded 
systems and so are much more lightweight than traditional TLS stacks).  
This gives me some glimmer of hope that as part of the spec finalisation 
we could actual require 1.3 or above as I always wished.

But I realise that there's potentially a lot of difference between 
between a green box on a Wikipedia page and actual practical, compatible 
real world implementation.  So I would like to ask authors of Gemini 
servers or clients which use a TLS stack other than OpenSSL whether or 
not they have encountered any problems actually using TLS 1.3.

I would also like to ask anybody who runs an Gemini indexer/crawler who 
might have the data at hand if they can provide us with some kind of 
statistics on the current real-world Gemini TLS version landscape.

Cheers,
Solderpunk
Stephane Bortzmeyer <stephane@sources.org>
Details
Message ID
<YYf7lMLoWii/K2kI@sources.org>
In-Reply-To
<ab605efa69fce8be90c0fbd195c97eb1@posteo.net> (view parent)
DKIM signature
missing
Download raw message
On Sun, Nov 07, 2021 at 04:07:05PM +0000,
 Solderpunk <solderpunk at posteo.net> wrote 
 a message of 31 lines which said:

> I would also like to ask anybody who runs an Gemini indexer/crawler
> who might have the data at hand if they can provide us with some
> kind of statistics on the current real-world Gemini TLS version
> landscape.

gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi

86?% of the capsules use TLS 1.3, 14?% use TLS 1.2.

(The code currently assumes a capsule is fully TLS 1.3 or fully TLS
1.2. Strange things will happen otherwise.)
Details
Message ID
<2dd47dcf95853beec7f85ea73dbf8935@posteo.net>
In-Reply-To
<YYf7lMLoWii/K2kI@sources.org> (view parent)
DKIM signature
missing
Download raw message
On 07.11.2021 17:15, Stephane Bortzmeyer wrote:

> gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
> 
> 86?% of the capsules use TLS 1.3, 14?% use TLS 1.2.

Thank you!  That is encouraging.  But it might just reflect the fact 
that most Gemini software is based on OpenSSL.  I will feel even happier 
if get confirmation from people running software based on LibreSSL or 
WolfSSL that TLS 1.3 is working smoothly in practice for them on a 
regular basis.

Cheers,
Solderpunk
Details
Message ID
<20211107170106.p4dex2k6rdiz3ocr@GLaDOS.local>
In-Reply-To
<ab605efa69fce8be90c0fbd195c97eb1@posteo.net> (view parent)
DKIM signature
missing
Download raw message
As of late 2019 client-side TLS 1.3 for LibreSSL was implemented, which
I can confirm.  Server support was completed by mid-to-late 2020 but 1.3
support for their OpenSSL API clone wasn't finished yet.

Apparently in the latest LibreSSL release (3.4.1, October 14th) they
completed their implementation of the OpenSSL TLS 1.3 API, which means
that an up-to-date LibreSSL should have full support for TLS 1.3 through
all of their various APIs as of now---although I can't confirm it since
I use LibreSSL very intermittently and usually just for testing of
cross-compilation to a BSD.

I've been using GnuTLS a little bit in Ada and it seems to support 1.3
fine although my testing was at the absolute most basic level.
According to various developer's blogs and the changelog GnuTLS got TLS
1.3 support before the RFC draft was even finalized (even as far back as
2016 when it was in an ultra-draft state), so one can feel pretty safe
in assuming that any broken functionality would've been fixed by now.

I don't have experience with any other TLS libraries, sorry.

---

Vaguely related question: prior to the specification being finalized, is
there any plan to ensure that support for future TLS versions to be
supported implicitly?  Something simple like "Clients MAY/MUST use TLS
1.3 (or the latest TLS version should TLS 1.3 be deprecated)" would be
better than being stuck at TLS 1.3 forever.

~nytpu

-- 
Alex // nytpu
alex at nytpu.com
gpg --locate-external-key alex at nytpu.com

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

Details
Message ID
<CFJS29B7GMKD.K1Z8E66LYEEC@taiga>
In-Reply-To
<ab605efa69fce8be90c0fbd195c97eb1@posteo.net> (view parent)
DKIM signature
missing
Download raw message
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

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

Details
Message ID
<20211107210650.azmw6sy6hevcgf7h@rkumarlappie>
In-Reply-To
<CFJS29B7GMKD.K1Z8E66LYEEC@taiga> (view parent)
DKIM signature
missing
Download raw message
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
Jacob Moody <moody@posixcafe.org>
Details
Message ID
<c0745055-dcec-97e0-0b18-4de0352ce52e@posixcafe.org>
In-Reply-To
<2dd47dcf95853beec7f85ea73dbf8935@posteo.net> (view parent)
DKIM signature
missing
Download raw message
Greetings Solderpunk,

I know there is a small but fairly active group of people who are using gemini
from the comfort of plan9/9front, myself included. 9front has it's own
TLS stack instead of relying on POSIX-y implementations, and at the time of
writing 9front's implementation only supports up to TLS 1.2.

Getting 1.3 implemented is on a list of things to do, but no real
work has started on it from what I could tell. While I understand
it doesn't make much sense to hold back for the sake of an otherwise
small fringe group, I wanted to point out a hard requirement on TLS 1.3
would (perhaps momentarily) prevent the use of gemini on 9front should
these requirement get set and strictly enforced.

Thank you,
moody

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

Details
Message ID
<20211108015753.GA16092@ma.sdf.org>
In-Reply-To
<20211107210650.azmw6sy6hevcgf7h@rkumarlappie> (view parent)
DKIM signature
missing
Download raw message
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.

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

Details
Message ID
<20211108034702.cldpweklx3wyc5iu@rkumarlappie>
In-Reply-To
<20211108015753.GA16092@ma.sdf.org> (view parent)
DKIM signature
missing
Download raw message
On Mon, Nov 08, 2021 at 01:57:53AM +0000, tidux at 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

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

Details
Message ID
<CFKBDO5SM3PF.1W540LF6GVSDN@taiga>
In-Reply-To
<20211107210650.azmw6sy6hevcgf7h@rkumarlappie> (view parent)
DKIM signature
missing
Download raw message
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.
Jason McBrayer <jmcbray@carcosa.net>
Details
Message ID
<87fss6wx00.fsf@cassilda.carcosa.net>
In-Reply-To
<ab605efa69fce8be90c0fbd195c97eb1@posteo.net> (view parent)
DKIM signature
missing
Download raw message
Solderpunk <solderpunk at posteo.net> writes:
> But I realise that there's potentially a lot of difference between
> between a green box on a Wikipedia page and actual practical,
> compatible real world implementation.  So I would like to ask authors
> of Gemini servers or clients which use a TLS stack other than OpenSSL
> whether or not they have encountered any problems actually using TLS
> 1.3.

I'd like to note that in my CL Gemini implementations (Germinal server,
and cl-gemini-client client), I /do/ use OpenSSL, and /support/ TLS 1.3,
but due to the way the cl+ssl wrapper is written, I'm unable to force
TLS 1.3-only. I've tried to submit patches upstream that would enable
doing so, but it's too hard for me to meet the requirements for multiple
CL implementations and multiple OpenSSL versions, so I've kind of given
up.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

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

Details
Message ID
<YYlioFku5KNUPEAN@localhost>
In-Reply-To
<20211107210650.azmw6sy6hevcgf7h@rkumarlappie> (view parent)
DKIM signature
missing
Download raw message
* Sunday, 2021-11-07 at 13:06 -0800 - Rohan Kumar <seirdy at seirdy.one>:

>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.)

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

Details
Message ID
<20211109081733.GA4051@host>
In-Reply-To
<YYlioFku5KNUPEAN@localhost> (view parent)
DKIM signature
missing
Download raw message
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
Ben Goldberg <ben@benaaron.dev>
Details
Message ID
<dc2cc67a-c5e7-057e-b1df-f6830c521156@benaaron.dev>
In-Reply-To
<ab605efa69fce8be90c0fbd195c97eb1@posteo.net> (view parent)
DKIM signature
missing
Download raw message
Sorry for talking a while to respond to this, I'm not very active here.

> But I realise that there's potentially a lot of difference between 
> between a green box on a Wikipedia page and actual practical, compatible 
> real world implementation.? So I would like to ask authors of Gemini 
> servers or clients which use a TLS stack other than OpenSSL whether or 
> not they have encountered any problems actually using TLS 1.3.
> 

stargazer uses rustls exclusively and I've had no problems with using 
TLS 1.3. rustls in fact only supports TLS 1.2 & 1.3, so I've haven't had 
to do anything special to restrict the use of older versions.
Reply to thread Export thread (mbox)