Peter Eisentraut wrote:
> Dan Kaminsky wrote:
>>>> 1) No roots (but still works for some unknown reason)
>>>> 2) Explicitly configured corporate roots
>>>> 3) Explicitly configured corporate roots, AND global roots
>>>> 4) Global roots (but still works for some unknown reason)
>
>> So, if you do nothing special, it's #1? Sounds like the path of least
>> resistance is no security. Uh oh.
>
> Yeah, in the average, if not common case, a user interested in SSL use would
> probably just follow the recipe in the documentation for creating and
> installing a self-signed certificate with no certificate checking in the
> client. Which, as you correctly observe, is pretty much completely useless.
>
> Someone should probably redesign, reconfigure, and redocument this.
Agreed.
I'd like to suggest that for the "easy fix" (without supporting custom
callbacks and whatever) we create a new connection parameter called
"sslverifypeer". It can be set to "verifypeer", "verifycert" or "off".
When set to "verifypeer", we will verify the peer name and the
certificate. When "verifycert" we just verify the certificate, fail if
we can't find a root certificate, but ignore the common name. "off"
should be self-explaining.
I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with
a default of "off". That way we don't break existing setups, but give
users the ability to verify if if they want to.
Comments?
//Magnus