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