On Fri, 2016-01-08 at 09:35 -0800, Russ Allbery wrote: > Moving the goalposts from trivial MITM via a rogue AP to obtaining a > fradulent SSL certificate is probably not "hard" security, whatever > that > means to you, but is a substantial increase the level of work > required for > the attacker. Well, I think that's what most people wrongly assume and therefore may easily fool themselves into a false sense of security. Sure, such an attack is probably not doable in 5mins for the neighbouring colleague who wants to play a prank - but so one is typically not the person who really wants to attack a project like Debian. And as I've said, the typical procedure how verification takes place on most CAs involves so many unsecured paths, mail, whois, how the whois is set by the (presumed) owner, how the registrar communicates that to the registry , how the CA retrieves the whois... It seems foolish, if at the one side many crypto algos (MD5, DSS, etc.) and keylenghts are considered to be not enough by people, while on the other side, they put their whole trust into the above weak procedure to secure their 4096 bit keys ;-) > Given that it's a fairly trivial change in most cases, > since most Git services already expose the repository via HTTPS, I'm > not > sure why you're objecting. I didn't object... I just wanted to express that where possible, ssh should be used rather than https. AFAIU, DDs and DMs already have some sort of trust path to Debian (and I hope it's better than trusting GANDI ;-) ), so they should already have a secure way to retrieve the public host keys of Debian Servers, and if not, simply provide them in a package, or somewhere signed by some Debian Archive key or so. Of course this applies only to the actual DDs and DMs, and not to anonymous access - there the best we can get is of course https (as you pointed out yourself, securing. Unfortunately, Debian put all its trust-eggs into someone else's basket - GAND - and thus into the basket of UTN (which belongs to whom right now?), and thus IIRC under the authority of national security letters and gag orders. I've already mentioned previously that this was at best questionable, because anyone who's more deply into Debian than just visiting the website (i.e. reading security.debian.org, BTS webinterface, accesing the mailing list archives - in short, everything that's https secured) has now no longer the chance to really securely interact with this systems. When Debian had its own CA, this was at least in principle possible and it would have also allowed to really securely use git over https with Debian's repos. Again, at least in principle, because IIRC, git didn't directly allow to set the trusted CA for a repo (or does it? :) ). > I'm not letting random Internet users ssh into my Git repository > host, > thanks. Securing untrusted ssh is a pain with a lot of fail-open > pitfalls. I always tightly firewall ssh to only IP addresses I'm > actually > using. Sorry, I should have made more clear, that I was talking about people who typically have write-access to these repos, from which one could/should hope, that they have a proper trust path and are allowed some form of access anyway. Oh and I should perhaps mention,... at least when using git with gitolite, I'm fairly confident that one actually can secure ssh enough that it shouldn't be a problem to give people access even it those are not 100% trusted. One can restrict things from ssh side quite nicely, and back when I set up my own gitservers, I got Sitaram to add a shell mode of gitolite, which I think increases security even more. Even a security paranoid as myself doesn't have too many concerns about it =) > I'm also entertained that you think that the completely unchecked > host > keys that everyone always approves without even looking at are better > security than X.509 CAs, for all the problems those have. Well I'm always happy if I can help to entertain people ^^ But seriously,... if someone's so stupid to simply accept the remote keys without checking... there's nothing one can do (unless perhaps banning such guy for life if one ever finds out). The same as such person blindly accepts an unverified key, the same he/she may simply post his/her trusted DD GPG key on pastebin ;) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature