Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 01:14:52 JST Rich Felker

   • Hachyderm

   Uh, do @hachyderm staff know there's been an expired certificate for at least an hour or so now? https://status.hachyderm.io shows no problem and at least some other folks don't seem to have noticed anything so I'm guessing it's a problem only with certain nodes.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 01:18:26 JST Rich Felker

     in reply to

     Related: I want to call out Firefox mobile for atrociously bad security UX around bad certs. The cert error message reads: "Fennec does not trust https : // hachyderm.io / because its certificate issuer is unknown, the certificate is self-signed, or the server is not sending the correct intermediate certificates."

     This muddling of multiple error conditions, which becomes an outright LIE when the actual error is the main one that appears in the real world (expiration or wrong clock), makes it impossible to act on and fuels wrongful fears that a site has been compromised.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 01:19:40 JST Rich Felker

     in reply to

     In this case it wasn't going to let me act on the information anyway (and provided an even worse message I didn't save) due to HSTS, but deleting the HSTS store to get the real error produced the above, with an option to override, but no way to get the information necessary to evaluate whether an override is safe.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 01:25:12 JST Rich Felker

     in reply to

     On another level, while standard TLS handling of expiry is reasonable in a standalone connection context, it's bullshit to begin with in a web context.

     There is no reasonable sense in which a certificate that I trusted 5s ago is suddenly untrusted because 5s passed.

     Browser UX should be something like continuing to trust an expired cert for up to 3-4 days (whatever expected reasonable turnaround time for an admin to act is) as long as:

     - The certificate is identical to the one you last trusted it as (in particular, this ensures no rollback).
     - You accessed the site within a few days prior to expiry (this ensures compromised certs can't be used against infrequent visitors long after compromise).

     Along with a clear UI element explaining that the site has failed to renew its certificate in time but that this does not indicate a compromise, and that it will stop working at [date and time] unless they resolve this.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 01:25:39 JST Rich Felker

     in reply to

     Also, disallowing HSTS override without rm'ing files in the profile directory is a shit anti-user behavior by browsers.

   • Embed this notice
     John Breen (jab01701mid@mastodon.social)'s status on Tuesday, 02-Sep-2025 02:03:28 JST John Breen

     in reply to

     @dalias Amen. Your post reminded me of this from a Brave browser a few days ago, operated by a human, with a correct clock...
     What in hell is anyone supposed to do with that error description...

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 02:05:24 JST Rich Felker

     in reply to

     • Falcon Darkstar

     @falcon You want certs to be much more short-lived than domain registration so that you don't have to rely on revocation. And there's no way evaluate registration lifetime anyway except "registrar says so in the whois text" which isn't really suited for cryptographic trust use. Just sticking to short lifetimes ensures certs will have very short validity past transfer of ownership tho, which is probably fine since nobody launches an important service right after domain transfer.

   • Embed this notice
     Falcon Darkstar (falcon@mastodon.falconk.rocks)'s status on Tuesday, 02-Sep-2025 02:05:25 JST Falcon Darkstar

     in reply to

     @dalias alternatively: the certificate should expire when the domain registration expires, at least if it contains a name for a second level domain, and should be revoked if domain ownership changes. Or we should use DANE.

   • Embed this notice
     Arne Visscher (zomgwtfbbqkewl@hachyderm.io)'s status on Tuesday, 02-Sep-2025 02:17:15 JST Arne Visscher

     in reply to

     • Hachyderm

     @dalias @hachyderm seems fine on my end (EU)

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 02:41:50 JST Rich Felker

     in reply to

     • Arne Visscher
     • Hachyderm

     @zomgwtfbbqkewl @hachyderm It's gotta be specific to particular endpoints. But it's happening both from a datacenter exit on IPv6 and from local ISP that's v4-only resolving the hostname to 162.216.18.106. Both US.

   • Embed this notice
     Arne Visscher (zomgwtfbbqkewl@hachyderm.io)'s status on Tuesday, 02-Sep-2025 06:04:04 JST Arne Visscher

     in reply to

     • Hachyderm

     @dalias @hachyderm I figured it'd be regional yeah. Hope someone gets on this quickly.

   • Embed this notice
     Hachyderm (hachyderm@hachyderm.io)'s status on Tuesday, 02-Sep-2025 06:53:16 JST Hachyderm

     in reply to

     • Arne Visscher

     @dalias

     Hello! We took a look and while the certs were rotated, they should be ok now. Can you let us know if this is still an issue?

     If it is, would you mind either emailing us or using Github Issues so we can go back and forth with you more easily with what we'll need to debug.

     Thank you!

     CC

     @zomgwtfbbqkewl

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 02-Sep-2025 09:09:12 JST Rich Felker

     in reply to

     • Arne Visscher
     • Hachyderm

     @hachyderm @zomgwtfbbqkewl Thanks. I emailed admin@ earlier too and just got a response that it should be fixed now. Verified that it is.

   • Embed this notice
     Hachyderm (hachyderm@hachyderm.io)'s status on Tuesday, 02-Sep-2025 17:19:36 JST Hachyderm

     in reply to

     • Arne Visscher

     @dalias

     Confirming :BlobhajSmile:

     Thank you for sending the additional debugging data, it helped us locate the cause.

     CC

     @zomgwtfbbqkewl

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 03-Sep-2025 01:25:19 JST Rich Felker

     in reply to

     • Falcon Darkstar

     @falcon I'm just saying there's no protocol level way to know domain registration period or transfer of ownership. On top of that, I tend to view the fact that transfer of ownership is possible as a bug. It breaks trust of people using the domain name and, even ignoring certificate issues, can cause a user's browser to disclose secrets to a new party they don't trust. I deem the new owner more of a threat than the old owner still having an unexpired certificate.

   • Embed this notice
     Falcon Darkstar (falcon@mastodon.falconk.rocks)'s status on Wednesday, 03-Sep-2025 01:25:20 JST Falcon Darkstar

     in reply to

     @dalias I am not sure I agree. There may be some legitimate interest in a shorter time to reduce CRL size, but also certificates should in most cases be revoked if a domain is transferred to an unrelated party. The status quo is even worse, forcing people to age domains and make guesses.

     Also, what the registrar says is the literal source of record for domain ownership.

     But with DANE, this would all happen automatically and certificate expiration would just not be a thing.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 03-Sep-2025 07:47:29 JST Rich Felker

     in reply to

     • Falcon Darkstar

     @falcon EV was attempting to verify entirely the wrong thing, which is why it was so hated and eventually made irrelevant.

   • Embed this notice
     Falcon Darkstar (falcon@mastodon.falconk.rocks)'s status on Wednesday, 03-Sep-2025 07:47:30 JST Falcon Darkstar

     in reply to

     @dalias the problem space goes deep. While we are talking radical ideas, it makes little sense that your anchor for e.g. TD.com being your bank is the fact that they pay a nominal sum to CSC Global and Verisign therefore maintains that the site points to them. One wants a stronger anchor that could prove it's your bank regardless of DNS, but the UI and frankly the social infrastructure to tie that up failed in EV certificates and remains unexplored otherwise.