SSL by default for all packaged web apps?
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
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.
Technical Account Manager - Canonical Ltd
Ubuntu Certified Instructor - LPIC-3
~= Ubuntu: Linux for Human Beings =~
More information about the ubuntu-server