💾 Archived View for gemi.dev › gemini-mailing-list › 000256.gmi captured on 2024-05-26 at 15:35:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
There are several contributing factors to TLS overhead. Some of it is network based, to do with actually downloading the certificate, and doing the handshake. Some of it is computation based, to do with the key exchange calculations. Which is the more important bottleneck will differe between applications. In cases where network overhead is more important, getting down the size of the certificate may help. My AV-98 TOFU database has 103 certificates stored in it. The mean size is 1247 bytes - about as large, IIRC, as the average text/gemini document. 95% of certificates range in size between 704 bytes and 1634 bytes. However, the smallest certificate I have encountered belongs to cozylabs.eu. It is 273 bytes, i.e. 20% of the average! Or, about 1 KiB smaller than average. That's 1KiB less network traffic for each request to that server compare to a typical server. cozylabs.eu achieves this feat with a single self-signed ED25519 certificate. For folks who want to ditch the CA system and embrace TOFU, this is clearly the way to do it. I will migrate gemini.circumlunar.space to this style of certificate in the near future. Unfortunately making this kind of cert with the `openssl` tool is not as straightforward as other options. The standard library for Go seems up to the task. I will write a small and simple bulletproof program to generate these certs next week, and document it well. It will be handy not only for server admins but people who want to generate their own client certs for use with clients like Alphonse. Stay tund... Cheers, Solderpunk
> On Jun 26, 2020, at 15:56, solderpunk <solderpunk at SDF.ORG> wrote: > > Unfortunately making this kind of cert with the `openssl` tool is not > as straightforward as other options. Does anyone have a reasonable recipe for openssl? Stumbled upon this: Create ED25519 certificates for TLS with OpenSSL https://blog.pinterjann.is/ed25519-certificates.html Is that a reasonable approach? Or? > The standard library for Go seems > up to the task. I will write a small and simple bulletproof program to > generate these certs next week, and document it well. It will be handy > not only for server admins but people who want to generate their own > client certs for use with clients like Alphonse. Stay tund... > Looking forward to it.
solderpunk <solderpunk at SDF.ORG> writes: > cozylabs.eu achieves this feat with a single self-signed ED25519 > certificate. For folks who want to ditch the CA system and embrace > TOFU, this is clearly the way to do it. I will migrate > gemini.circumlunar.space to this style of certificate in the near > future. I would like to do this for my server, but I'm concerned about changing the certificate when there are people actually using TOFU. Do we have a best practice note on changing certificates? -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
On Fri, Jun 26, 2020, at 1:56 PM, solderpunk wrote: > cozylabs.eu achieves this feat with a single self-signed ED25519 > certificate. For folks who want to ditch the CA system and embrace > TOFU, this is clearly the way to do it. I will migrate > gemini.circumlunar.space to this style of certificate in the near > future. > > Unfortunately making this kind of cert with the `openssl` tool is not > as straightforward as other options. The standard library for Go seems > up to the task. I will write a small and simple bulletproof program to > generate these certs next week, and document it well. It will be handy > not only for server admins but people who want to generate their own > client certs for use with clients like Alphonse. Stay tund... Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)". This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. ~ Case (acdw)
> Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)". > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. Using Kristall works and it's blazingly fast, seems to be a correct server configuration Regards - xq
On Fri, Jun 26, 2020, at 3:05 PM, Felix Quei?ner wrote: > > > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)". > > > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. > Using Kristall works and it's blazingly fast, seems to be a correct > server configuration > > Regards > - xq Hm, must be an issue with my network (I'm at work) then -- sorry for clogging up the ML! I'll try again at home tonight. ~ acdw
Felix Quei?ner <felix at masterq32.de> writes: >> Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, >> or actually any gemini browser, including AV-98: the error there is "ERROR: >> [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key >> parameters (_ssl.c:1108)". >> >> This makes me think it's an error with the server, as opposed to the ED22519 >> key; I'd love to try another server with this type of certificate for testing. > Using Kristall works and it's blazingly fast, seems to be a correct > server configuration Works fine in elpher, too. It actually works for me in AV-98 and openssl s_client, though, so this may be dependent on OpenSSL version? I have openssl-1.1.1g installed, but I understand there are lots of systems out there still on 1.0.x. (Note: this is a big reason why it's hard to do the "limit to TLS 1.3 or 1.2 with good cyphers: the wide use of ancient OpenSSL versions. It's also why Germinal doesn't actually forbid TLS 1.1 connections: the method for doing so has changed between OpenSSL 1.0 and 1.1, and the library I'm using doesn't support the 1.1 method.) -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
Hi there, I am the author of cozylabs.eu. > However, the smallest certificate I have encountered belongs to > cozylabs.eu. It is 273 bytes, i.e. 20% of the average! Or, about 1 KiB > smaller than average. That's 1KiB less network traffic for each > request to that server compare to a typical server. > > cozylabs.eu achieves this feat with a single self-signed ED25519 > certificate. For folks who want to ditch the CA system and embrace > TOFU, this is clearly the way to do it. I will migrate > gemini.circumlunar.space to this style of certificate in the near > future. > > Cheers, > Solderpunk The code that i use to generate my certificate is as follows: https://git.sr.ht/~jzs/cozylabs.eu-gemini/tree/master/server.go#L263 It might serve as an inspiration to making a generic standalone certificate generator for those interested. Kind regards, Jens.
On Fri, Jun 26, 2020 at 03:03:47PM +0000, Case Duckworth wrote: > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)". > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. I suspect the issue is old openssl version, which version are you using? I am using the lastest libressl and I have the same problem. OpenSSL only recently added support for ed25519, so libressl might not have it yet. Paper
Hey, > I will write a small and simple bulletproof program > to > generate these certs next week, and document it well. It will be > handy > not only for server admins but people who want to generate their own > client certs for use with clients like Alphonse. Stay tund... > > Cheers, > Solderpunk Just a heads-up that go has a few of these already, including IP SANs. The one I usually use - and I can't find a link to it offhand - is by one Jason Woods. They're all derived from this in the stdlib though: https://github.com/golang/go/blob/master/src/crypto/tls/generate_cert.go /Nick
> On Jun 26, 2020, at 17:55, Nick Thomas <me at ur.gs> wrote: > > Just a heads-up that go has a few of these already, including IP SANs. > The one I usually use - and I can't find a link to it offhand - is by > one Jason Woods. They're all derived from this in the stdlib though: > > https://github.com/golang/go/blob/master/src/crypto/tls/generate_cert.go That Jason Woods (driskell)? https://github.com/driskell/log-courier/blob/master/lc-tlscert/lc-tlscert.go
> That Jason Woods (driskell)? > > https://github.com/driskell/log-courier/blob/master/lc-tlscert/lc-tlscert.go The very same!
> On Jun 26, 2020, at 18:22, Nick Thomas <gemini at ur.gs> wrote: > >> That Jason Woods (driskell)? >> >> https://github.com/driskell/log-courier/blob/master/lc-tlscert/lc-tlscert.go > > The very same! Cool. It''s even documented: https://github.com/driskell/log-courier/blob/master/docs/SSLCertificateUtility.md
On Friday, June 26, 2020 10:30 AM, Jason McBrayer <jmcbray at carcosa.net> wrote: > I would like to do this for my server, but I'm concerned about changing > the certificate when there are people actually using TOFU. Do we have a > best practice note on changing certificates? Solderpunk and I were discussing ideas in the "Thoughts on TOFU" thread. For now, I would suggest just changing it, and clients may complain, but eventually they will switch over. I'd be happy to hear Solderpunk's opinion on this though. makeworld
It was thus said that the Great Case Duckworth once stated: > On Fri, Jun 26, 2020, at 3:05 PM, Felix Quei?ner wrote: > > > > > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)". > > > > > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. > > Using Kristall works and it's blazingly fast, seems to be a correct > > server configuration > > > > Regards > > - xq > > Hm, must be an issue with my network (I'm at work) then -- sorry for clogging up the ML! I'll try again at home tonight. No, I get an error with my own too simple Gemini client: ios:write() = handshake failed: error:06FFF09C:digital envelope routines:CRYPTO_internal:unsupported algorithm It looks to be an issue of the TLS library not supporting the crypto algorithm (in my case, a few months old version of LibreSSL). -spc
That might be my problem as well -- looks like I'm a few dot-versions behind. Which I must admit is a little concerning if this becomes the de facto cert crypto method -- even worse than the TLS 1.2/1.3 divide. ~ acdw On Fri, Jun 26, 2020, at 6:50 PM, Sean Conner wrote: > It was thus said that the Great Case Duckworth once stated: > > On Fri, Jun 26, 2020, at 3:05 PM, Felix Quei?ner wrote: > > > > > > > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` tool, or actually any gemini browser, including AV-98: the error there is "ERROR: [SSL: UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS] unable to find public key parameters (_ssl.c:1108)". > > > > > > > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. > > > Using Kristall works and it's blazingly fast, seems to be a correct > > > server configuration > > > > > > Regards > > > - xq > > > > Hm, must be an issue with my network (I'm at work) then -- sorry for clogging up the ML! I'll try again at home tonight. > > No, I get an error with my own too simple Gemini client: > > ios:write() = handshake failed: error:06FFF09C:digital envelope > routines:CRYPTO_internal:unsupported algorithm > > It looks to be an issue of the TLS library not supporting the crypto > algorithm (in my case, a few months old version of LibreSSL). > > -spc > >
In all fairness, i don't think Many people are using ed25519. Maybe solderpunk has some stats on that :) Anyways, if i'm the only one creating problems, i could change back to a std rsa cert. /Jens. ??????? Original Message ??????? On Friday, June 26, 2020 9:29 PM, Case Duckworth <acdw at acdw.net> wrote: > That might be my problem as well -- looks like I'm a few dot-versions behind. Which I must admit is a little concerning if this becomes the de facto cert crypto method -- even worse than the TLS 1.2/1.3 divide. > > ~ acdw >
On Fri, Jun 26, 2020 at 04:55:05PM +0100, Nick Thomas wrote: > Just a heads-up that go has a few of these already, including IP SANs. > The one I usually use - and I can't find a link to it offhand - is by > one Jason Woods. They're all derived from this in the stdlib though: > > https://github.com/golang/go/blob/master/src/crypto/tls/generate_cert.go > Thanks a lot for this heads up! Cheers, Solderpunk
It was thus said that the Great solderpunk once stated: > There are several contributing factors to TLS overhead. I think some of the overhead concern is overblown. As I said to defdefred, people are forgetting that TCP *itself* has overhead. More on that below. > Some of it is > network based, to do with actually downloading the certificate, and > doing the handshake. Some of it is computation based, to do with the > key exchange calculations. Which is the more important bottleneck will > differe between applications. In cases where network overhead is more > important, getting down the size of the certificate may help. > > My AV-98 TOFU database has 103 certificates stored in it. The mean size > is 1247 bytes - about as large, IIRC, as the average text/gemini > document. 95% of certificates range in size between 704 bytes and 1634 > bytes. How are they stored? If they look like this: -----BEGIN CERTIFICATE----- MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0 ... then your figures are a bit high---the certificate is *not* transmitted as base-64 encoded data, so unless you took that into account, your figures are on the high side. And as I'm wont to do, I did a deep dive into this. I made a request to <gemini://gemini.conman.org/> to obtain the 2,633 byte file, and I captured it with wireshark. Here is the packet-by-packet replay of that exchange. size direction 1 60 -> SYN packet to server (no data) 2 60 <- SYN + ACK from server (still no data) 3 52 -> ACK from client (still no data) 4 203 -> initial client TLS request 5 52 <- ACK from server (no data) 6 1492 <- server certificate 7 52 -> ACK from client (no data) 8 611 <- TLS? unsure from this point on 9 52 -> ACK from client (no data) 10 144 -> data 11 52 <- ACK from server (no data) 12 95 <- data 13 102 -> data 14 1492 <- data (I'm assuming by now this is the file) 15 1282 <- data (probably more file) 16 52 -> ACK from client (no data) 17 75 <- getting ready to close? 18 75 -> getting ready to cloes? 19 52 -> FIN + ACK from client (no data) 20 46 <- FIN from server (no data) One implementation quirk GLV-1.12556 has is that before it serves up any data, it ensures that the complete TLS handshake has finished---I do that to ensure the client certificate (if any) is available but I could probably try moving that out of the "happy no-certificate path". Anyway ... Half the packets involved are simply TCP overhead, no data of any type is sent. The first three packets are larger than the minimum 40 bytes due to TCP options being sent, and the largst packet size availble is 1492, due to limititaions on Ethernet. And just for completeness, here's a gopher request to a file of similar size (<gopher://gopher.conman.org/>, 2,413 bytes): size direction 1 60 -> SYN packet to server (no data) 2 60 <- SYN + ACK from server (no data) 3 52 -> ACK from client (no data) 4 54 -> request to server 5 52 <- ACK from server (no data) 6 1492 <- data from server 7 52 -> ACK from client (no data) 8 1039 <- data from server 9 52 -> ACI from client (no data) 10 52 <- FIN from server (no data) 11 52 -> FIN from client (no data) 12 52 <- ACK from server (no data) Here, 75% of the packets are pure TCP overhead, but it is 60% of the packets of the TLS request. I'm leaving it as an exercise for the reader to compare the actual byte counts between the two requests. And as far as removing the TCP overhead, good luck with *that!* I'd love to see the solution ... -spc
On Fri, Jun 26, 2020 at 06:18:11PM -0400, Sean Conner wrote: > It was thus said that the Great solderpunk once stated: > > There are several contributing factors to TLS overhead. > > I think some of the overhead concern is overblown. Oh, I completely agree. It seems to bother a lot of people so I've been pointing out comparatively quick and easy things we could do without changing the spec at all to address it, because I'd much rather do that than increase complexity or reduce security. But my personal experience using AV-98 is that browsing Geminispace feels plenty snappy enough as is. Especially relative to how long the content takes to consume. > How are they stored? If they look like this: > > -----BEGIN CERTIFICATE----- > MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT > MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG > A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0 > ... > > then your figures are a bit high They're DER encoded binary files, so no worries about that. > size direction > 1 60 -> SYN packet to server (no data) > 2 60 <- SYN + ACK from server (still no data) > 3 52 -> ACK from client (still no data) > 4 203 -> initial client TLS request > 5 52 <- ACK from server (no data) > 6 1492 <- server certificate > 7 52 -> ACK from client (no data) > 8 611 <- TLS? unsure from this point on > 9 52 -> ACK from client (no data) > 10 144 -> data > 11 52 <- ACK from server (no data) > 12 95 <- data > 13 102 -> data > 14 1492 <- data (I'm assuming by now this is the file) > 15 1282 <- data (probably more file) > 16 52 -> ACK from client (no data) > 17 75 <- getting ready to close? > 18 75 -> getting ready to cloes? > 19 52 -> FIN + ACK from client (no data) > 20 46 <- FIN from server (no data) Thanks for this, very enlightening! Cheers, Solderpunk
On Fri, Jun 26, 2020 at 03:03:47PM +0000, Case Duckworth wrote: Hi! > Unfortunately, I can't access cozylabs.eu using the `openssl s_client` FWIW i was able to access this address with my client (i am using cl+ssl for TLS). Bye! C.
----- Forwarded message from solderpunk <solderpunk at SDF.ORG> ----- Date: Fri, 26 Jun 2020 15:57:59 +0000 From: solderpunk <solderpunk@SDF.ORG> To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> Subject: Re: TLS certificate sizes in Geminispace On Fri, Jun 26, 2020 at 05:05:22PM +0200, Felix Quei?ner wrote: > > This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. > Using Kristall works and it's blazingly fast, seems to be a correct > server configuration > Hmm, I think SDF's mail server must be having issues, I'm not seeing other posts to this thread, even my own replies, but I can see them at Sloum's Gemini mirror of the list. I'll send this now in the hopes it gets through eventually... I think perhaps it is, indeed, the case that older versions of OpenSSL will choke on this. That *sucks*. I know this is a big problem with the web, but the web, by virtue of being mostly a commercial enterprise, needs to support janky old clients because the people using them still have good money. I figured that since there *are* no janky old Gemini clients, we would not be bitten by this kind of thing. Okay, perhaps everybody jumping to ED22519 right now is not viable, but it should be a medium-term goal and, in the mean time, we can figure out what the smallest possible widely supported certificate is (without doing silly things like using tiny key sizes), and build tools / write docs help folks generate them. Cheers, Solderpunk
----- Forwarded message from solderpunk <solderpunk at SDF.ORG> ----- Date: Fri, 26 Jun 2020 16:44:41 +0000 From: solderpunk <solderpunk@SDF.ORG> To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> Subject: Re: TLS certificate sizes in Geminispace On Fri, Jun 26, 2020 at 05:05:22PM +0200, Felix Quei?ner wrote: > Using Kristall works and it's blazingly fast, seems to be a correct > server configuration Initially, I could not access cozylabs.eu using Bombadillo. Then I upgraded my Golang version from 1.11 to 1.14 and rebuilt Bomadillo, and now it works just fine. I have not tested it yet, but I presume that exactly the same would be true of Amfora. I tried this after realising that the crypto/ed25519 package only appeared in the Go standard library with the 1.13 release (September last year). I run Debian stable, famous for lagging behind the latest release of everthing. In this case, Debian stable was far enough behind on Go that it meant Go-based clients wouldn't work with ED25519. After the *next* Debian stable release, I imagine this will not be an issue. Already with the current stable release, Python-based clients using Python's OpenSSL binding work with ED25519 just fine. My tiny little ~100 line Lua client also works just fine, although to be fair I may have pulled in some Lua libraries from LuaRocks which are more up to date than what Debian ships with. Anyway, it seems to me that we're perhaps a year or so away from a situation where even famously slow moving and outdated distributions can handle these certs out-of-the-box with a majority of clients , so let's look forward to that faster future. In the meantime, folks who like to "live on the edge" can change earlier I will probably, contrary to my earlier claim, be a bit more conservative with gemini.circumlunar.space, because that really ought to be very widely acccessible. Also in the meantime, I encourage all authors of Gemini-related software written in Go who distribute pre-compiled binaries to compile their binaries with the latest version of Go they can. Cheers, Solderpunk
G'day! I've put an ed25519 based cert on gemini://gem.pwarren.id.au/ which is being served out by the latest gemserv. I generated it on debian with openssl 1.1.1d via: $ openssl genpkey -algorithm ED25519 > gemkey.pem $ openssl req -x509 -key gemkey.pem -subj "/CN=gem.pwarren.id.au" -reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:gem.pwarren.id.au,DNS:gemini.pwarren.id.au,DNS:gemini.lan")) -out gemnew.pem -days 3600 I'm not sure if SANs are required really for gemini, I think with the TOFU idea it's only the hash that matters? The new cert is 489 bytes vs the 1830 for the old RSA keyed certificate (in PEM format), most of my content so far is < 2000 bytes! Cheers -- Paul On 27/6/20 6:58 pm, solderpunk wrote: > ----- Forwarded message from solderpunk <solderpunk at SDF.ORG> ----- > > Date: Fri, 26 Jun 2020 15:57:59 +0000 > From: solderpunk <solderpunk at SDF.ORG> > To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> > Subject: Re: TLS certificate sizes in Geminispace > > On Fri, Jun 26, 2020 at 05:05:22PM +0200, Felix Quei?ner wrote: >>> This makes me think it's an error with the server, as opposed to the ED22519 key; I'd love to try another server with this type of certificate for testing. >> Using Kristall works and it's blazingly fast, seems to be a correct >> server configuration >> > > Hmm, I think SDF's mail server must be having issues, I'm not seeing > other posts to this thread, even my own replies, but I can see them at > Sloum's Gemini mirror of the list. I'll send this now in the hopes it > gets through eventually... > > I think perhaps it is, indeed, the case that older versions of OpenSSL > will choke on this. That *sucks*. I know this is a big problem with > the web, but the web, by virtue of being mostly a commercial enterprise, > needs to support janky old clients because the people using them still > have good money. I figured that since there *are* no janky old Gemini > clients, we would not be bitten by this kind of thing. > > Okay, perhaps everybody jumping to ED22519 right now is not viable, but > it should be a medium-term goal and, in the mean time, we can figure out > what the smallest possible widely supported certificate is (without > doing silly things like using tiny key sizes), and build tools / write > docs help folks generate them. > > Cheers, > Solderpunk > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1003 bytes Desc: OpenPGP digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/d958 682b/attachment-0001.sig>
On 27/6/20 8:37 pm, Paul Warren wrote: > G'day! > > I've put an ed25519 based cert on gemini://gem.pwarren.id.au/ which is > being served out by the latest gemserv. > > I generated it on debian with openssl 1.1.1d via: > > $ openssl genpkey -algorithm ED25519 > gemkey.pem > > $ openssl req -x509 -key gemkey.pem -subj "/CN=gem.pwarren.id.au" > -reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf > "[SAN]\nsubjectAltName=DNS:gem.pwarren.id.au,DNS:gemini.pwarren.id.au,DNS:gemini.lan")) > -out gemnew.pem -days 3600 > > I'm not sure if SANs are required really for gemini, I think with the > TOFU idea it's only the hash that matters? > > The new cert is 489 bytes vs the 1830 for the old RSA keyed certificate > (in PEM format), most of my content so far is < 2000 bytes! > > Cheers > -- > Paul Uh, oh, in all this mucking about with certs, I overwrote my Astrobotany key, which I'd not got round to backing up yet :( Not sure what'll happen to my legendary hissing mature pachypodium now! (Apologies for the previous top post! -- Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1003 bytes Desc: OpenPGP digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/e30c d6e7/attachment.sig>
I, personally, feel that TLS is an incontrovertible part of the appeal of Gemini to me (I've been using Gopher for my own personal things that I want to serve _without_ TLS), but I think there should be guidance on selecting TLS parameters. I've run some load tests and generated some pretty graphs for different generated keys and using them with both Jetforce and Molly Brown, and there is certainly low hanging fruit to work on. If folks are interested, I can collect some of my tests, data, and Python analysis and I can put them up in a digestible post. - meff On 6/26/20 3:37 PM, solderpunk wrote: > On Fri, Jun 26, 2020 at 06:18:11PM -0400, Sean Conner wrote: >> It was thus said that the Great solderpunk once stated: >>> There are several contributing factors to TLS overhead. >> I think some of the overhead concern is overblown. > Oh, I completely agree. It seems to bother a lot of people so I've been > pointing out comparatively quick and easy things we could do without > changing the spec at all to address it, because I'd much rather do that > than increase complexity or reduce security. But my personal experience > using AV-98 is that browsing Geminispace feels plenty snappy enough as is. > Especially relative to how long the content takes to consume. > >> How are they stored? If they look like this: >> >> -----BEGIN CERTIFICATE----- >> MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT >> MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG >> A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0 >> ... >> >> then your figures are a bit high > They're DER encoded binary files, so no worries about that. > >> size direction >> 1 60 -> SYN packet to server (no data) >> 2 60 <- SYN + ACK from server (still no data) >> 3 52 -> ACK from client (still no data) >> 4 203 -> initial client TLS request >> 5 52 <- ACK from server (no data) >> 6 1492 <- server certificate >> 7 52 -> ACK from client (no data) >> 8 611 <- TLS? unsure from this point on >> 9 52 -> ACK from client (no data) >> 10 144 -> data >> 11 52 <- ACK from server (no data) >> 12 95 <- data >> 13 102 -> data >> 14 1492 <- data (I'm assuming by now this is the file) >> 15 1282 <- data (probably more file) >> 16 52 -> ACK from client (no data) >> 17 75 <- getting ready to close? >> 18 75 -> getting ready to cloes? >> 19 52 -> FIN + ACK from client (no data) >> 20 46 <- FIN from server (no data) > Thanks for this, very enlightening! > > Cheers, > Solderpunk
> On Jun 26, 2020, at 15:56, solderpunk <solderpunk at SDF.ORG> wrote: > > cozylabs.eu achieves this feat with a single self-signed ED25519 > certificate. What is the consensus on those self-signed ED25519 certificates? Good? Bad? Ugly? $ echo | openssl s_client -connect cozylabs.eu:1965 2>/dev/null | openssl x509 -outform der | wc -c 273 So, 273 bytes in DER format. $ openssl s_client -quiet -crlf -connect cozylabs.eu:1965 <<< gemini://cozylabs.eu/ 2>/dev/null | wc -c 340 For 340 bytes of text/gemini content. Fair enough. (Ignoring all of the TCP overhead itself, as pointed out by Sean [1]). > Unfortunately making this kind of cert with the `openssl` tool is not as straightforward as other options. $ openssl version OpenSSL 1.1.1g 21 Apr 2020 $ openssl req -new -newkey ed25519 -nodes -keyout key.pem -x509 -days 36500 -subj / -outform der | wc -c 282 282 bytes versus 273 bytes for cozylabs.eu <http://cozylabs.eu/>. Doesn't seem to be that bad. Perhaps I missed something :) [1] gemini://gemi.dev/gemini-mailing-list/messages/001958.gmi <gemini://gemi.dev/gemini-mailing-list/messages/001958.gmi> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/1eb3 e6c0/attachment.htm>
> What is the consensus on those?self-signed ED25519?certificates? Good? Bad? Ugly? I prefer using EC keys, which are still quite small (256 bits), but are more widely supported. The OpenSSL command is a bit annoying, but I made a gemlog post about it to make it easier. gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi The *key* part of it is: -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 Cheers, makeworld
> On Jul 9, 2020, at 18:50, colecmac at protonmail.com wrote: > >> What is the consensus on those self-signed ED25519 certificates? Good? Bad? Ugly? > > I prefer using EC keys, which are still quite small (256 bits), but are more widely > supported. The OpenSSL command is a bit annoying, but I made a gemlog post about it > to make it easier. > > gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi Cool. Thanks for sharing. > The *key* part of it is: > -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 Ok, so: $ openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout key.pem -x509 -days 36500 -subj / -outform der | wc -c 347 347 bytes vs 282 bytes for the ED25519 variant. Not bad at all, size wise. Is it something you are using at makeworld.gq? $ echo | openssl s_client -connect makeworld.gq:1965 2>/dev/null | openssl x509 -outform der | wc -c 1160 At first glance I guess not: Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/32d3 61af/attachment-0001.htm>
> Ok, so: > > $ openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout key.pem -x509 -days 36500 -subj / -outform der | wc -c > 347 > > 347?bytes vs?282 bytes for the?ED25519 variant. Not bad at all, size wise. Yep, pretty equivalent. Thanks for doing the test! > Is it something you are using at?makeworld.gq? > At first glance I guess not I will be, I've generated the new certs already actually. I'm just waiting for my current certs to expire on Aug. 30th. Thanks, makeworld
On Thu Jul 9, 2020 at 6:29 PM CEST, Petite Abeille wrote: > > > > On Jun 26, 2020, at 15:56, solderpunk <solderpunk at SDF.ORG> wrote: > > > > cozylabs.eu achieves this feat with a single self-signed ED25519 > > certificate. > > What is the consensus on those self-signed ED25519 certificates? Good? > Bad? Ugly? My opinion is that they are very nice certs indeed and it would be lovely if we could all use them for everything, but we're probably a few years away from a point where a server admin can be confident that, say, 95% or more of potential visitors will be on systems where this will "just work". In the interim, ECDSA certificates using the NIST curves (yes, the ones everybody is suspicious of) are probably the best possible trade-off between small size and good support. I've finally started work on my little super-simple certificate generator. By default it uses ECDSA with the P256 curve. You can feed it an option to use ED25519 instead. That's it, there is no support for RSA. Cheers, Solderpunk
---
Previous Thread: Real world data on TLS power consumption on mobile devices