> Actually the question was about SSLr*, but the guy was talking about
> ssh.
Ah.
> If there is much demand for it, ssl_rcmd() could probably be modified
> to handle HTTPS's CONNECT protocol, so you could possibly just use
> your WEB proxy - I'll look into that. Anyway you do it though, you
> can forget your secondary error/signal channel...
I'm not interested in out-proxies. I can use socks for that if I want to.
I don't like HTTPS and I don't like socks, but they'll do...
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.
This would make things a LOT easier for support people in the field, and
would reduce the complexity of the firewall.
> 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.
Follow-Ups:
References:
|
|
