💾 Archived View for gemi.dev › gemini-mailing-list › 000821.gmi captured on 2023-11-04 at 13:08:01. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Gemini Discovery is now up and running. In a nutshell, it's a directory of search engines and directories. It's available at: gemini://discovery.geminiprotocol.com/ It mostly serves two audiences:
Nathan Galt <mailinglists at ngalt.com> writes: > Gemini Discovery is now up and running. In a nutshell, it's a directory of search engines and directories. It's available at: > > gemini://discovery.geminiprotocol.com/ > > It mostly serves two audiences: > > * people who want to find new/updated things on Gemini > * people who want other people to be able to find their (new) capsules > > If you'd like a page that links to most of the gemini-discovery services out there, check it out. I'm not able to load the page on any clients (porcelain, lagrange, tinmop & my secret little project) on OpenBSD. All of them complains about a failure during the handshake :/
On Tue, Mar 16, 2021 at 11:07:35AM +0100, Omar Polo <op at omarpolo.com> wrote a message of 17 lines which said: > I'm not able to load the page on any clients (porcelain, lagrange, > tinmop & my secret little project) on OpenBSD. All of them complains > about a failure during the handshake :/ No problem with Lagrange or Amfora here. gnutls-cli shows no TLS issue: % gnutls-cli --insecure -p 1965 discovery.geminiprotocol.com Processed 0 CA certificate(s). Resolving 'discovery.geminiprotocol.com:1965'... Connecting to '95.217.134.139:1965'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `EMAIL=admin at geminiprotocol.com,CN=discovery.geminiprotocol.com,C=se', issuer `EMAIL=admin at geminiprotocol.com,CN=discovery.geminiprotocol.com,C=se', serial 0x4c149bab68907b80691f37bbfae5c30ef6a6ae6d, EdDSA (Ed25519) key 256 bits, signed using EdDSA-Ed25519, activated `2021-03-14 18:03:31 UTC', expires `2040-12-31 18:03:31 UTC', pin-sha256="wPXjqjkOcGyL4cY7RGy4ctMLDZfxfTXxgHkKQY9A+bc=" Public Key ID: sha1:a105e4d487cbef2db156c4cb5413e27382b2b1fd sha256:c0f5e3aa390e706c8be1c63b446cb872d30b0d97f17d35f180790a418f40f9b7 Public Key PIN: pin-sha256:wPXjqjkOcGyL4cY7RGy4ctMLDZfxfTXxgHkKQY9A+bc= - Status: The certificate is NOT trusted. The certificate issuer is unknown.
Omar Polo <op at omarpolo.com> wrote: Nathan Galt <mailinglists at ngalt.com> writes: > Gemini Discovery is now up and running. In a nutshell, it's a directory of search engines and directories. It's available at: > > gemini://discovery.geminiprotocol.com/ > I'm not able to load the page on any clients (porcelain, lagrange, > tinmop & my secret little project) on OpenBSD. All of them complains > about a failure during the handshake :/ I'm doing the hosting and will respond to you off list for troubleshooting. -- Katarina
Stephane Bortzmeyer <stephane at sources.org> writes: > On Tue, Mar 16, 2021 at 11:07:35AM +0100, > Omar Polo <op at omarpolo.com> wrote > a message of 17 lines which said: > >> I'm not able to load the page on any clients (porcelain, lagrange, >> tinmop & my secret little project) on OpenBSD. All of them complains >> about a failure during the handshake :/ > > No problem with Lagrange or Amfora here. gnutls-cli shows no TLS > issue: > > % gnutls-cli --insecure -p 1965 discovery.geminiprotocol.com > Processed 0 CA certificate(s). > Resolving 'discovery.geminiprotocol.com:1965'... > Connecting to '95.217.134.139:1965'... > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > - Certificate[0] info: > - subject `EMAIL=admin at geminiprotocol.com,CN=discovery.geminiprotocol.com,C=se', issuer `EMAIL=admin at geminiprotocol.com,CN=discovery.geminiprotocol.com,C=se', serial 0x4c149bab68907b80691f37bbfae5c30ef6a6ae6d, EdDSA (Ed25519) key 256 bits, signed using EdDSA-Ed25519, activated `2021-03-14 18:03:31 UTC', expires `2040-12-31 18:03:31 UTC', pin-sha256="wPXjqjkOcGyL4cY7RGy4ctMLDZfxfTXxgHkKQY9A+bc=" not a tls experts, but I think my issues are caused by the ed25519 key. I recall reading something that libressl don't support those keys yet (please correct me if I'm wrong) ; nc -c -Tnoverify discovery.geminiprotocol.com 1965 nc: tls handshake failed (handshake failed: error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure) > Public Key ID: > sha1:a105e4d487cbef2db156c4cb5413e27382b2b1fd > sha256:c0f5e3aa390e706c8be1c63b446cb872d30b0d97f17d35f180790a418f40f9b7 > Public Key PIN: > pin-sha256:wPXjqjkOcGyL4cY7RGy4ctMLDZfxfTXxgHkKQY9A+bc= > > - Status: The certificate is NOT trusted. The certificate issuer is unknown. > *** PKI verification of server certificate failed... > - Successfully sent 0 certificate(s) to server. > - Description: (TLS1.2-X.509)-(ECDHE-X25519)-(EdDSA-Ed25519)-(AES-256-GCM) > - Session ID: F8:63:9A:89:C8:0B:8A:C7:58:15:8F:74:23:00:95:A5:67:D8:F8:FE:5F:40:FD:4F:8A: 4B:AE:31:44:31:23:D6 > - Options: extended master secret, safe renegotiation, > - Handshake was completed
On Tue, Mar 16, 2021 at 11:30:14AM +0100,
Omar Polo <op at omarpolo.com> wrote
a message of 44 lines which said:
> not a tls experts, but I think my issues are caused by the ed25519 key.
> I recall reading something that libressl don't support those keys yet
If so, this is certainly a serious problem with LibreSSL. RFC 8410,
which added these keys in certificates, is already 2.5 years old.
According to Lupa
<gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi>, 8 capsules
use this type of key. Can you connect to them:
name | lastsuccessfulconnect | certalgorithm
-----------------------+----------------------------+---------------
lord.re | 2021-03-16 07:45:22.190857 | ED25519
tdem.in | 2021-03-14 19:06:25.216331 | ED25519
erion.cf | 2021-03-13 09:00:36.070426 | ED25519
fern91.com | 2021-03-13 07:28:30.499848 | ED25519
gemini.eletrotupi.com | 2021-03-13 05:55:16.892495 | ED25519
earnestma.xyz | 2021-03-10 14:27:00.991546 | ED25519
antonmcclure.com | 2021-03-09 19:22:56.702628 | ED25519
cfdocs.wetterberg.nu | 2021-03-06 09:38:35.085335 | ED25519
---
Previous Thread: SDF has set up Gemini service for its MetaARPA users