💾 Archived View for gemi.dev › gemini-mailing-list › 000526.gmi captured on 2024-05-26 at 16:07:15. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
The page <gemini://gemini.circumlunar.space/> lists a "Houston search engine", whose certificate expired months ago. Is it supposed to be accepted? Amfora rejects it. % gnutls-cli -p 1965 houston.coder.town ... - subject `EMAIL=k at kvn.dev,CN=houston.coder.town,O=Internet Widgits Pty Ltd,ST=CA,C=US', issuer `EMAIL=k at kvn.dev,CN=houston.coder.town,O=Internet Widgits Pty Ltd,ST=CA,C=US', serial 0x04a4388eea0fd69cb645ac15a6117912cdf35ca9, RSA key 2048 bits, signed using RSA-SHA1 (broken!), activated `2020-05-20 21 21:48:19 UTC', expires `2020-06-19 21:48:19 UTC'
It is indeed expired and should be rejected, as you saw with gnutls and Amfora. Hopefully the sysadmin will update it, maybe you could email them. Looks like the address is k at kvn.dev. makeworld
On Sun, 6 Dec 2020 at 18:25, <colecmac at protonmail.com> wrote: > > It is indeed expired and should be rejected, as you saw with gnutls and > Amfora. I disagree with makeworld on this. The idea of expiration comes from the Certificate Authority scheme of certificate validation. A certificate authority will not lend their trust to someone indefinitely, because that would eventually lead to a horrible mess of billions of rejected certificates. Instead they put a time limit on their certificates to say that "if we haven't vouched for this person/organisation in the last X months, just assume we no longer do". With a self-signed certificate the date is just a setting that the certificate issuer can set arbitrarily, which means a middle-man attacker can too. A valid date range doesn't in any way affect the security of the certificate. The *only* valid question is "Do I trust this?" which is somewhat of a catch 22. This is where TOFU comes in: we assume that the certificate is correct the first time it's presented to us, and subsequent checks are just a matter of "is this the same certificate already presented to me for this host?" Incidentally I wrote a gemlog post on the subject last night (after the original mail in this thread was sent, but before I'd seen it -- my post had been in the brewing for a few days). Tell me if there's anything that can be clarified in that post: gemini://tilde.team/~ew0k/posts/certificate-security.gmi Cheers, ew0k
> With a self-signed certificate the date is just a setting that the > certificate issuer can set arbitrarily Then server owners can set an expiration date in the far future. If they set a close expiration date, then they are expecting it to expire.
On Monday, December 7, 2020 1:48 AM, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > On Sun, 6 Dec 2020 at 18:25, colecmac at protonmail.com wrote: > > > It is indeed expired and should be rejected, as you saw with gnutls and > > Amfora. > > I disagree with makeworld on this. The advantage of having expiry dates is that if the server admin loses the key, or their hardware, or something like that, they know that clients will accept the new cert after a certain period of time, with no issues or scary warnings. Now, I know that this becomes a bit counter-intuitive when certs expire 5 years in the future, but I still think it's a good quality to have. makeworld
---