# Interest in extending FastCGI / SCGI support to allow TLS encrypted connections to back end? **URL:** \ **Category:** NGINX\ **Created:** [January 18, 2013, 6:46pm UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618 "2013-01-18T18:46:02Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [January 18, 2013, 6:46pm UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/1 "2013-01-18T18:46:02Z")
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. ---
**Author:** ![newdude](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/aca169/32.png) [@newdude](https://www.ruby-forum.com/u/newdude)\ **Post date:** [January 20, 2013, 4:12pm UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/2 "2013-01-20T16:12:20Z")
Hello. 2013/01/18 17:45:13 +0000 Some D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) =\> To removed\_email\_address@domain.invalid : 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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ([http://vereshagin.org](http://vereshagin.org)) pgp: 1754B9C1 ---
**Author:** ![newdude](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/aca169/32.png) [@newdude](https://www.ruby-forum.com/u/newdude)\ **Post date:** [January 21, 2013, 8:08am UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/3 "2013-01-21T08:08:39Z")
On 20/01/13 15:10, Peter Vereshagin wrote: > Hello. > > 2013/01/18 17:45:13 +0000 Some D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) =\> To > removed\_email\_address@domain.invalid : > 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. ---
**Author:** ![newdude](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/aca169/32.png) [@newdude](https://www.ruby-forum.com/u/newdude)\ **Post date:** [January 21, 2013, 12:16pm UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/4 "2013-01-21T12:16:23Z")
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. ---
**Author:** ![newdude](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/aca169/32.png) [@newdude](https://www.ruby-forum.com/u/newdude)\ **Post date:** [January 21, 2013, 8:33am UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/5 "2013-01-21T08:33:11Z")
Hello. 2013/01/21 07:07:46 +0000 Some D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) =\> To removed\_email\_address@domain.invalid : SD\> On 20/01/13 15:10, Peter Vereshagin wrote: SD\> \> 2013/01/18 17:45:13 +0000 Some D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) =\> To removed\_email\_address@domain.invalid : 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: [fcgi\_spawn - FastCGI server for CGI-like Perl applications effective multiprocessing, the executable daemon of FCGI::Spawn - metacpan.org](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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ([http://vereshagin.org](http://vereshagin.org)) pgp: 1754B9C1 ---
**Author:** ![newdude](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/aca169/32.png) [@newdude](https://www.ruby-forum.com/u/newdude)\ **Post date:** [January 21, 2013, 1:39pm UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/6 "2013-01-21T13:39:54Z")
On 21/01/13 11:53, Manlio P. 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. ---
**Author:** ![newdude](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/aca169/32.png) [@newdude](https://www.ruby-forum.com/u/newdude)\ **Post date:** [January 21, 2013, 12:54pm UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/7 "2013-01-21T12:54:20Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 18/01/2013 18:45, Some D. 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 P. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - [http://enigmail.mozdev.org/](http://enigmail.mozdev.org/) iEYEARECAAYFAlD9LDkACgkQscQJ24LbaUTm9ACdFY/VuIiAMjqbfEwaRZn8zofp pykAn3oX5mPy6rkT5N/wk2liwkaKI6ZY =+S3y -----END PGP SIGNATURE----- ---
**Author:** ![newdude](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/aca169/32.png) [@newdude](https://www.ruby-forum.com/u/newdude)\ **Post date:** [January 21, 2013, 3:22pm UTC](https://www.ruby-forum.com/t/interest-in-extending-fastcgi-scgi-support-to-allow-tls-encrypted-connections-to-back-end/225618/8 "2013-01-21T15:22:42Z")
Hello. 2013/01/21 11:15:51 +0000 Some D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) =\> To removed\_email\_address@domain.invalid : SD\> On 21/01/13 07:31, Peter Vereshagin wrote: SD\> \> 2013/01/21 07:07:46 +0000 Some D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) =\> To removed\_email\_address@domain.invalid : SD\> \> SD\> On 20/01/13 15:10, Peter Vereshagin wrote: SD\> \> SD\> \> 2013/01/18 17:45:13 +0000 Some D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) =\> To removed\_email\_address@domain.invalid : 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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ([http://vereshagin.org](http://vereshagin.org)) pgp: 1754B9C1