+1 for SSL of packages.<br><br>A compromise would just be to run the entire mirror both http & https with a self signed cert and leave the default http. <br><br>The packages that are coming from the ubuntu mirror are very important especially since so many companies use ubuntu in production environments. <br>
<br>As for the whole self signed vs. signed by a company I don't really care and I don't think many do either. People that modify the packages to use SSL will know why and what they are doing. Those who don't will just default to http.<br>
<br>~Dan<br><br><div class="gmail_quote">On Tue, Mar 1, 2011 at 8:01 PM, Etienne Goyer <span dir="ltr"><<a href="mailto:etienne.goyer@canonical.com">etienne.goyer@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 11-03-01 06:39 PM, Marc Deslauriers wrote:<br>
> On Tue, 2011-03-01 at 18:04 -0500, Etienne Goyer wrote:<br>
>>> We should not turn on SSL by default with self-signed certificates. That<br>
>>> is insecure and is not a configuration that should be encouraged.<br>
>><br>
>> There is two things there:<br>
>><br>
>> 1. Encrypting communication between the client and the server (notably<br>
>> to protect the credential exchange from eavesdropping).<br>
>><br>
>> 2. Preventing MitM by authenticating the server.<br>
>><br>
>><br>
>> Using SSL with self-signed certificate doesn't address 2., but it does<br>
>> address 1. From my perspective, it's an incremental improvement over<br>
>> plain-text HTTP. So, why not?<br>
><br>
> I'm not quite sure under which circumstance 1 would be a problem but 2<br>
> would not. When you're on a trusted network? If you're on a trusted<br>
> network, you probably don't need SSL in the first place.<br>
<br>
</div>There's no such thing as a trusted network. I am just saying that<br>
encrypting traffic is an incremental improvement over plain-text HTTP.<br>
<div class="im"><br>
> The problem here is that turning it on by default will instill a false<br>
> sense of security into people's minds. You are telling them that it's<br>
> acceptable to bypass the important warnings and to click the "OK" button<br>
> in Firefox when they connect the first time. You are showing them the<br>
> lock icon in Firefox indicating to them that they're on a secure<br>
> connection, when in fact, that's not the case...<br>
<br>
</div>Yet, most internal web service (those that aren't public-facing) require<br>
the end-user to dismiss a self-signed certificate already. That's what<br>
I see out there. Turning SSL on by default would not be a regression,<br>
it would be an incremental improvement over plain-text HTTP.<br>
<div class="im"><br>
<br>
>> I have had that argument with a few people over the years. Fact is, at<br>
>> least for non publicly facing web services, most people will continue to<br>
>> use self-signed certificates for the simple reason that getting a<br>
>> "valid" certificate (or setting up your own CA) is a huge hassle, and<br>
>> not even always possible.<br>
><br>
> They are trading off security to save $50 and 30 minutes of work.<br>
> Unless, of course, you are getting every single user to manually<br>
> validate the fingerprint every time they click that Accept button.<br>
<br>
</div>And this is the crux of the matter. I have had this argument served<br>
recently by obnoxious developers of an application that would not run<br>
without a valid SSL certificate, and it was of no help to me. On<br>
internal network, organisation of all size often use non-registred<br>
domain name. You cannot get a valid SSL certification signed by a CA<br>
for a .silly domain, however hard you try. Plus, it's often much more<br>
involved that 50$ and 30 minutes. Sometime, it requires you seek<br>
approval from procurement, IT security or net ops department to buy a<br>
certificate in the name of your org.<br>
<div class="im"><br>
<br>
>> I would even go as far as arguing that trying to discourage people from<br>
>> using self-signed certificate through systemic measure is a waste of<br>
>> time, because most people just do not understand the implication.<br>
>> Putting the cart before the horses and stuff.<br>
><br>
> Setting up an insecure SSL connection by default, and giving them the<br>
> impression of being encrypted properly is security theatre. This isn't<br>
> something we should be recommending, or doing by default. If someone<br>
> decides that self-signed certificates are "good enough" for them, they<br>
> should set it up themselves and face the consequences.<br>
<br>
</div>And that is what most people are currently doing, in fact. They would<br>
be none the worst if we enabled SSL by default.<br>
<br>
But, in the end, I do not care much and I am not going to argue any more<br>
in favor of the proposal. It's just an incremental usability<br>
improvement, like ssh-installed-by-default would have been. We could<br>
nitpick all night long about the fine point of security vs usability,<br>
but it's not very productive.<br>
<div class="im"><br>
<br>
--<br>
Etienne Goyer<br>
Technical Account Manager - Canonical Ltd<br>
Ubuntu Certified Instructor - LPIC-3<br>
<br>
~= Ubuntu: Linux for Human Beings =~<br>
<br>
--<br>
</div><div><div></div><div class="h5">ubuntu-server mailing list<br>
<a href="mailto:ubuntu-server@lists.ubuntu.com">ubuntu-server@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-server" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-server</a><br>
More info: <a href="https://wiki.ubuntu.com/ServerTeam" target="_blank">https://wiki.ubuntu.com/ServerTeam</a><br>
</div></div></blockquote></div><br>