SSL by default for all packaged web apps?

[Etienne Goyer]

On 11-03-01 06:39 PM, Marc Deslauriers wrote:
> On Tue, 2011-03-01 at 18:04 -0500, Etienne Goyer wrote:
>>> We should not turn on SSL by default with self-signed certificates. That
>>> is insecure and is not a configuration that should be encouraged.
>>
>> There is two things there:
>>
>> 1. Encrypting communication between the client and the server (notably
>> to protect the credential exchange from eavesdropping).
>>
>> 2. Preventing MitM by authenticating the server.
>>
>>
>> Using SSL with self-signed certificate doesn't address 2., but it does
>> address 1.  From my perspective, it's an incremental improvement over
>> plain-text HTTP.  So, why not?
> 
> I'm not quite sure under which circumstance 1 would be a problem but 2
> would not. When you're on a trusted network? If you're on a trusted
> network, you probably don't need SSL in the first place.

There's no such thing as a trusted network.  I am just saying that
encrypting traffic is an incremental improvement over plain-text HTTP.

> The problem here is that turning it on by default will instill a false
> sense of security into people's minds. You are telling them that it's
> acceptable to bypass the important warnings and to click the "OK" button
> in Firefox when they connect the first time. You are showing them the
> lock icon in Firefox indicating to them that they're on a secure
> connection, when in fact, that's not the case...

Yet, most internal web service (those that aren't public-facing) require
the end-user to dismiss a self-signed certificate already.  That's what
I see out there.  Turning SSL on by default would not be a regression,
it would be an incremental improvement over plain-text HTTP.


>> I have had that argument with a few people over the years.  Fact is, at
>> least for non publicly facing web services, most people will continue to
>> use self-signed certificates for the simple reason that getting a
>> "valid" certificate (or setting up your own CA) is a huge hassle, and
>> not even always possible.
> 
> They are trading off security to save $50 and 30 minutes of work.
> Unless, of course, you are getting every single user to manually
> validate the fingerprint every time they click that Accept button.

And this is the crux of the matter.  I have had this argument served
recently by obnoxious developers of an application that would not run
without a valid SSL certificate, and it was of no help to me.  On
internal network, organisation of all size often use non-registred
domain name.  You cannot get a valid SSL certification signed by a CA
for a .silly domain, however hard you try.  Plus, it's often much more
involved that 50$ and 30 minutes.  Sometime, it requires you seek
approval from procurement, IT security or net ops department to buy a
certificate in the name of your org.


>> I would even go as far as arguing that trying to discourage people from
>> using self-signed certificate through systemic measure is a waste of
>> time, because most people just do not understand the implication.
>> Putting the cart before the horses and stuff.
> 
> Setting up an insecure SSL connection by default, and giving them the
> impression of being encrypted properly is security theatre. This isn't
> something we should be recommending, or doing by default. If someone
> decides that self-signed certificates are "good enough" for them, they
> should set it up themselves and face the consequences.

And that is what most people are currently doing, in fact.  They would
be none the worst if we enabled SSL by default.

But, in the end, I do not care much and I am not going to argue any more
in favor of the proposal.  It's just an incremental usability
improvement, like ssh-installed-by-default would have been.  We could
nitpick all night long about the fine point of security vs usability,
but it's not very productive.


-- 
Etienne Goyer
Technical Account Manager - Canonical Ltd
Ubuntu Certified Instructor   -    LPIC-3

 ~= Ubuntu: Linux for Human Beings =~