> What I'm talking about is separating the encryption and authentication,
> so you can establish an encrypted channel to the firewall, look at the
> authentication information there, then establish a new encrypted channel
> to the destination based on that, like the way ftp-gw works. This doesn't
> have to be totally transparent... you can do a login "user @
dest" at the
> firewall. Let it print a message, syslog, popup, whatever, saying
> that it's going through a proxy, so you can be aware that a man-in-the-
> middle attack might be going on.
Sounds like you are talking about interactice logins? SSLrsh does not
support rlogin. I use stelnet for that.
I use a modified tn-gw for in-bound connections configured
to only accept an SSL connection (forced not negotiated). Like
stelnetd, tn-gw can be told to accept the X.509 cert as
authentication, otherwise it will extract the common name field from
the certificate and offer it up to the authsrv. Once authenticated
you can connect to the internal host if the authsrv allows it. That
connection is not currently SSL based as tn-gw would have to negotiate
it using its own certificate.
For out-bound secure connections I just use the normal tn-gw.
I just stelnet to the tn-gw, since it does not negotiate SSL the
session is unencrypted so far. I then connect to gate.quick.com.au
which negotiates SSL and I get a verified end to end encrypted
session.
> > For interactive sessions, you can proxy ssh btw. At one site where I
> > work I have set up tn-gw to treat port 22 as a "raw" port, and the
> > guys who use ssh have hacked themeslves a simple proxy that negotiates
> > the connection via tn-gw, and then hands the socket to ssh - I think
> > that is how it works.
>
> I'd be interested in seeing that code.
I don't have it, sorry but I'm pretty sure some of the guys who do,
read this list.
--sjg
References:
|
|
