Telnet over SSL

Telnet over SSL

Post by Erik » Sat, 08 Feb 1997 04:00:00



Hi,
Is it possible to have a Telnet-session over SSL? If so, can you tell me
your experions (speed, problems,....)

Thanks,
Erik J


 
 
 

Telnet over SSL

Post by Paul D. Roberts » Sat, 08 Feb 1997 04:00:00



: Hi,
: Is it possible to have a Telnet-session over SSL? If so, can you tell me
: your experions (speed, problems,....)

There's an SSL'd telnet on the normal non-US crypto mirror sites, a search
on SSLey should find it.  I haven't used it, since I don't allow SSL out
of my domain.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions

                                                                     PSB#9280

 
 
 

Telnet over SSL

Post by Paul D. Roberts » Sun, 09 Feb 1997 04:00:00



:
: That's a typo, it's "SSLeay".  You also need the "SSLapps" package

Yup.

: > I haven't used it, since I don't allow SSL out of my domain.
:
: Out of curiosity, why not?

It's a generic transport layer hole in and out of my network.  My security
model specifically requires application layer gatewaying.  There's not a
great deal of differece between allowing SSL out, and allowing TCP out,
except that, as you pointed out, if I want to know what's traversing my
firewall, I can sniff TCP.  

As has been pointed out here before, the continuation of overloading HTTP,
as well as the perceived "need" for new protocols will sooner or later
mean that those of us wishing to have a tightly bounded security model
will be talking about "The good old days, when you could just block that
stuff." pretty soon.  I'm still not caving in before my time.  It's my
responsibility to protect my enterprise to the best of my ability, and I
can't do that within my own comfort level by not knowing what is going in
and out of my network, at least at the application protocol level.  

If I allow SSL out, then I'm back to trusting the end-users not to run
trojaned programs, puposefuly or accidently break the model, and it's bad
enough trying to enforce a browser version, and 'approved' software on the
desktop.

If I were looking to trojan a program to tunnel info out of a network,
I'd have it look for netscape.ini, pull out the proxy info, and go out
port 443 using SSL.  Not only would it work most of the time, but when
someone finally tracked it down, they wouldn't be able to find out what
they lost.  If the tunnel led back in, to say a telnetd on an NT machine,
even if you caught me in the act, you'd have almost no idea what I was
doing to your server or network.

If I did allow it, I'd want to man-in-the-middle it on a proxy, and pass
the resultant HTTP through an appliaction proxy, and re-encrypt it on the
other side.  It gives me the assurance that it's HTTP, as well as the
ability to log the transactions for auditing and usage tracking.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions

                                                                     PSB#9280

 
 
 

Telnet over SSL

Post by Gaud » Sun, 09 Feb 1997 04:00:00




>: Hi,
>: Is it possible to have a Telnet-session over SSL? If so, can you tell me
>: your experions (speed, problems,....)
>There's an SSL'd telnet on the normal non-US crypto mirror sites, a search
>on SSLey should find it.  I haven't used it, since I don't allow SSL out
>of my domain.
>Paul
>-----------------------------------------------------------------------------
>Paul D. Robertson      "My statements in this message are personal opinions

>                                                                     PSB#9280


The gurus there will answer your question asap.

To join, check the ns website.

Gaudia

 
 
 

Telnet over SSL

Post by Paul D. Roberts » Mon, 10 Feb 1997 04:00:00



: Are you sure you're not thinking of HTTPS, instead of SSL?

Positive.

:
: SSL is only a secure connection protocol, it lets you secure
: one thing, like an HTTPS (secure http) connection.  

SSL is a transport layer encryption service, unlike SHHTP, HTTPS doesn't
adhear to a HTTP protocol for it's transport.

:
: But you can have SSL on any port... the TLS (IETF
: group making SSL3 a standard) is currently discussing registering 5 new ports
: for SSL secured POP3, IMAP, SMTP, NNTP and FTP.  The SSL telnet I mentioned
: in a previous post uses the normal telnet port.  So 'blocking SSL'
: sounds sort of wierd...  I think what you really mean is blocking HTTPS.

No, I mean blocking SSL, since most places that let SSL through let it go
right through port 443, and since applications aren't bound to well known
ports by architectural methods,  there's nothing stopping anyone from
running an SSLized telnetd on any target port, including 443, and nothing
keeping any client on my network from connecting to it, since, unless I
run a man-in-the-middle attack on it, I don't know if it's HTTP, Telnet,
PC Anywhere, FTP, IRC, or UberHackerTunnel 1.0 going out of my network.

I don't permit generic transports outbound (Socks either).  Yes, it *is*
possible to encapsulate bad things over SMTP, HTTP, etc, but as I've said
before, those are more dectecable, and I can, supposing I log enough,
reconstruct what was lost/stolen/let in/let out.  This is not possible
with a generic encrypted transport layer.  

Even the CONNECT method for HTTPS, which does give at least some header
information isn't sufficient for my requirements.

From Netscape's site at:

http://developer.netscape.com/library/one/sdk/proxy/unixguide/ssl-tun...

"Because the proxy never sees the data, it can't verify that the protocol
spoken between the client and the remote server is SSL.  This means the
proxy also can't prevent other protocols from being passed through."

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions

                                                                     PSB#9280

 
 
 

Telnet over SSL

