On Sun, Oct 14, 2012 at 2:04 AM, Magnus Hagander <magnus@hagander.net> wrote:
> There's a lot of shades of gray to that one. Way too many to say
> they're right *or* wrong, IMHO.
We can agree it is 'sub-ideal', but there is not one doubt in my mind
that it is not 'right' given the scope of Debian's task, which does
*not* include pushing applied cryptography beyond its current pitiful
state.
Debian not making self-signed certs available by default will just
result in a huge amount of plaintext database authentication and
traffic available over the internet, especially when you consider the
sslmode=prefer default, and as a result eliminate protection from the
most common class of attack for users with low-value (or just
low-vigilance) use cases. In aggregate, that is important, because
there are a lot of them.
It would be a net disaster for security.
> It *does* make people think they have "full ssl security by default",
> which they *don't*.They do have partial protection, which helps in
> some (fairly common) scenarios. But if you compare it to the
> requirements that people *do* have when they use SSL, it usually
> *doesn't* protect them the whole way - but they get the illusion that
> it does. Sure, they'd have to read up on the details in order to get
> secure whether it's on by default or not - that's why I think it's
> hard to call it either right or wrong, but it's rather somewhere in
> between.
If there is such blame to go around, I place such blame squarely on
clients. More secure is the JDBC library, which makes you opt into
logging into a server that has no verified identity via configuration.The problem there is that it's a pain to get
signedcerts in, say, a
test environment, so "don't check certs" will make its way into the
default configuration, and now you have all pain and no gain.
--
fdr
