3 ms·

Sometimes you're running a single application via AWS OpsWorks or so, and your application is handling the SSL because you don't want to pay for an elastic load

Sometimes you're running a single application via AWS OpsWorks or so, and your application is handling the SSL because you don't want to pay for an elastic load balancer to handle the SSL.

danpalmer 12y ago
Fair enough, I'm not familiar with that service. Running a Node.js application without a reverse proxy in front of it sounds like poor practice though, particularly from a security standpoint.
- je42 12y ago
  Do you have any particular security holes in mind that nginx guards which node.js / io.js are open for ?
  - danpalmer 12y ago
    Not off the top of my head, although I know the recommendation at least used to be that Node was not run with full public access. I think it makes sense to separate the security and low level details of serving a public site, and the details of hosting an application though. This is common practice with Django, using gunicorn and nginx, and I believe with Ruby as well in a similar manner.
    - nailer 12y ago
      Django and Ruby /can't/ serve static content at any speed as they block their main thread. Node and nginx use the same model for io, as does Tornado and Eventmachine (though the latter two are nowhere near as popular).
  - jamiesonbecker 12y ago
    Separating your TLS server from your app server also shields your app server from leaks in your TLS server. See: Heartbleed.
    - je42 12y ago
      True, however the higher the number of different software packages that participate in your application's operational environment, the higher the chances that one of these exposes security holes. You have to make a trade-off between complexity and increasing security by isolating pieces of your stack.
  - realityking 12y ago
    You can at least configure some basic sanitizations, so you'r app doesn't have to deal with them. Examples of the top of my head, are normalizing slashes and removing invalid headers. Whether that's worth it is another question.

Sometimes you're running a single application via AWS OpsWorks or so, and your application is handling the SSL because you don't want to pay for an elastic load balancer to handle the SSL.

danpalmer 12y ago

Fair enough, I'm not familiar with that service. Running a Node.js application without a reverse proxy in front of it sounds like poor practice though, particularly from a security standpoint.

je42 12y ago
Do you have any particular security holes in mind that nginx guards which node.js / io.js are open for ?
- danpalmer 12y ago
  Not off the top of my head, although I know the recommendation at least used to be that Node was not run with full public access. I think it makes sense to separate the security and low level details of serving a public site, and the details of hosting an application though. This is common practice with Django, using gunicorn and nginx, and I believe with Ruby as well in a similar manner.
  - nailer 12y ago
    Django and Ruby /can't/ serve static content at any speed as they block their main thread. Node and nginx use the same model for io, as does Tornado and Eventmachine (though the latter two are nowhere near as popular).
- jamiesonbecker 12y ago
  Separating your TLS server from your app server also shields your app server from leaks in your TLS server. See: Heartbleed.
  - je42 12y ago
    True, however the higher the number of different software packages that participate in your application's operational environment, the higher the chances that one of these exposes security holes. You have to make a trade-off between complexity and increasing security by isolating pieces of your stack.
- realityking 12y ago
  You can at least configure some basic sanitizations, so you'r app doesn't have to deal with them. Examples of the top of my head, are normalizing slashes and removing invalid headers. Whether that's worth it is another question.