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 =~ -- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
