Forum: NGINX Interest in extending FastCGI / SCGI support to allow TLS encrypted connections to back end?

Hi,

I was wondering if there was any interest in extending the FastCGI and
SCGI implementations in Nginx to allow a TLS encryption to the
application backend?

Currently if you have Nginx on one machine and your FastCGI / SCGI
application on another machine then communications between the two will
be unencrypted. Of course you can use something like stunnel (which
someone on this list told me about helpfully a while ago) to encrypt the
communications but that seems a bit messy. If Nginx supported TLS
encryption natively then applications using FastCGI or SCGI could be
upgraded to take advantage of that fact if the developer thought it was
worthwhile.

I can't be the only person who wants a 100% encrypted connection from
the browser to Nginx to the FastCGI application to the database.

Hello.

2013/01/18 17:45:13 +0000 Some Developer <someukdeveloper@gmail.com> => 
To nginx@nginx.org :
SD> be unencrypted. Of course you can use something like stunnel (which
SD> someone on this list told me about helpfully a while ago) to encrypt 
the
SD> communications but that seems a bit messy. If Nginx supported TLS

*CGI interfaces look to be the previous century demand. HTTP(S) seems to 
be
the trend, even for the newly developed databases.

What's messy with your 'stunnel'? Why shouldn't you use the 'nginx' on 
the
backend side with https as an uplink protocol? The your 'fastcgi client' 
nginx
should use then the 'nginx on a backend side' as an https upstream.

SD> I can't be the only person who wants a 100% encrypted connection 
from
SD> the browser to Nginx to the FastCGI application to the database.

Are there any other web server(s) having this feature implemented then?

Thank you.

--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: 
1754B9C1

On 20/01/13 15:10, Peter Vereshagin wrote:
> Hello.
>
> 2013/01/18 17:45:13 +0000 Some Developer <someukdeveloper@gmail.com> => To 
nginx@nginx.org :
> SD> be unencrypted. Of course you can use something like stunnel (which
> SD> someone on this list told me about helpfully a while ago) to encrypt the
> SD> communications but that seems a bit messy. If Nginx supported TLS
>
> *CGI interfaces look to be the previous century demand. HTTP(S) seems to be
> the trend, even for the newly developed databases.

Unfortunately there really isn't much that you can use instead of
FastCGI or SCGI if you want to be able to host multiple applications
using different languages in a consistent manner.

> What's messy with your 'stunnel'? Why shouldn't you use the 'nginx' on the
> backend side with https as an uplink protocol? The your 'fastcgi client' nginx
> should use then the 'nginx on a backend side' as an https upstream.

I'm not sure I completely understand your point here. Are you suggesting
that you just run a simple Nginx server on the application so that the
front end Nginx server can just pass the requests to the Nginx on the
application server via HTTPS and then the local Nginx server just passes
the requests on to the application server on 127.0.0.1?

> SD> I can't be the only person who wants a 100% encrypted connection from
> SD> the browser to Nginx to the FastCGI application to the database.
>
> Are there any other web server(s) having this feature implemented then?

Not that I am aware of.

Hello.

2013/01/21 07:07:46 +0000 Some Developer <someukdeveloper@gmail.com> => 
To nginx@nginx.org :
SD> On 20/01/13 15:10, Peter Vereshagin wrote:
SD> > 2013/01/18 17:45:13 +0000 Some Developer 
<someukdeveloper@gmail.com> => To nginx@nginx.org :
SD> > What's messy with your 'stunnel'? Why shouldn't you use the 
'nginx' on the
SD> > backend side with https as an uplink protocol? The your 'fastcgi 
client' nginx
SD> > should use then the 'nginx on a backend side' as an https 
upstream.
SD>
SD> I'm not sure I completely understand your point here. Are you 
suggesting
SD> that you just run a simple Nginx server on the application so that 
the
SD> front end Nginx server can just pass the requests to the Nginx on 
the
SD> application server via HTTPS and then the local Nginx server just 
passes
SD> the requests on to the application server on 127.0.0.1?

Short answer: yes.

127.0.0.1 or local socket or DMZ neighbor (the whatever).

What's wrong with stunnel then?

I have my interest as an author of 'fcgi_spawn' for perl 'cgi alike' 
apps:

  http://search.cpan.org/dist/FCGI-Spawn/bin/fcgi_spawn

Had never mind about SSL'ing the socket to listen for...

Thank you.

--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: 
1754B9C1

