On Wed, Mar 27, 2002 at 04:17:53PM +0100, Jean-Michel Hemstedt wrote:
> > > On Tuesdayen den 26 March 2002 16.33, Balazs Scheidler wrote:
> > The user is not capable of deciding whether a certificate presented to him
> > really belongs to the given server. They simply press 'continue' without
> > thinking that the server they are communicating with is fake.
> >
> > Of course if you AND your users know what the hell a certificate is, they
> > can decide but I think you are a minority.
> >
>
> We are far from TPROXY, but here is my point of view:
>
> - HTTPS decrypting proxy is an (mitma) alternative if you want
> to block all "CONNECT" operations in your proxy. But it sounds
> like an absuse protection against inside users. And unfortunately,
> for the user itself, as mentionned above, it will block services
> such as home banking as well.
* If you allow HTTPS transparently, CONNECT is not invoked.
* If you use a non-transparent HTTP proxy, the client requests a CONNECT from
the proxy which in turn connects to the web server opening a hole in your
firewall.
You have three options:
1) enable SSL traffic without being able to verify its contents (Nimda
through SSL anyone?)
2) disable SSL completely
3) use a decrypting SSL proxy with content verification
>
> - If your proxy allows "CONNECT" requests, then virtually anything
> can pass through it, and HTTPS decrypting proxy does not make sense.
why? I attach a decrypting HTTPS proxy when a CONNECT request is
encountered, as follows:
* Nontransparent HTTP proxy receives a CONNECT www.homebank.hu:443 HTTP/1.0 request
* Http proxy stacks in an SSL proxy which receives the datastream after CONNECT
* The SSL proxy decrypts traffic and stacks in a HTTP proxy again:
[nontransparent HTTP proxy]
|
[decrypting SSL proxy invoked after CONNECT]
|
[stacked transparent HTTP proxy]
The above scenario is completely doable with Zorp.
> Then, if you are really concerned by insider attacks, what about a
> session/tunnel timer which could be a possible (ugly) protection
> against wormhole kinds of attacks, without invalidating ssl?
IMHO it's not about insider attacks, its about incompetent clients who start
trojan horses, get viruses and accept certificates without even knowing what
it means.
Decrypting on the firewall is not invalidating SSL. SSL is
authentication+integrity protection+crypted traffic. Authentication is
performed by the firewall, integrity protection is performed and the whole
traffic is crypted. Authentication is moved from the client computer to the
firewall, which checks it more strictly than most clients do.
And the firewall accepts a certificate based on its policy. No user should
override this.
Of course when moving the certificate authentication is not an option
(because client certificates are used, which are stored on a hardware
token), you can still use a 'hole', but this can be limited to a few
addresses only.
btw: I think this discussion is off-topic on netfilter-devel, so we might
continue our discussion in private.
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
