Re: some feedback about security from the user's point of view
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: