SSL by default for all packaged web apps?

Etienne Goyer etienne.goyer at canonical.com
Wed Mar 2 05:38:23 UTC 2011


Re-reading my email, I think I got a bit too snarky toward the end.
While I think my arguments are sound, the discussion does not have to be
confrontational.  My apologies to Marc and the list for the tone I used
earlier.

On 11-03-01 09:01 PM, Etienne Goyer wrote:
> 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 =~




More information about the ubuntu-server mailing list