Post by David Hopwoo » Mon, 10 Feb 1997 04:00:00


[alt.internet.providers and comp.infosystems.www.browsers.ms-windows removed
from Newsgroups]



Quote:> No, I mean blocking SSL, since most places that let SSL through let it go
> right through port 443, and since applications aren't bound to well known
> ports by architectural methods,  there's nothing stopping anyone from
> running an SSLized telnetd on any target port, including 443, and nothing
> keeping any client on my network from connecting to it, since, unless I
> run a man-in-the-middle attack on it, I don't know if it's HTTP, Telnet,
> PC Anywhere, FTP, IRC, or UberHackerTunnel 1.0 going out of my network.
> I don't permit generic transports outbound (Socks either).  Yes, it *is*
> possible to encapsulate bad things over SMTP, HTTP, etc, but as I've said
> before, those are more dectecable, and I can, supposing I log enough,
> reconstruct what was lost/stolen/let in/let out.  This is not possible
> with a generic encrypted transport layer.  

Surely anyone trying to get data out can just do an HTTP post of an encrypted
file. Yes, it's probably easier for you to filter this out from the noise,
but the more encrypted stuff goes out of your network, the more chance someone
has of obtaining a high bandwidth secure channel to the outside. That's
unavoidable, IMHO.

Quote:> Even the CONNECT method for HTTPS, which does give at least some header
> information isn't sufficient for my requirements.
> From Netscape's site at:
> http://developer.netscape.com/library/one/sdk/proxy/unixguide/ssl-tun...
> "Because the proxy never sees the data, it can't verify that the protocol
> spoken between the client and the remote server is SSL.  This means the
> proxy also can't prevent other protocols from being passed through."

Correct. But I don't see why the same isn't true for HTTP etc. I think I
remember hearing that someone once implemented TCP-over-email, just to prove
it could be done.

David Hopwood

 
 
 

Telnet over SSL

Post by Paul D. Roberts » Tue, 11 Feb 1997 04:00:00



: So how do you block SSL, since it could be sent over connections to any port?
: Your proxy checks the initial data in all TCP connections, looking for the
: bytes that say its a ClientHello SSL message?

[follow-ups set to comp.security.firewalls, since everyone else is
probably bored out of their skulls by now]

No, it's an application layer gateway, it only passes approved application
layer data.  In it's case, that means regular unencrypted HTTP requests go
out, and some of them are allowed back in, soon bits of some of them,
since I'm about to allow Internet Explorer, and don't want the
risks of ActiveX, JavaScript, and Java.

If it's not on the very short list of things which are approved to go out,
and the list of machines that are allowed to send it out, then it gets
blocked, and either logged or ignored depending. Since the default is to
reject a protocol, service, or transport, SSL, not just HTTPS, but any
SSL'ized application quite efficiently gets dropped on the floor along
with hundreds of other things.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions

                                                                     PSB#9280

 
 
 

Telnet over SSL

Post by Mark » Tue, 11 Feb 1997 04:00:00



> Hi,
> Is it possible to have a Telnet-session over SSL? If so, can you tell me
> your experions (speed, problems,....)

> Thanks,
> Erik J



Try CSM Proxy - it'll allow SSL<->SSL connections using any TCP
protocol.
We use CSM Proxy (formerly Open Sesame) and it also has many more
benefits besides just acting as a SSL<->SSL server.
They have a free eval at http://www.csm-usa.com

Mark

 
 
 

Telnet over SSL

Post by Paul D. Roberts » Fri, 14 Feb 1997 04:00:00



:
: Surely anyone trying to get data out can just do an HTTP post of an encrypted
: file. Yes, it's probably easier for you to filter this out from the noise,
: but the more encrypted stuff goes out of your network, the more chance someone
: has of obtaining a high bandwidth secure channel to the outside. That's
: unavoidable, IMHO.

First of all, I don't allow encrypted communications out.  Yes, as I've
said, you could theoretically encapsulate over HTTP.  It's not just the
chance of filtering out from the noise, it's the principle of least
privilege.  There are a lot of things you can do to reduce the risk,
allow only certain browser strings through, compare forward and reverse
lookups of sites visited, watch connect frequencies, and ammount of data
transferred (in and out) per site, and things like that.  If something
still goes past, then at least you know that you've done everything that
you can to protect your enterprise.  There is a base level of risk that
you have to accept to connect to the Internet.  Hopefully you've
quantified that risk to the powers that be, even after they spent all that
money on a firewall, and its admin.

: Correct. But I don't see why the same isn't true for HTTP etc. I think I
: remember hearing that someone once implemented TCP-over-email, just to prove
: it could be done.

I never said it wasn't true, as a matter of fact, I've said often enough
that it is true.  Just because something can't be secured 100% doesn't
mean that you shouldn't take steps to make it as secure as possible.

None of it is 100% foolproof, but I feel confident in saying that I'm
doing _everything_ possible under the circumstances to protect my
employer.

It was, I believe telnet over e-mail, hell of a latency problem, but the
largest MTU you've ever seen.  Since it just UUencoded and UUdecoded the
packets at each end, the tunnel was good for any protocol, or every
protocol if you were to put the interface into promiscuous mode and grab
all the IP, IPX, and SNA therein.  The burning question, of course, would
be 'would you notice the extra traffic?'

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions

                                                                     PSB#9280