Re: some feedback about security from the user's point of view
Thanks for the reply and the links Robert.
I agree with your point on SSL/TLS not being as computationally
expensive as it used to be, however (as you correctly state) it can be
more of an issue regarding management/resources, as well as red tape.
Regarding Google's statement with SSL/TLS cost being negligible, while I
empirically agree with this one (e.g. in our project's infrastructure
un-accelerated SSL overhead was minimal, even though by default we
employ the strongest cipher suits of it), again this falls into a matter
of integrating SSL into existing infrastructure, a cost that might not
be readily available justifiable to a bureaucratic environment, such as
a university. To put it a bit colloquially, downloading Debian ISOs over
encrypted or unencrypted HTTP will not cause any fluctuation on the
amount of daily sleep I get :)
Regarding the MD5 sum example and certain released PoCs: producing two
"random" files with identical MD5 sums is one thing, introducing a
meaningful backdoor (which means deterministic change) or ten in a
Debian iso and generating an iso file which is similar in size to the
original one and has an identical MD5 sum might be a tad more
computationally difficult (this is my estimation), especially for
something as short-lived as a Linux CD image. Adding into account that
this trick can easily be rendered useless if the end user chooses let's
say SHA256 as opposed to MD5 to verify the downloaded file (and banished
altogether by a simple announcement by Debian team along the lines
of "please use SHA256 to verify all downloads from us". I fully agree
with the removal of MD5 as a sign of "keeping with the times" though.
On 01/23/2011 08:04 PM, Robert Tomsick wrote:
> On Sun, 2011-01-23 at 19:34 +0200, AK wrote:
>
>> a small disclaimer first, I am not affiliated with debian in any way,
>> I am, as the original author would have put it a user.
> The same goes for me, so I suppose my remarks should be taken with a
> comparably-sized grain of salt. :) That said:
>
>> 1) Why is *getting* debian over plain HTTP such a big issue? Assuming
>> that even you get a tampered .iso, it is trivial to verify that it is
>> not the genuine one, even in using a "broken" hash algorithm such as
>> MD5. SSL-enabling all downloads from Debian would have the unfortunate
>> side effects of increasing the load on the servers, requiring more
>> budget from the Debian team, as well as meaning losing a few mirrors
>> around the globe. Personally, I view it as a reasonable risk, provided
>> that the end user verifies the .iso image before installing.
> I think the resistance to the idea isn't so much from the fact that the
> use of SSL is a panacea -- there are obviously numerous ways that one
> can wind up with a compromised OS, the initial download is but one of
> them -- but rather that it would provide a good "first layer" of
> protection against tampering.
>
> While I have done no measurements of this myself, there seems to be some
> [1] consensus [2] that SSL doesn't actually impose nearly as much
> overhead as people think it does, especially if you're dealing with
> long-lasting connections. Obviously there is a good bit of management
> overhead associated with deployment and administration, but at least
> from the performance standpoint it seems (to my untrained eye) like the
> "SSL == serious performance hit" issue has been at least partially
> conquered by Moore's law. From one of the Google engineer's postings
> [2] on the subject:
>
> "In January this year (2010), Gmail switched to using HTTPS for
> everything by default. [...] In order to do this we had to deploy no
> additional machines and no special hardware. On our production frontend
> machines, SSL/TLS accounts for less than 1% of the CPU load, less than
> 10KB of memory per connection and less than 2% of network overhead. Many
> people believe that SSL takes a lot of CPU time and we hope the above
> numbers (public for the first time) will help to dispel that.
>
> If you stop reading now you only need to remember one thing: SSL/TLS is
> not computationally expensive any more."
>
> [1]
> http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
>
> [2] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
>
>> Regarding MD5, while indeed it has been broken, is it not sufficient
>> for simple checksumming purposes? I have not looked throughly into
>> this
>> so please feel free to correct me but how practical would have been
>> for
>> someone to create a meaningful debian .iso AND introduce backdoors
>> to it
>> AND create a MD5 sum that matches the original one? Are there any
>> examples of it in the wild?
> I don't know of any examples for ISO images, but there definitely have
> been PoCs released capable of generating collisions for other types of
> file. Of course I imagine that anyone who actually 1) can produce and
> 2) does produce such collisions for ISOs is probably doing so for
> nefarious purposes, and is thus not terribly eager to make public the
> existence of whatever tools they created/used...
>
> There are already SHA1, SHA256, and SHA512 sums available for the images
> right now, so really the removal of MD5 would be more a show of good
> faith than a practical improvement to security. Of course if any
> documentation actually recommends the use of MD5 over the other
> digests... well that's another matter.
>
> Cheers,
> Rob
>
>
Reply to: