Last Comment Bug 247212 - SSL tunnelling program
: SSL tunnelling program
Status: NEW
Product: NSS
Classification: Components
Component: Tools (show other bugs)
: 3.9.2
: All All
P3 enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
Blocks: 247416
  Show dependency treegraph
Reported: 2004-06-16 17:48 PDT by Julien Pierre
Modified: 2007-10-30 16:44 PDT (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Julien Pierre 2004-06-16 17:48:09 PDT
The need was recently brought up to our attention for an NSS-based SSL
tunnelling program . The first user would be the CVS server and cvs clients on  . This would be a server program with two modes of operation:

1) reverse SSL proxy . This would have a non-SSL listen socket, and would
forward the data to a secure SSL server, on a local or remote machine .
This allows adding SSL support to client applications . 

2) straight proxy . This would have an SSL listen socket, and would forward the
data to a non-SSL server, on a local or remote machine . This allows adding SSL
support to server applicatiions.

This new program probably needs to borrow code from selfserv ssltap . It would
be best if some code could be shared rather than copied & pasted, but these
tools aren't setup with libraries right now ...
Comment 1 User image Robert Relyea 2004-06-16 18:07:57 PDT
Be very careful about what is advertised in these scenarios --

If reverse proxy is authenticates the session to the server (either through 
username/password or client auth), it needs to make sure it can't be subverted. 
This will almost certainly preclude the use of the reverse proxy on a remote 

The same issue goes for the server (unless the server lives on it's own private 
network, firewalled off from the world).

Proxying on the same machine has been done before, usually in the context of 
subverting US export laws.
Comment 2 User image Julien Pierre 2004-06-16 18:17:44 PDT
Bob, I am aware of the security issues . But I think our tool would have to
allow connecting to remote machines in order to be usable in firewalled
environments. FYI, the use cases we are planning for CVS are :

1) Mozilla developers run a reverse proxy on their local machine . They change
their CVSROOT to point to localhost instead of . The reverse
proxy connects to a remote "SSL CVS server".

2) At the level, a straight proxy is exposed to the outside world
for . It connects to the actual CVS server either on the local
machine, or on a remote machine in a firewalled network . The non-SSL CVS port,
whether local or remote, would no longer be accessible to the outside world. For, it can stay without SSL since there is no auth and no
check-in possible, and the code is all public .

Do you see any issues with the above ?
Comment 3 User image Nelson Bolyard (seldom reads bugmail) 2004-06-16 20:20:21 PDT
Julien, I think you have the terms "reverse" and "straight" exactly 
backwards in your original description above.  

A reverse proxy typically accepts SSL connections from over the internet, 
and then connects locally to a server that does not understand SSL.  
I think that is what would run on the CVS server's box.  

The forward proxy appears to the CVS client to be a local CVS server.  
In that respect, it is exactly a forward proxy.  

Wan-Teh identified a program named "stunnel" that might do the job for in the very short term.  However, the people at 
do not appear motivated to attempt to use it, IMO.  If we don't get 
them started on soemthing with SSL fast, I think we will have difficulty
getting them to adopt something better in the slightly longer term.

Comment 4 User image Julien Pierre 2004-06-16 20:50:10 PDT
Nelson, I think you are right, I reversed the terms ;)

I think the stunnel is fine for server side temporarily if we can't
deliver it fast enough.

However, for the client (developer) side, I really think we need to deliver
something that is NSS-based, so it is guaranteed to work for every mozilla platform.

It seems the client side program is easier to write since we don't have to setup
an SSL listen socket, all the ciphers, etc; which is done in the selfserv code.

I was originally thinking that the tunneling program would be the same for
reverse proxy and proxy, with different options. But perhaps this shouldn't be
the case, to avoid code duplication and maximize code sharing ?

As I see it, there are several options :

1. brand new tool, no code sharing, does both directions . Obviously this wil
take longest .

2. modify selfserv to do both directions, with command-line options

3. modify selfserv to do only the SSL server case, and have a separate program
for the other case (non-SSL server to SSL server)

Which one do you prefer ? I sort of like option 2, but figured you might not
necessarily ... Especially as the changes for proxying could be major, eg. use
non-blocking sockets.
Comment 5 User image Robert Relyea 2004-06-17 11:38:23 PDT
I think that exact scenario is fine. I'm most concerned with the SSL 
connections terminating inside 'secure' locations. I would worry about running 
the client side on a remote machnine, for instance.

The server scenario is really no different from an SSL server which contacts a 
database server behind it's firewall where your actual brokerage account data 
is stored, for instance.

Question, are they planning on doing client auth, or relying on 

Comment 6 User image Julien Pierre 2004-06-17 13:33:00 PDT
The current proposal I made to them is just username/pwd over SSL, not client
auth. Client auth would require the SSL support to be integrated into the CVS
server and it's not something I have suggested we do.

On the client side, the tunnelling program could handle client auth easily, though.
Comment 7 User image Julien Pierre 2004-06-17 16:44:02 PDT
One more comment about the client auth on the client side . It would be easy for
the client-side daemon to provide client auth, but it would always be for the
same user. The client cert would be specified at daemon startup . That's
probably fine.
However, if one wanted to use multiple CVS IDs for checkins from the same
machine, I think the security model would break down. 

Each user would have to run their own proxy on the local machine, and there
wouldn't be a way to prevent someone from logging in to the wrong daemon - it
would just be a TCP local port.

To do client auth the right way would probably require the SSL code to be
integrated into the CVS client program, which I am also not suggesting we do.
However, once we do that, the benefits of SSL session reuse from the proxy would
be eliminated, and might actually notice high CPU usage .

So, there is something to be said here for a proxy solution with
userid/passwords vs client auth in the CVS case.

Even if we don't end up using the tunnel for CVS, I think it's a good tool to
have in NSS, one that I have wanted to add for years actually.
Comment 8 User image Daniel (Leaf) Nunes 2004-06-17 17:13:26 PDT
(In reply to comment #3)
> Wan-Teh identified a program named "stunnel" that might do the job for
> in the very short term.  However, the people at 
> do not appear motivated to attempt to use it, IMO.  If we don't get 
> them started on soemthing with SSL fast, I think we will have difficulty
> getting them to adopt something better in the slightly longer term.

I'll try and investigate stunnel in the next week or so, and i've filed a bug on
myself to track progress on that, and added a dependency on this bug for
eventual use of an nss based tunnel.
Comment 9 User image Julien Pierre 2004-12-08 18:05:53 PST
Re-targetting to 3.10 .
Comment 10 User image Julien Pierre 2005-11-11 16:37:22 PST
This is not going to happen for 3.11 .
Comment 11 User image Julien Pierre 2006-08-04 18:23:39 PDT
Writing this programmer would be a good exercise for a new NSS programmer.
Comment 12 User image Julien Pierre 2006-08-04 18:23:58 PDT
I meant writing this program, of course.
Comment 13 User image Julien Pierre 2007-10-30 16:44:46 PDT
I was informed that Red Hat ported stunnel to NSS recently . I don't know if it meets all the requirements that had been set in this bug. It would be nice to have the tool be cross platform.

Note You need to log in before you can comment on or make changes to this bug.