On Sat, 20 Sep 1997, Adam Shostack wrote:
> In that case, can you use a proxy that will do SSL to the
> outside, and throw up a notice to your user that its cleartext on the
> lan?
I'm looking at that issue right now. I'd rather just have the proxy MITM
the SSL, it's much cleaner overall, and easier to support.
> As a general design issue, I think firewalls are becoming less
> useful as most things users do run over HTTP; they are still useful in
> that they protect all those other problems, but the desktop security
> problem looms large.
>
> Also, do you proxy DNS? The latest phrack has a tool to
Pretty much, the proxy server handles DNS requests, one of the advantages
of non-transparent proxies is that the client need never resolve external
addresses. Since I control the proxy, no clients get external name
resolution answers directly or indirectly.
> tunnel a connection over DNS packets. I expect that you've thought
> about the issue, but I'll point out in a general way that going to
> these lengths on your net connection may be not worthwhile if your
> users can carry data out in their attache cases or on a DAT tape.
In a secure data environment, that's an issue. In an environment where
one simply wants to do as much as possible to stop someone from tunneling
in to attack hosts and services, the issue of everything over HTTP is
something which is _slightly_ more managable, not pretty, not easily, but
doable to a level where I can sleep at night, even if fitfully.
> The issue is that tunnel support is something that I might
> play with in a cryptographic level. Its not obvious to me that having
> the hook per se in the protocol is free of problems.
Nor is it to me, which is why I posed the questions and follow-ups here.
I _think_ it's solvable, but I'd like to know that. I don't have a
problem with calling Winn and trying to slide into things, I'd just like
to feel it's worth attempting.
> For example, if we can chain proxies, perhaps I have an attack
> where the proxy chain is long enough that the user only sees the right
> parts of it. A real URL that the Ed Felton had set up was like:
> (www.microsoft.com.cs.research.princeton.edu/updates/hotfix2.exe)
That's why the pseudo-code had tunnel counters, not just flags,
I thought about that pseudo-code for 4 or 5 minutes before I wrote it.
> Your pseudo-code example is clean, these things tend to pop
> out in subtle ways when code is being written. There are also issues
> when adding back compatibility to a protocol (see Wagner & Schneier on
> SSL3, on www.counterpane.com); avoiding rollback attacks is *really*
> tough.
Implementation is always the hard part, that's why I do strategy ;)
> Its unfortunate that we can't pull out a standard protocol
> that has clean support for this sort of thing, because I agree with
> you that it would be damn useful.
Just once, I'd like to see true proxy support in a cryptographic protocol, where at
the administrator's option, and with notification of each end, it would be possible to
enforce a security policy. If there's something that we, as a collective group, can
do to further that, then I think it's a good thing. But then again, if I'm the only
one who has these concerns, it's not worth the battle.
Watching all these folks allow IP protocol 47 in at will for PPTP, along
with 24x7 cable modem access to the Net makes me think that we'll see a great deal
more tunneling activity in attacks. If we don't speak now, we'll be the ones doing
clean-up from attacks at our sites, not the protocol developers.
If I can get some sort of feeling (privately, the list doesn't
need cluttered) of who's interested in such a thing, as well as some public
disucussion on these issues (VPNs are coming, we as an industry need to
be aware of the issues - unless Marcus objects to this list being used to
discuss such things, I'd rather we hashed it all out now)
[This space left blank for moderator's note]
If there's sufficient interest, I can set up a side list for the discussion if we
stray too much, or the volume gets too bad. Opinions on such should also be directed
to my address. I'd rather we, as firewallers, could reach a pseudo-consensus and move
it forward now, even if it's slated for a future version, than have us come in on the
back end and only get lip service a la the CONNECT headers.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts_at_clark.net which may have no basis whatsoever in fact."
PSB#9280
Received on Sep 20 1997
Intro
