> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Mikael Olsson [...] > "Marc E. Mandel" wrote: > > > > [firewall management interfaces...] > > > > - An https management interface where both the firewall and the > > administrator(s) have valid certificates. > > Hmm.. for what kind of environment? Aren't you worried about > all the client-side vulnerabilities in browsers?
What's your attack scenario for this, Mike? Client-side browser holes are usually only a problem if we're talking about malicious servers, but you seemed to be suggesting that there was a potential vulnerability when the browser is used by the firewall manager as a "live" Internet browser at the same time. Is that a real attack, or an Akavit dream? More detailed info please. 8) I only ask because HTTPS _should_ be the best way to do this. There should be, somewhere, a reference good, strong HTTPS server for embedded operations, which doesn't use crappy scripting to make it prettier. Mind you, Gauntlet used/uses Java (NOT Javascript) in a standard browser, which _should_ be fine as well. Where's the hole in that? > > - a secure version of Simple Network Management Protocol > >(SNMP).[...] And I'd like it installed by the tooth fairy, please. (NB: I have nothing against devices spitting information _out_ via SNMP to internal hosts. Whether or not my firewall is about to fall over from heat or a bad disk is of interest to me. SNMP RW, however, was invented by the devil to trick unwary admins into fatal mistakes.) > > - an Secure Shell (SSH) implementation that supports both secure > > telnet and secure ftp. > > SSH has problems too; perhaps not so much design-wise as > complexity- wise, which the recent and not-so-recent stream > of bugs in various SSH implementations has shown us. Weeellll...I don't yet have a fixed opinion about whether the keystroke timing style attacks against the underlying crypto make it broken design-wise. The have, obviously, also been implementation errors. And SSH also limits us to a CLI, which, although nice, doesn't fulfill the requirement of being a GUI. We can use SSH to carry encoded info back and forward from some special app, but then we're back to the specialised management app. I am not a GUI bigot - GUIs are fantastic things for some tasks (and are also awful for others). GUIs that make changes to text-editable files make me even happier. > Granted, these problems could probably be worked around by writing > a minimalistic implementation that scraps SSHv1 compatibility > and a few other things that one really shouldn't need in a > firewall. > > Then again, if I had to choose from the above three, SSH would > definately be my choice. > > Regards, > Mikael Olsson Basically, I want standards driven GUIs that use crypto protocols I know everything about - this is why I'm instinctively attracted to HTTPS, even though I know HTTP sucks, and I know that browsers also suck. You, a vendor, are telling me that it's better to use a custom-written app with a "bare bones" crypto connection (which I read as "we wrote it ourselves"). This _instantly_ starts my snake-oil detector ringing, but I still think you're right given the apparent impossibility of writing a browser / server combo that's not like swiss cheese. The problem is that I now have to trust you (hypothetically), and your code-monkeys, to have implemented a ground-up management app and comms protocol correctly. Now that I think of it, I'm _living_ in Switerland and I haven't yet seen any swiss cheese. Hmm. Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
