SSL by default for all packaged web apps?

[Marc Deslauriers]

On Tue, 2011-03-01 at 21:01 -0500, Etienne Goyer wrote:
> >> 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.

Given that it's a _lot_ easier to MITM a switched network than it is to
eavesdrop on one, I don't think this would be much of an improvement.

> 
> > 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.

This is incredibly wrong and no organisation who's had a security audit
would be able to continue doing so, unless what's being protected is of
no value, including the passwords that are being used.


> >> 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.

There _are_ valid use-cases for self-signed certificates. I don't think
_preventing_ the use of self-signed certs to be the right thing to do.

Using an unregistered domain name for an internal network is bad network
design, and causes a lot of problems, including an SSL cert problem.
Inventing any random TLD seems to have had a splurge in popularity when
Active Directory showed up.

I agree, purchasing a certificate can be more complex than what I
described....but I don't think self-signed certs are any kind of valid
replacement.

> 
> 
> >> 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.

Just because they are doing something terribly insecure already doesn't
mean we should be doing it by default.

Self-signed certs don't improve security over clear text in any
significant way (unless used by technical people who check fingerprints,
etc.)

> 
> 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.

I do think that we need something easier to set up SSL though, and that
may be what we should put effort into. Maybe we should ship ssl
configuration files that are turned off by default, and have a tool that
an admin can run that would list all the apps currently installed that
could use an SSL cert, and then offer to either 1- Generate the CSR
required to purchase a cert, 2- Set up a CA with certs to import into
organization’s cert stores, 3- Use a self-signed cert for testing
purposes.

Marc.