SSL-enabled sites through Cloudflare

Plone Support Administering Plone sites
, ,
1

yesterday I was able to deploy a site using SSL; I'm still having some issues redirecting the standard traffic but is kind of working.

this is a streamline version of the configuration I used:

upstream varnish {
    server example1:6081;
    server example2:6081;
}

server {
    listen 80;
    server_name example.org;
    return 301 https://www.example.orgr$request_uri;
}

server {
    listen 80;
    listen 443 ssl;

    ssl_certificate /etc/nginx/ssl/example.org.pem;
    ssl_certificate_key /etc/nginx/ssl/example.org.key;

    server_name www.example.org;

    location / {
        proxy_pass http://varnish/VirtualHostBase/https/www.example.org:443/Plone/VirtualHostRoot/;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_ignore_headers Expires;
    }
}

I still need to redirect all traffic from http://www.example.org to https://www.example.org also.

I think I can fix that using:

server {
    listen 80;
    server_name example.org www.example.org;
    return 301 https://www.example.orgr$request_uri;
}

and removing the listen 80; from the second server directive, but I still need to test it.

CPU usage is a little bit higer but not too much; I still need to tweak the ngx_http_ssl_module and set the ssl_session_cache directive.

but my question here has to be more with Cloudflare configuration.

are you guys using your SSL-enabled sites behind Cloudflare? how do you configure it?

any other best practices on SSL-enabled sites?

2

You can also use cloudflare page rules to do http:// -> https://

1 Like
3

Yes, that's one big reason to use CF: free configuration-free SSL certs, even easier than letsencrypt (which didn't work for older distros).

I set CF to use "full" SSL enforcement (not "full (strict)").

4

Here's something I use...(It may not be perfect!)

# This adds security headers
add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'";

server {
    listen 80;
    server_name sub.domain.com;
    location ~* sendto_form {
             return 404;
    }
    location ~* php {
             return 404;
    }
    location ~ && {
             return 404;
    }
    location ~ join_form {
             return 404;
    }
    location / {
        rewrite ^ https://$server_name$request_uri permanent;
    }
    client_max_body_size 10M;
}

server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/localcerts/sub.domain.com.crt;
    ssl_certificate_key /etc/ssl/localcerts/sub.domain.com.key;
    server_name sub.domain.com;
    access_log /var/log/nginx/sub.domain.com.access.log;
    error_log /var/log/nginx/sub.domain.com.error.log;

    # Note that domain name spelling in VirtualHostBase URL matters
    # -> this is what Plone sees as the "real" HTTP request URL.
    # "Plone" in the URL is your site id (case sensitive)
    location ~* server-status {
             return 404;
             access_log off;
    }
    location ~* sendto_form {
             return 404;
             access_log off;
    }
    location ~* php {
             return 404;
             access_log off;
    }
    location ~ && {
             return 404;
             access_log off;
    }
    location ~ join_form {
             return 404;
             access_log off;
    }
    location / {
        rewrite ^/(.*)$ /VirtualHostBase/https/sub.domain.com:443/MySite/VirtualHostRoot/$1 break;
        #
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    client_max_body_size 10M;
}
5

@vangheem are we vulnerable to the Breach Attack or our CSRF protection mitigates that?

seems Cloudflare has taken some steps to mitigate it, but I want to be sure if I need to disable GZip compression (something I really don't want) or do anything else to protect this site.

6

What do you mean by "are we vulnerable"?

Do you mean is Plone, cloudflare, nginx or what? The reason I ask is because security is more than just at the web application layer...

The BREACH attack is exploited based on a combination of factors so it all depends on your deployment. The major weakpoint here is http compression algorithms.

Theoretically, Plone should not be vulnerable because we use a keyring of 5 randomized keys when issue tokens with secrets.

That being said, I've never done or heard of anyone that tested Plone against a BREACH style attack. For a Plone attack, the attacker would need to have an account on the target Plone site so that Plone will distribute the CSRF keys to the user. Then, I'm not sure how they get around the random keys used that plone employs.

I'm not sure if any of the things cloudflare has listed there actually fight against BREACH even though they claim it does. Everything they talk about is related to SSL compression.

In any case, if you're very nervous about the attack, you can disable compression just on text/html responses.

7

thank you! that's all I wanted to know.

sure, that's what I though.

8

meh, nevermind, I'm reading BREACH again and it is in fact related to SSL compression as well so cloudflare's mods probably do help.

1 Like
9

that header makes the trick; according to RFC 6797 on HTTP Strict Transport Security Policy Effects:

The effects of the HSTS Policy, as applied by a conformant HTTP user agent (UA) in interactions with a web resource host wielding such policy (known as an HSTS Host), are summarized as follows:

  1. UAs transform insecure URI references to an HSTS Host into secure URI references before dereferencing them.
  2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings.

I added also the ssl_session_cache directive as, according to nginx documentation on Configuring HTTPS servers:

The most CPU-intensive operation is the SSL handshake. There are two ways to minimize the number of these operations per client: the first is by enabling keepalive connections to send several requests via one connection and the second is to reuse SSL session parameters to avoid SSL handshakes for parallel and subsequent connections.

but, at least for me, it had no effect at all: nginx is using only around 1% CPU and that was mostly unchanged after that.

1 Like