Java Applet Client for STUNNEL-fronted server

Thread view:

Richard Maher - 17 Jun 2007 07:19 GMT

Hi,

I currently have an intranet-resident JAVA Applet that connects back to the
Application Server via standard TCP/IP sockets using the java.net.Socket
class, and everything is peachy. What I'm looking at doing now is making it
Internet friendly by providing host authentication (don't care about client
authentication at the mo) and strong cryptography between client and server.

OpenSSL and Stunnel (I don't want to have to make the Application Server SSL
compatible if I don't have to) are available on the server box therefore I
would dearly love an example of a JAVA client that can talk javax.net.SSL
(or something else) to a Stunnel-fronted server. (Less is definitely more
here - The least number of client keys and or certificate-generations the
better!)

Can anyone please help me with this? Obviously example-code would be ideal,
as would first-hand accounts of the trials and tribulations, but I'll
certainly settle for web-references to the appropriate docs or other
relevant material!

Are all the libraries/code reqd bundled with the JDK and runtime JVM ready?

Is there a better way? (Sadly IPsec is not an option here) Maybe there's an
alternate solution that can preserve the client's true IP address and
present it to the Application Server's "Listen"?

Cheers Richard Maher

Reply to this Message

Richard Maher - 21 Jun 2007 03:14 GMT

Is my question so ambiguous that nobody wants to answer it?

Well, it work for the other guy :-)

Cheers Richard Maher

> Hi,
>
[quoted text clipped - 23 lines]
>
> Cheers Richard Maher

Reply to this Message

Arne Vajhøj - 04 Jul 2007 04:42 GMT

> Is my question so ambiguous that nobody wants to answer it?

I posted some SSLSocket code in your next question, so I assume
all is set here.

Arne

Reply to this Message

Richard Maher - 04 Jul 2007 09:51 GMT

> I posted some SSLSocket code in your next question, so I assume
> all is set here.

Yeah, Rockin' and Rollin' thanks again Arne. (At least I hope so, I haven't
gotten around to testing it yet (with Stunnel), and am currently
experiencing the joys of porting my Internet Explorer JavaScript/HTML to
Firefox :-) On the upside, the Applet stuff worked straight away)

Having said that there is a related topic that you might be able to assist
me with though: -

"The TCP/IP Out-of-band character with Java->SSL->Stunnel."

I know Java can't receive OOB data (except inline) but it can send them and
SSLSocket inherits sendUrgentData() so it's vaguely on topic. The problem I
foresee according to the STUNNEL docs is that unless the OOB character is
in-lined then it will just be ignored. Can anyone confirm this?

SSLv3 seems to mandate that the OOB data be supported (as normal data with a
complete SSL wrapper record) but I can't find anything in the OpenSSL
routines that modify (or inform) an SSL_Read() that it's got the OOB; can
anyone confirm this?

At first glance, I just can't see a problem with STUNNEL/OpenSSL unpacking
the OOB byte and passing it on to the in-the-clear connection (with the
option for *both* inline or OOB) but maybe that's just me?

Cheers Richard Maher

PS. I actually find the whole SSL thing a huge fudge and long for the day
when everyone is talking something more transparent like IPSec! (Or other
VPN solution) Still they'll always be the ubiquitous unauthorised browser
client with a dynamic IP address I suppose.

PPS. If you know much about a "SOCKS - Generic *circuit-level* Proxy Server"
I'd be very willing to listen to that too! But the implementations I've seen
(HP-UX at least) seem to deploy SSH in this space with one process/user and
up-front user authorization and other unpleasantness; any thoughts?

> > Is my question so ambiguous that nobody wants to answer it?
>
> I posted some SSLSocket code in your next question, so I assume
> all is set here.
>
> Arne

Reply to this Message

Arne Vajhøj - 04 Jul 2007 21:54 GMT

> Having said that there is a related topic that you might be able to assist
> me with though: -
[quoted text clipped - 14 lines]
> the OOB byte and passing it on to the in-the-clear connection (with the
> option for *both* inline or OOB) but maybe that's just me?

I would go for a simpler solution.

Either open a second socket connection for this traffic or make
a protocol on the original socket that has both "next data block"
and "urgent interrupt" messages.

Arne

Reply to this Message

Java Applet Client for STUNNEL-fronted server

Free Magazines