Не разрешать небезопасные соединения на nginx - PullRequest
0 голосов
/ 03 июля 2018

Я установил сертификат certbot для nginx:

sudo certbot --nginx -d example.com

и перенаправьте все http на https:

# Redirect non-https traffic to https
if ($scheme != "https") {
    return 301 https://$host$request_uri;
} # managed by Certbot

Он работает из браузера, но я все еще могу установить небезопасное соединение через

curl --insecure example.com

Вот основные конфигурации в nginx.conf:

server {
  listen 80;
  server_name example.com;
  if ($scheme != "https") {
     return 301 https://$host$request_uri;
  }
  location / {
    root /www/html/;
    ...
    proxy_pass http://127.0.0.1:80;
  } 
  listen 443 ssl; # managed by Certbot
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by 
 Certbot
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed 
  by Certbot
  include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
  proxy_ssl_trusted_certificate /etc/letsencrypt/live/example.com/cert.pem;
  proxy_ssl_verify on;
  proxy_ssl_verify_depth 2;
}

Когда я выпускаю curl -iI https://example.com, возвращает:

HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 04 Jul 2018 09:19:35 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1218
Connection: keep-alive
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Tue, 01 Jul 2018 12:10:25 GMT
ETag: W/"Zwtf1TTMBhoSbg9LZvHbCg=="
Strict-Transport-Security: max-age=31536000; includeSubDomains

1 Ответ

0 голосов
/ 03 июля 2018

должно возвращаться HTTP/1.1 301 Moved Permanently, в котором пользовательский агент может или не может перенаправить на новое место.

используйте -L или --location в вашей команде curl для автоматического следования перенаправлениям.

Изменить 2018-07-05:

Вот основные конфигурации в nginx.conf:

Хотя это не плохая конфигурация, использование директивы if не рекомендуется . Вам лучше разбить конфигурацию на два отдельных блока server, один для http, а другой для https.

Что-то вроде:

server {
    listen 80;
    server_name example.com;

    # log your http request if you need to
    error_log /var/log/nginx/example-com_error.log notice;
    access_log /var/log/nginx/example-com_access.log combined;

    # certbot endpoint
    location ~ ^/\.well-known/ {
        root /var/www/certbot/;
        access_log off;
    }

    # other requests should end up here
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name example.com;

    # log your http request if you need to
    error_log /var/log/nginx/example-com_error.log notice;
    access_log /var/log/nginx/example-com_access.log combined;

    # default document root and document index
    root /var/www/html;
    index index.html;

    # SSL cert, private key, and configurations.
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # https configurations
    location / {
        proxy_pass http://127.0.0.1:80; # why would you proxy_pass back to nginx again?

        # you only need this if your proxy_pass uses https, not http like this example.
        proxy_ssl_trusted_certificate /etc/letsencrypt/live/example.com/cert.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 2;
    }
}

должно хватить.

Когда я запускаю curl -iI https://example.com,, возвращается:

да, почему бы не вернуть HTTP/1.1 200 OK?

Небезопасная часть флага --insecure только в cURL отключает проверку сертификата HTTPS , то есть вы можете использовать недопустимый сертификат SSL в запросе HTTPS (плохой CN, плохой SAN, неправильный срок действия, плохой CA, самоподписанный и т. д.) и cURL все равно удовлетворит ваш запрос, вместо того, чтобы терпеть неудачу.

...