(Remember, we were talking about the "best possible way" of administrating a firewall; any little flaw counts :))
Kevin Steves wrote: > > On Tue, Jun 04, 2002 at 02:20:02PM +0200, Mikael Olsson wrote: > > The complete (Open)SSH package is ~55000 lines of code, although > > obviously not _all_ of it should be counted, and comes with > > that number seems overstated; for openssh-3.2.3p1 i see: > > $ kdsi *.[ch] openbsd-compat/*.[ch] > 43488 7044 10999 4442 total I did "wc -l *.[ch]" in the 3.2.2p1 tarball root dir and got 54355 lines; I even forgot about openbsd-compat and openssl, so it should be even higher if you really want to count the complete package..? Anyway, the numbers here are sort of misleading anyway, since we shouldn't really be counting code that never ever gets exposed until well after the user switch has been made. I was just trying to illustrate the difference in code bulk. (Don't worry, I'm _not_ advocating supersimplistic frameworks like ours for general-purpose use. It's very impractical for anything but administering network gear; specialization does that.) > > backwards-compatibility code for stuff that shouldn't be used > > to administrate firewalls (e.g. SSH1, which doesn't authenticate > > the data stream). > > you are referring to insertion attacks due to CRC usage for data > integrity checking? do you consider v1 to be fundamentally broken? Well, hm, yes and no. Insertion attacks by themselves could be bad enough; consider the consequences of someone for instance inserting random garbage in a stream where you're uploading a new kernel... to a firewall far away... that needs to have 99.999% uptime. Also, from a generally paranoid perspective: best practices dictate that one use a nonreversible hash to authenticate the stream. SSHv1 fails in doing this. Ergo, it's less than perfect, and that's enough for me to strongly recommend SSHv2 and disable v1 in the config. ´ IMHO, for firewalls and firewall administration, the "less exposure" demand is a very real one, so ripping out unused code here is a good thing, and having it around is a bad thing. How MUCH of a bad thing is another story; again: we were shooting for "the best possible", okay? :) > from: http://www.cisco.com/warp/public/707/ssh.shtml > > "If a review of any claimed protocol defects shows that SSHv1 protocol > in Cisco IOS is fundamentally broken, then Cisco will determine if it > is appropriate to migrate to SSHv2 at that time." Keeping in mind that migration would likely be costly for them, I'd take that statement with a pinch of salt. Out of curiosity: do they even _have_ code for SSHv2? Would they need to code it first? Statements like these tend to set me off on a rant though. Why insist on staying with something that is "theoretically flawed", just because a "real" vulnerability hasn't been shown to the public? What if one day some clueful guy comes up with one, and suddenly they've got millions of vulnerable units on their hands? (Bah, I know, the vast majority uses telnet anyway :/ ) Granted, maybe some day someone will find a big-ass hole in the SSHv2 protocol, or maybe in TLS, or maybe in IPsec, or maybe in our framework for that matter. There is always that risk. I still don't think "there are no public vulnerabilities" is a convincing argument, in face of the theoretical flaws. In a risk management scenario (which firewalling is all about), why choose the bigger risk, when there is a better alternative? (Although "SSHv2 is too demanding for the CPUs in the smaller routers" is probably a more convincing argument, and likely closer to the truth :/ ) -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
