O firefox tenta abrir o subdomínio http como https [configuração nginx]

4

Eu tenho domain.com e sub.domain.com configurados em nginx. domain.com tem certificado ssl, enquanto sub.domain.com não tem. sempre que eu tento abrir link em qualquer navegador moderno (firefox, chrome mesmo no navegador limpo sem plugins) ele me redireciona para link e me dá um erro, pois meu certificado ssl é apenas para domain.com.

No entanto, o wget não me redireciona:

 $ wget -O /dev/null http://sub.domain.com         
--2014-08-15 09:49:00--  http://sub.domain.com/
Resolving sub.domain.com (sub.domain.com)... X.X.X.X
Connecting to sub.domain.com (sub.domain.com)|X.X.X.X|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/dev/null’
2014-08-15 09:49:00 (1.23 MB/s) - ‘/dev/null’ saved [15807]

Aqui está a configuração do nginx para domain.com

server {
       # Redirect all http to https
       listen         X.X.X.X:80;
       server_name    ^domain.com www.domain.com;
       rewrite        ^ https://www.domain.com$request_uri? permanent;
}

server {
        ## Redirect https no-www to www for domain.com only
        listen               X.X.X.X:443 ssl;

        # Note ssl-bundle should contain only domain.com & root certificate
        ssl_certificate      /home/domain/ssl/www_domain.com.bundle;
        ssl_certificate_key  /home/domain/ssl/domain.com.key;

        ### Need to change that to avoid SSL Beast
        ssl_protocols              SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers  on;
        ssl_ciphers                "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK";

        ### Need to add this to enable HTTP Strict-Transport-Security
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
        server_name          ^domain.com;
        rewrite              ^ https://www.domain.com$request_uri? permanent;
}


server {
       ### Main section
       listen X.X.X.X:443 ssl;
       server_name                www.domain.com;
       server_tokens              off;

       ssl_certificate      /home/domain/ssl/www_domain.com.bundle;
       ssl_certificate_key  /home/domain/ssl/domain.com.key;
       ### Need to change that to avoid SSL Beast
       ssl_protocols              SSLv3 TLSv1 TLSv1.1 TLSv1.2;
       ssl_prefer_server_ciphers  on;
       ssl_ciphers                "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK";

        ### OCSP will be enabled only after nginx v1.3.5, so let's wait until it becomes the stable version 
        ### ( 1.6 is already in testing )
        # enable ocsp stapling (mechanism by which a site can convey certificate revocation information to visitors in a privacy-preserving, scalable manner)
        # http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
        #resolver 8.8.8.8;
        #ssl_stapling on;
        #ssl_trusted_certificate /home/domain/certs/ssl-bundle.crt;

        ### Need to add this to enable HTTP Strict-Transport-Security
        ###
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
        add_header X-Frame-Options SAMEORIGIN;

        root /home/domain/www/domain.com;
        index index.php index.html index.htm;


        location /promo/ {
            proxy_set_header   Host             $host;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_pass         http://127.0.0.1:10001;
            proxy_redirect     off;
    }

    location ^~ /s/promo/static/ {
            disable_symlinks off;
            expires 1y;
            root /home/domain/www/promo-static ;
            log_not_found off;
    }


    location / {
          <.various rules.>
    }
}

E aqui está a configuração para sub.domain.com:

server {
        listen X.X.X.X:80;
        server_name sub.domain.com ;

        # Serve media and static with nginx
        location ^~ /media/ {
                root /home/domain/www/sub_domain_com/project/;
                access_log off;
        }

        location ^~ /static/ {
                root /home/domain/www/sub_domain_com/project/;
                access_log off;
        }

        # Proxy redirect to django
        location / {
                proxy_read_timeout 1200;
                proxy_set_header   Host             $host;
                proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
                proxy_set_header   X-Real-IP        $remote_addr;
                proxy_pass         http://127.0.0.1:10001;
                proxy_redirect     off;
        }
}

Estou sem ideias de como parar o redirecionamento http para https para sub.domain.com.

Mais uma coisa estranha: se eu remover completamente a seção do redirecionamento http domain.com para https domain.com, o wget retornará HTTP request sent, awaiting response... No data received. no link mas o firefox e o chrome manterão a versão https aberta quando eu digitar o link ! o que há de errado com esses navegadores e como eu preciso configurar o nginx para parar esse comportamento?

    
por rush 15.08.2014 / 08:02

1 resposta

12

Isso é o que a pretende fazer. Depois que um navegador visitar a versão https de um site e receber o cabeçalho de HSTS de volta, ele sempre solicitará a versão https até a data de expiração, que no seu caso é de um ano.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

E como você tem includeSubDomains , os subdomínios estão incluídos.

Para desativar o HSTS, altere a idade máxima para 1, solicite a versão https novamente para armazenar em cache o novo cabeçalho, aguarde um segundo e tente a versão http.

Ou você pode simplesmente remover includeSubDomains e solicitar novamente a versão https para armazenar em cache o cabeçalho.

    
por 15.08.2014 / 08:36

Tags