Ben Nagy wrote:
>
> [dangers of administrating your firewall via HTTPS]
>
> 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)
Yes, the attack scenario definately included using the same browser
to access internet servers. However, first thing's first:
It is definately possible to write a _secure_ (i.e. minimalistic) HTTPS
server for firewall management (although, as I said previously, web
servers all tend to have holes in them for some reason I have yet to
understand :/ ), so let's assume for the sake of discussion that we're
using a server that can't be directly attacked
On the same note, it should be possible to write a secure browser,
but that's not going to happen any time soon. Besides, requiring a
purpose-written secure browser for managing the firewall defeats
the purpose of having the web interface in the first place, so
this is obviously not an option.
So.. vulnerabilities?
A recent case in point is, as a previously pointed out, the
vulnerability that arises from hitting the back button in IE:
http://online.securityfocus.com/archive/1/267561
Old vulnerability variations include the equivalent of doing
"history(-1)" in a script.
I suppose we don't have to rehash all the browser
vulnerabilities to date? :)
This _could_ all be reasonably secured, assuming:
- The HTTPS server is well-written (probably not a generic one)
- You use a reasonable secure browser (not IE)
(whoops, this won't sit well with a lot of people)
- And/or: you use a separate management station that isn't
allowed to browse the internet, and you only allow management
from that station. (But in many people's eyes, this _also_
defeats the purpose of web based administration!)
But, IMHO, that's a lot of assumptions, which is why I started
yammering in the first place.
>
> ["secure" SNMP...]
> And I'd like it installed by the tooth fairy, please.
:)
> 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.
As far as the crypto goes, this basically limits you to
IPsec, SSL or SSH. IPsec is doable in some setups, but is probably
too complicated for "most" organizations. SSL or SSH are less
complicated setup-wise, but still come with a fairly large code
bulk. Although granted: a lot of it can probably be stripped out.
More below...
> 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").
Wrote the crypto framework, yes; based on a couple of basic and
well-understood methods of setting up an encrypted channel
using only a symmetric cipher and a hash function (CAST-128 and
SHA-1 in our case). I would give you a reference, but I can't
seem to find it in Applied Cryptography right now. %#¤&%#
> This _instantly_ starts my snake-oil detector ringing,
Which, generally speaking, it ought to do.
Lord knows we've all seen too many piss-poor excuses for crypto
frameworks in everything ranging from firewalls with large
installed user bases to operating systems with even larger
installed user bases.
> 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.
Speaking in the general case: yeah, you're right.
Speaking specifically about our crypto framework: it _has_ been
audited by several clueful people. Although that probably
still doesn't mean much to you, coming from me. On a personal
note, I've been quietly pondering on what publishing the specs
could accomplish here...
The reason for designing our own framework was simply keeping
the code bulk down. Our crypto layer (data goes in one end
and it speak TCP sockets in the other end), including the
crypto/hash/hmac routines, is about 4000 lines of code.
The complete (Open)SSH package is ~55000 lines of code, although
obviously not _all_ of it should be counted, and comes with
backwards-compatibility code for stuff that shouldn't be used
to administrate firewalls (e.g. SSH1, which doesn't authenticate
the data stream).
Personally speaking, I trust our framework more than I trust
SSH, SSL or IPsec, but, then again, you know nothing of what
I trust, and it tells you absolutely nothing of the quality
of "any random firewall that uses its own crypto framework",
which, as we were talking about firewall management in the
general case, makes your point very valid. I even have to
agree with you: _I_ don't trust every random crypto-enabled
app that I come across.
Maybe I should have just kept my trap shut about my views
in this area and spared myself the pain :)
--
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
"Senex semper diu dormit"
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
