basic auth request

[Chris Angelico]

On Sun, Aug 22, 2021 at 8:30 PM Barry Scott <barry at barrys-emacs.org> wrote:
>
>
>
> On 22 Aug 2021, at 10:37, Chris Angelico <rosuav at gmail.com> wrote:
>
> When it comes to security, one thing I'm very curious about is why we
> don't have any sort of certificate renewal verification. My browser
> could retain the certificates of some web site (or of all web sites,
> even - they're not THAT large), and if the site presents a different
> cert, it could show the previously retained one and challenge the
> server "prove that you're the same guy". This proof would consist of
> the latest cert, signed by the older cert's key (or possibly a chain
> that can construct such a proof, which would allow the server to
> simply retain each new cert signed by the one previous cert, forming a
> line - or a tree if necessary). My suspicion is that it'd add little
> above simply having a valid cert, but if people are paranoid, surely
> that's a better place to look?
>
>
> The web site proves it owners the hostname and/or IP address using its certificate.
> You use your trust store to show that you can trust that certificate.
>
> The fact that a certificate changes is not a reason to stop trusting a site.
>
> So it does not add anything.
>
> The pain point in PKI is revocation. The gold standard is for a web site to use OCSP stapling.
> But that is rare sadly. And because of issues with revocation lists, (privacy, latency, need to
> fail open on failiure, DoD vector, etc) this is where the paranoid should look.
>

Fair point. Let me give you a bit of context.

Recently, the owner/operator of a site (I'll call it
https://demo.example/ ) died. Other people, who have been using the
site extensively, wish for it to continue. If the domain registration
expires, anyone can reregister it, and can then generate a completely
new certificate for the common name "demo.example", and web browsers
will accept that. The old cert may or may not have expired, but it
won't be revoked.

As far as I can tell, a web browser with default settings will happily
accept the change of ownership. It won't care that the IP address,
certificate, etc, have all changed. It just acknowledges that some CA
has signed some certificate with the right common name. And therein is
the vulnerability. (NOTE: I'm not saying that this is a real and
practical vulnerability - this is theoretical only, and a focus for
the paranoid.)

This is true even if the old cert were one of those enhanced
certificates that some CAs try to upsell you to ("Extended Validation"
and friends). Even if, in the past, your bank was secured by one of
those certs, your browser will still accept a perfectly standard cert
next time. Which, in my opinion, renders those (quite pricey)
certificates no more secure than something from Let's Encrypt that has
no validation beyond ownership of DNS.

Of course, you can pin a certificate. You can ask your browser to warn
you if it's changed *at all*. But since certs expire, that's highly
impractical, hence wondering why we don't have a system for using the
old cert to prove ownership of the new one.

So how is a web browser supposed to distinguish between (a) normal
operation in which certs expire and are replaced, and (b) legit or
non-legit ownership changes? (Of course the browser can't tell you
whether the ownership change is legit, but out-of-band info can help
with that.)

Or does it really matter that little?

ChrisA