Open Bug 247212 Opened 20 years ago Updated 2 years ago

SSL tunnelling program

Categories

(NSS :: Tools, enhancement, P3)

Product:
NSS
Component:
Tools
Version:
3.9.2
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: julien.pierre, Unassigned)

References

Details

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
mozilla.org  . 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 ...
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 
machine.

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.
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 cvs.mozilla.org . The reverse
proxy connects to a remote "SSL CVS server".

2) At the mozilla.org level, a straight proxy is exposed to the outside world
for cvs.mozilla.org . 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
cvs-mirror.mozilla.org, 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 ?

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
mozilla.org in the very short term.  However, the people at mozilla.org 
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.


Nelson, I think you are right, I reversed the terms ;)

I think the stunnel is fine for mozilla.org 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.

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 
username/passwords>

bob
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.

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 mozilla.org 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.
Blocks: 247416
(In reply to comment #3)
> Wan-Teh identified a program named "stunnel" that might do the job for
> mozilla.org in the very short term.  However, the people at mozilla.org 
> 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.
Severity: normal → enhancement
Re-targetting to 3.10 .
Priority: -- → P3
Target Milestone: --- → 3.10
Target Milestone: 3.10 → 3.11
QA Contact: bishakhabanerjee → jason.m.reid
This is not going to happen for 3.11 .
Target Milestone: 3.11 → 3.12
Target Milestone: 3.12 → ---
QA Contact: jason.m.reid → tools
Writing this programmer would be a good exercise for a new NSS programmer.
Assignee: julien.pierre.bugs → nobody
I meant writing this program, of course.

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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.