Re: tn5250 and SSL -- LINUX5250

On Tue, Sep 25, 2001 at 01:00:11AM -0500, Scott Klement wrote:
>
> On Mon, 24 Sep 2001, Jay 'Eraserhead' Felice wrote:
> >
> > I used tn5250 with SSH port forwarding for the longest time as my only
> > access to an AS/400 from home.  I also use CIPE (you can search 
>freshmeat.net
> > for it) to create a tunnel from my Linux laptop to the firewall, then you
> > can use tn5250 to connect to the AS/400 as if you were on the AS/400's LAN. 
> I
> > can still use this method.
>
> Thanks, I'll take a look at CIPE.  It sounds like you're running a PPTP
> through a tunnel -- that could be useful...

Sort of the same idea, but CIPE is another thing from PPTP entirely.  It
just creates a blowfish-encrypted point-to-point interface on a Linux box
(and now there's a Win32 client as well), and encrypts traffic.  You use
native linux routing to get the traffic from one place to another.

I wrote a chapter for a book on tunneling protocols ;-)

>
> I also discovered that it was pretty easy to write a simple proxy that
> I could run on my home PC that would encrypt the data and connect to the
> telnet-ssl server on my AS/400.
>
> >
> > As for SSL, it should be very easy to add SSL support to tn5250 - it was
> > modularized that way originally.  A new stream "class" has to be implemented
> > which uses the OpenSSL API instead of the plain socketing API.  I wish I
> > had the time to work on it, as I can probably hack it out in a day or two.
> > Such is the life of the business owner *sigh*.
> >
> > -Jay 'Eraserhead' Felice
>
> Actually, on Sunday I started hacking out an 'sslstream' module for
> tn5250...  starting with telnetstr.c as a base, and changing it to work
> with the SSL API's.

Cool!  I'm glad someone has the time to do it.

>
> The pain is going to be in curses_terminal_waitevent, since it tries
> to do a select() on the socket descriptor as well as on fd 0.  This
> won't work with SSL, since select() will only see what's happening on
> the TCP level.   SSL reads data from TCP in blocks, and buffers the
> decrypted data, so you can't simply use select() on the descriptor.

Looking at the ssl manpage, if you use SSL_get_rfd() to retreive the read fd
for that connection, select() should still work.  I recall select()ing on an
SSL fd successfully, although I can't remember where.  The SSL library will
even work with non-blocking sockets so the only new case is that
it is possible for tn5250_display_waitevent()/tn5250_terminal_waitevent()
to return a data event but there isn't enough data to decrypt, so the SSL API
would return that there is no new data (but it would have to read all the
data on the socket, so we wouldn't spin on select()).  I just did a quick
once-through the code, and I can't see anywhere that would be a
problem---the way the handle_receive() "method" works is to hork as much data
as possible and see how many records it can make out of it.  As long as the
SSL implementation keeps to those semantics, I don't figure you'd need to hack
it.

>
> And since that's in the terminal object, rather than the stream object,
> anything I do to fix it seems like a kludge :)

Don't think you need to ;-)

>
> But... I'll figure something out.
>

Good luck,
-Jay 'Eraserhead' Felice

Now if someone wants to do the password hash stuff, that'd be really cool.