Security – secure cookies when https is done on balancer, but balancer->appserver is http

cookiehaproxyhttpsSecurity

We're trying to maintain PCI compliance for our application and after an audit, the report was telling us that we need to set the secure flag on our cookies. The site is HTTPS (using pound for https termination) sitting in front of haproxy which serves to a number of backened appservers, as follows:

CLIENT ->(https)-> [Pound]->[HAProxy] ->(http)-> { app001 | app002 | appNNN }

I've done some research (googling) around but haven't been able to find anything definitive about this, but would there be any issue with an appserver setting a secure cookie over http between it and the balancer, and would it make it through to the client over https?

Our staging environment doesn't have SSL set up the same way as production so I'm unable to test this, but I'm trying to come up with a plan of action and see if there's anything I'm missing before we try to move forward with this.

Best Answer

You can set the secure flag on a cookie regardless of whether the connection made to the origin server was secured or not. The client interprets this flag, and won't actually set the cookie if the connection wasn't secured.

According to RFC 6265:

When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).

See RFC 6265 for more on how this flag works (and cookies in general).

Correct way in new versions of nginx

Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls

I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;
       # add Strict-Transport-Security to prevent man in the middle attacks
       add_header Strict-Transport-Security "max-age=31536000" always; 

       [....]
}

Security – Our security auditor is an idiot. How to give him the information he wants

First, DON'T capitulate. He is not only an idiot but DANGEROUSLY wrong. In fact, releasing this information would violate the PCI standard (which is what I'm assuming the audit is for since it's a payment processor) along with every other standard out there and just plain common sense. It would also expose your company to all sorts of liabilities.

The next thing I would do is send an email to your boss saying he needs to get corporate counsel involved to determine the legal exposure the company would be facing by proceeding with this action.

This last bit is up to you, but I would contact VISA with this information and get his PCI auditor status pulled.

Best Answer

Related Solutions

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

Security – Our security auditor is an idiot. How to give him the information he wants

Related Topic