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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1295805878.2295.45.camel@kestrel
