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
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
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
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
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.
(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.
Re-targetting to 3.10 .
This is not going to happen for 3.11 .
Writing this programmer would be a good exercise for a new NSS programmer.
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.