On 07/01/16 16:17, Daniel J. Luke wrote:
On Jan 7, 2016, at 5:53 AM, Russell Jones <[email protected]>
wrote:
On Daniel's point: checking an SSL cert provides a guarantee from some
certificate issuer, given a competent sysadmin, etc, that the host name matches
it.
When you validate an SSL certificate all you end up with is the assurance that
some Certificate Authority has issued a certificate for that hostname.
That seems to me to be understating the case.
There are lots of CAs and they aren't immune to process (or other) issues (see
also DigiNotar). There's a reason why there has been interest in public key
pinning (and DANE + DNSSEC) - so you end up with a greater assurance.
Yes, and there was Lavabit, of course. But these are rather unusual
cases. It's fine, important indeed, to exclude them as far as possible
by ensuring oversight, but the problem still exists even with checksums,
realistically.
Do you have some reason to think there are issuers in the root certificate list that
would issue bogus python.org certs? Or are you talking about a cert being stolen? I'm not
sure what you mean by "just .. valid".
I don't have reason to believe either of those things is currently happening -
but I have reason to believe either is possible, and we shouldn't decide to
rely on neither happening.
I agree. I wasn't suggesting we should in general. Rather, it was a
suggestion for mitigation until a better one came along (which it did,
very quickly).
Even in the non-malicious case, a re-org of files on python.org would yield
unknown behavior (the file at that url could change, and in the base case we
would get an error - in the worst case anything could be in that file).
Well no, not *anything* unless python.org to open it to the public,
which seems a little far-fetched.
Russell
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
