💾 Archived View for gemi.dev › gemini-mailing-list › 001070.gmi captured on 2024-03-21 at 18:16:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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
On Sun, Nov 07, 2021 at 04:07:05PM +0000, Solderpunk <solderpunk@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.)
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
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@nytpu.com gpg --locate-external-key alex@nytpu.com
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
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
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
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.
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
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.
Solderpunk <solderpunk@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@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
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
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.
---