basic auth request

[Chris Angelico]

On Thu, Aug 26, 2021 at 12:48 AM Jon Ribbens via Python-list
<python-list at python.org> wrote:
>
> On 2021-08-25, Chris Angelico <rosuav at gmail.com> wrote:
> > On Thu, Aug 26, 2021 at 12:16 AM Jon Ribbens via Python-list
> ><python-list at python.org> wrote:
> >> There are so many trusted CAs these days that the chances of them all
> >> being secure approaches zero - they are not all equal yet they are all
> >> equally trusted. Which is why a change of CA on a site you have visited
> >> before is potentially suspicious.
> >
> > Do any popular web browsers notify you if that happens? I've certainly
> > never noticed it with any that I use (and I've transitioned several
> > sites from one CA to another).
>
> There was, if the site was using "HTTP Public Key Pinning". But
> that appears to have now been removed in favour of "Certificate
> Transparency", which to me seems to be a system very much based
> on the "problem: horse gone; solution: shut stable door" principle.
>
> Another attempt at combatting this problem is DNS CAA records,
> which are a way of politely asking all CAs in the world except the
> ones you choose "please don't issue a certificate for my domain".
> By definition someone who had hacked a CA would pay no attention
> to that request, of course.

True, but that would still prevent legit CAs from unwittingly
contributing to an attack. But it still wouldn't help if someone can
do any sort of large-scale DNS attack, which is kinda essential for
most of this to matter anyway (it doesn't matter if an attacker has a
fake cert if all traffic goes to the legit site anyway).

> > I've come to the conclusion that most security threats don't bother
> > most people, and that security *warnings* bother nearly everyone, so
> > real authentication of servers doesn't really matter all that much.
> > *Encryption* does still have value, but you'd get that with a
> > self-signed cert too.
>
> Encryption without knowing who you're encrypting *to* is worthless,
> it's pretty much functionally equivalent to not encrypting.

Somewhat. It does prevent various forms of MitM attack. It's all about
adding extra difficulties on an attacker, so I wouldn't say
"worthless", just because it isn't 100% reliable.

Earlier I posited a hypothetical approach wherein the server would
sign a new cert using the old cert, and would then be able to present
that upon request. Are there any massive glaring problems with that?
(Actually, I'm pretty sure there will be. Lemme reword. What massive
glaring problems can you see with that?) It would require servers to
retain a chain of certificates, and to be able to provide that upon
request. It wouldn't even need a change to HTTP per se - could be
something like "https://your.host.example/cert_proof.txt" the same way
that robots.txt is done. In theory, that would allow a client to, at
the cost of retaining the one last-seen cert for each site, have
confidence that the site is the same one that was previously seen.

But, maybe we're just coming back to "it doesn't matter and nobody
really cares".

ChrisA