On 21/01/13 07:31, Peter Vereshagin wrote:
> SD> that you just run a simple Nginx server on the application so that the
> SD> front end Nginx server can just pass the requests to the Nginx on the
> SD> application server via HTTPS and then the local Nginx server just passes
> SD> the requests on to the application server on 127.0.0.1?
>
> Short answer: yes.
>
> 127.0.0.1 or local socket or DMZ neighbor (the whatever).
>
> What's wrong with stunnel then?

Nothing is wrong with stunnel other than it adds extra complexity to
your deployment. It would be nice if Nginx could handle this on its own.
It clearly already can due to its support of HTTPS on the browser side
so I can't imagine it would be very hard to add support on the FastCGI
or SCGI side.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 18/01/2013 18:45, Some Developer ha scritto:
> Hi,
>
> I was wondering if there was any interest in extending the FastCGI and
> SCGI implementations in Nginx to allow a TLS encryption to the
> application backend?
>
> Currently if you have Nginx on one machine and your FastCGI / SCGI
> application on another machine then communications between the two will
> be unencrypted.

Use Nginx on machine A and Nginx on machine B.
Then, on machine B, use FastCGI/SCGI/uWSGI to talk with your 
applications.

> [...]


Manlio Perillo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlD9LDkACgkQscQJ24LbaUTm9ACdFY/VuIiAMjqbfEwaRZn8zofp
pykAn3oX5mPy6rkT5N/wk2liwkaKI6ZY
=+S3y
-----END PGP SIGNATURE-----

On 21/01/13 11:53, Manlio Perillo wrote:
>
> Use Nginx on machine A and Nginx on machine B.
> Then, on machine B, use FastCGI/SCGI/uWSGI to talk with your applications.

OK. This sounds like the best option.

Thank you both for your help.

Hello.

2013/01/21 11:15:51 +0000 Some Developer <someukdeveloper@gmail.com> => 
To nginx@nginx.org :
SD> On 21/01/13 07:31, Peter Vereshagin wrote:
SD> > 2013/01/21 07:07:46 +0000 Some Developer 
<someukdeveloper@gmail.com> => To nginx@nginx.org :
SD> > SD> On 20/01/13 15:10, Peter Vereshagin wrote:
SD> > SD> > 2013/01/18 17:45:13 +0000 Some Developer 
<someukdeveloper@gmail.com> => To nginx@nginx.org :
SD> > SD> > What's messy with your 'stunnel'? Why shouldn't you use the 
'nginx' on the
SD> > SD> > backend side with https as an uplink protocol? The your 
'fastcgi client' nginx
SD> > SD> > should use then the 'nginx on a backend side' as an https 
upstream.
SD> > SD>
SD> > SD> I'm not sure I completely understand your point here. Are you 
suggesting
SD> > SD> that you just run a simple Nginx server on the application so 
that the
SD> > SD> front end Nginx server can just pass the requests to the Nginx 
on the
SD> > SD> application server via HTTPS and then the local Nginx server 
just passes
SD> > SD> the requests on to the application server on 127.0.0.1?
SD> >
SD> > Short answer: yes.
SD> >
SD> > 127.0.0.1 or local socket or DMZ neighbor (the whatever).
SD> >
SD> > What's wrong with stunnel then?
SD>
SD> Nothing is wrong with stunnel other than it adds extra complexity to
SD> your deployment. It would be nice if Nginx could handle this on its 
own.
SD> It clearly already can due to its support of HTTPS on the browser 
side
SD> so I can't imagine it would be very hard to add support on the 
FastCGI
SD> or SCGI side.

It's fine only for the smaller half of cases when the backend has only 
one
application (fcgi or scgi) server per host.

Back in time when one application server was handling several 
application(s)
this did more sense. But this just doesn't seem to be a web applications
architecture trend any more.

Adding more application to the typical nginx consumer's backend means 
adding
more application servers therefore more ports/sockets to listen.

The more ports to listen on the outer network means more complication(s) 
e.
g., firewall and encryption on each of them, from both frontend and a 
backend
sides.

At the same time being backed by nginx (or backing nginx) those daemons 
should
feel better with outer network instabilities, e. g., avoiding 'slow 
client
problem' that may happen between frontend and backend hosts keeping from 
use
of the full potential of the application servers and so on.

I believe it's not hard to implement encryption in the nginx fcgi/scgi 
client,
just think it's not a future targeting and can decrease the growth of
installations number, on backends particularly. ;-)

Thank you.

--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: 
1754B9C1