Centos7学习笔记（二十二）- HTTPS

一、http劫持原理

首先通过dns污染，将访问的目标服务器，解析到问题服务器。问题服务器上，做nginx代理，利用sub_filter模块，可以匹配并替换原目标服务器上的部分（或全部）内容，以达到广告发布、挂马等目的。

最好的防范措施是hosts直接解析，防止污染。

二、https原理

http原理具体来说，是很复杂的。这里仅简单描述一下它的大致流程——

网站服务器先通过向“登记机构”发起“证书签名申请”（CSR），CA机构在获取CSR后，确认无误，将证书颁发给网站服务器，其证书还包括公钥和私钥内容。网站在获取CA颁发的证书后，需要在自身部署好证书验证内容（nginx配置）。

当浏览器发起访问时，它又会经过一系列复杂的验证过程，其中，关于如何验证证书合法性，它通过3方面来验证：

1. 验证证书是否在有效期内。

　　在服务端面返回的证书中会包含证书的有效期，可以通过失效日期来验证证书是否过期

2. 验证证书是否被吊销了。

　　被吊销后的证书是无效的。验证吊销有CRL(证书吊销列表)和OCSP(在线证书检查)两种方法。

证书被吊销后会被记录在CRL中，CA会定期发布CRL。应用程序可以依靠CRL来检查证书是否被吊销了。

CRL有两个缺点，一是有可能会很大，下载很麻烦。针对这种情况有增量CRL这种方案。二是有滞后性，就算证书被吊销了，应用也只能等到发布最新的CRL后才能知道。

增量CRL也能解决一部分问题，但没有彻底解决。OCSP是在线证书状态检查协议。应用按照标准发送一个请求，对某张证书进行查询，之后服务器返回证书状态。

OCSP可以认为是即时的（实际实现中可能会有一定延迟），所以没有CRL的缺点。

3. 验证证书是否是上级CA签发的。

windows中保留了所有受信任的根证书，浏览器可以查看信任的根证书，自然可以验证web服务器的证书，

是不是由这些受信任根证书颁发的或者受信任根证书的二级证书机构颁发的（根证书机构可能会受权给底下的中级证书机构，然后由中级证书机构颁发中级证书）

在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信

三、https证书类型及证书的颁发

https证书无非三种：

DV（个人用或者测试用，多为免费，多为仅对单一域名有效）

OV（企业用，可根据情况申请单一域名、多域名或者通配符域名（*.example.com）证书）

EV（增强型OV证书，一般用于大型公司、金融公司、政府机构）

证书也是可以自签发的，流程如下：

a、生成CA根证书

openssl genrsa -des3 -out myCA.key 2048    #www
openssl req -x509 -new -key myCA.key -sha256 -days 36000 -out myCA.pem

b、生成服务器私钥和证书请求

openssl genrsa -out www.xyz.key 2048

openssl req -new -key www.xyz.key -out www.xyz.csr

c、签发服务器证书

openssl x509 -req -in www.xyz.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial \
-out www.xyz.crt -days 36000 -sha256

d、查看服务器私钥及证书

openssl rsa -noout -text -in www.xyz.key     #查看私钥
openssl req -noout -text -in www.xyz.csr      #查看证书请求文件
openssl x509 -noout -text -in www.xyz.crt     #查看CA证书

e、服务器导入CA根证书

yum install -y ca-certificates
cp myCA.pem /usr/local/share/ca-certificates/myCA.crt
update-ca-certificates

四、证书在nginx中的部署

涉及三个指令：

Syntax: ssl on | off;
Default: ssl off;
context: http, server

Syntax: ssl_certificate  file;
Default: - ;
context: http, server

Syntax: ssl_certificate_key keyfile;
Default: - ;
context: http, server

单站点https配置示例：

server
{
    listen 80;
    server_name www.hcrbbs.top;
    rewrite ^(.*) https://$server_name$1 redirect;
}
server
{
    listen 443;
    server_name www.hcrbbs.top;
    root /www/html/;
    index index.php;
    ssl on;
    ssl_certificate /etc/nginx/cert/5370791_www.hcrbbs.top.pem; ### 证书换成你的
    ssl_certificate_key /etc/nginx/cert/5370791_www.hcrbbs.top.key; ### 证书换成你的
    location / {
        ....
    }
}

带有负载均衡的配置示例：

后端：

server
{
    listen 80;                                                《=========后端不需要配置ssl
    server_name www.hcrbbs.top;   
    root /www/html/;
    index index.php;
    location / {
        ....
    }
}

负载均衡LB上：

upstream website {
    server    172.16.1.17:80;
    server    172.16.1.18:80;
    server    172.16.1.19:80;
    server    172.16.1.20:80;
}
server {
    listen 443;                        《==============前端负载均衡监听443，开启ssl即可
    server_name    www.hcrbbs.top; 
    ssl    on;
    ssl_certificate    cert/5370791_www.hcrbbs.top.pem; 
    ssl_certificate_key /etc/nginx/cert/5370791_www.hcrbbs.top.key;
    location / {
        proxy_pass    http://website;
        proxy_set_header HOST    $http_host;
    }
}
server {
    listen 80;
    server_name     www.hcrbbs.top; 
    retunr 302 https://$server_name$request_uri;
}

下面贴上一个完整的前端四层负载均衡做端口转发，七层负载均衡做https，后端web集群仍然配置http的示例配置：

前端四层做端口转发及七层负载均衡：

stream {
        log_format      proxy   '$remote_addr&nbsp;-&nbsp;$remote_port - [$time_local]&nbsp;-&nbsp;$server_addr - $server_port&nbsp;&nbsp;$protocol '
                                 '"$status&quot;&nbsp;&quot;$bytes_received" "$upstream_addr&quot;&nbsp;&quot;$upstream_bytes_sent"';
        access_log      /var/log/nginx/proxy.log  proxy;
        upstream lb {
                server 172.16.1.5:443;
                server 172.16.1.6:443;
        }
        server {
                listen 80;
                proxy_connect_timeout 3s;
                proxy_pass      lb;
        }
        server {
                listen 443;
                proxy_connect_timeout 3s;
                proxy_pass      lb;
        }
}

七层负载均衡做https，80端口跳转https：

upstream  testweb {
        server  172.16.1.17:80;
        server  172.16.1.18:80;
        server  172.16.1.19:80;
        server  172.16.1.20:80;
        check interval=3000    rise=2    fall=3    timeout=1000    type=tcp;
        }
server {
        listen 80;
        server_name     test.hcrbbs.top;
        rewrite ^(.*)   https://$server_name$1  redirect;
        #return 302     https://$server_name$request_uri;
}
server {
        listen  443 ssl;
        server_name     test.hcrbbs.top;
        ssl_certificate cert/test.hcrbbs.top.crt;
        ssl_certificate_key     cert/test.hcrbbs.top.key;
        location / {
                proxy_pass      http://testweb;
                include proxy_params;
                proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
                }
         location  /status {
                check_status;
                access_log off;
                allow 10.0.0.0/24;
                deny all;
                }
        }

后端web集群其一机器的配置：

server {
        listen 80;
        server_name test.hcrbbs.top;
        root /www/html;
        client_max_body_size    200m;
        location / {
                index    index.php;
        }
        location ~ .*.php$ {
                fastcgi_pass    127.0.0.1:9000;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param   HTTPS   on;            《============这里，需要php-fpm开启https传输识别，php才能正常工作。这点尤为重要。
                include fastcgi_params;
        }
}

PS:上面的"fastcgi_param HTTPS on;"，最好替换为“fastcgi_param HTTPS $https if_not_empty;”

五、nginx中SSL的优化

为何要优化？

网站启用https后，会加剧服务器的负担。每次新的TLS连续都需要握手，以便创建共享的加密密钥，在TCP三次握手之上还需要两个来回。传统的http使用TCP三次握手建立连接，而SSL和TLS在这个基础上还需要9个握手包，所以这个负担显而易见。不过，通过重用Session提高https的性能，TLS有几个特点可以抵消额外的握手：重用一个Session。有两个标准会话重用机制：session IDs (RFC 5246) 和 session tickets (RFC 5077)，使用其中一个技术，一个客户端可以重用之前创建的会话，这个会话是之前和服务器进行握手成功的，这样可以减少一次来回过程。基于SessionID的会话重用适合现代所有浏览器，FireFox和Chrome甚至还支持 session tickets。

Nginx之ssl_session_cache详解：

Syntax:ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
Default:ssl_session_cache none;
Context:http, server

参数解释：
设置存储session参数的缓存的类型和大小。缓存可以是以下任何一种类型：
off
严禁使用session缓存：nginx明确告诉客户端session可能不会被重用。
none
session缓存的使用被禁止：nginx告诉客户端session可能会被重用，但实际上并不会将session参数存储在缓存中。
builtin
在OpenSSL中构建的缓存；仅由一个工作进程使用。缓存大小在session中指定。如果没有给出大小，则等于20480个会话。使用内置高速缓存可能导致内存碎片。
shared
所有工作进程之间共享缓存。缓存大小以字节为单位指定；一兆字节可以存储大约4000个session。每个共享缓存都应该有一个任意名称。具有相同名称的缓存可以用于多个虚拟服务器。

两种类型的缓存可以同时使用：配置案例:
ssl_session_cache builtin:1000 shared:SSL:10m;
但是只使用shared缓存，而不使用built-in缓存性能应该会更高。

目前使用较多的配置是built-in和shared同时使用：ssl_session_cache builtin:1000 shared:SSL:10m;但是Nginx官方说只使用shared，性能会更高，配置方法为：ssl_session_cache shared:SSL:10m;

Nginx之ssl_session_timeout详解：

Syntax:ssl_session_timeout time;

Default:ssl_session_timeout 5m;

Context: http server

中文解释：指定客户端可以重用会话参数的时间（超时之后不可使用）

Nginx之ssl_prefer_server_ciphers详解：

ssl_prefer_server_ciphers on|off 作用：是否由服务器决定采用哪种加密算法，默认是off。

如果ssl协议支持tlsv1 tls1.1这种老协议，设置为 on ，并配合ssl_ciphers使用

如果ssl协议只支持tlsv1.2 tlsv1.3新协议，设置为 off （nginx默认为off），因为新协议不再采纳此参数

Nginx之ssl_protocols详解：

指定ssl所使用的协议版本。具体见后文示例。

Nginx之ssl_ciphers详解：

指定上述ssl_protocols指定协议所使用的加密算法。配合ssl_protocols和ssl_perfer_server_ciphers使用。

OSCP Stapling

当我们通过HTTPS访问网站的时候，客户端会通过证书颁发机构的证书吊销列表（CRL）或者数字证书在线状态协议(OCSP)记录验证网站服务器的证书是否有效。前一种验证方式是最低效的，CA会不断向CRL文件添加证书吊销记录，CRL文件就会变得越来越大，客户端在验证前就需要耗费越来越长的时间来下载CRL文件。

相比 CRL 验证方式，OCSP 就更加高效，OCSP 每次只查询并获取一条记录。然而这些默认查询 OCSP 的客户端在获得查询结果的响应前势必会一直阻塞后续的事件，在网络情况堪忧的情况下（尤其是大陆地区）会造成较长时间的页面空白。并且一旦有黑客或者组织对CA的OCSP发动DDos攻击，客户端便无法从 OCSP 服务器获取查询结果并完成证书验证, 客户端就可能会提示网站不受信任。

而 OCSP Stapling ，顾名思义，是将查询 OCSP 接口的工作交给服务器来做，服务器除了可以直接查询 OCSP 信息，还可以仅进行少数次查询并将响应缓存起来。当有客户端向服务器发起 TLS 握手请求时，服务器将证书的 OCSP 信息随证书链一同发送给客户端，从而避免了客户端验证会产生的阻塞问题。由于 OCSP 响应是无法伪造的，因此这一过程也不会产生额外的安全问题。

值得注意的是：Nginx会在客户端的HELLO握手信息中返回OCSP记录，并且只有当客户端对Nginx发出OCSP信息请求的情况下，Nginx才会发送缓存的OCSP 权威记录到客户端。

ssl_stapling on;
# OCSP Stapling 开启。OCSP是用于在线查询证书吊销情况的服务，使用OCSP Stapling能将证书有效状态的信息缓存到服务器，提高 TLS 握手速度
ssl_stapling_verify on;
# OCSP Stapling 验证开启
ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;

# OCSP Stapling 的证书位置（完整的证书链）
resolver 233.5.5.5 233.6.6.6 valid=300s;
# 用于查询 OCSP 服务器的DNS
resolver_timeout 5s;
#查询域名超时时间

注意上述 DNS 是阿里云的，如果不信任的话可以改成 Google 的：8.8.8.8 8.8.4.4 [2001:4860:4860::8888] [2001:4860:4860::8844]

根据以上SSL优化的相关指令，在mozilla wiki中推荐了三种配置，分别是最新配置、中等兼容（默认）和旧的向后兼容性。。具体见下：

A、最新配置

对于具有支持 TLS 1.3 且不需要向后兼容的客户端服务，最新配置提供了极高级别的安全性。

# generated 2021-06-22, Mozilla Guideline v5.6, nginx 1.17.7, OpenSSL 1.1.1d, modern configuration

B、中等兼容（默认）

对于不需要与旧客户端兼容的服务，例如 Windows XP 或旧版本的 OpenSSL。这是绝大多数服务的推荐配置，因为它高度安全并且与过去五年（或更长时间）发布的几乎所有客户端兼容。

# generated 2021-06-22, Mozilla Guideline v5.6, nginx 1.17.7, OpenSSL 1.1.1d, intermediate configuration

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;

    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt ;> /path/to/dhparam
    ssl_dhparam /path/to/dhparam;

    # intermediate configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS (ngx_http_headers_module is required) (63072000 seconds)
    add_header Strict-Transport-Security "max-age=63072000" always;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    # replace with the IP address of your resolver
    resolver 127.0.0.1;
}

C、旧的向后兼容性

与许多非常老的客户端兼容，只能作为最后的手段使用。

# generated 2021-06-22, Mozilla Guideline v5.6, nginx 1.17.7, OpenSSL 1.1.1d, old configuration

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;

    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # openssl dhparam 1024 > /path/to/dhparam
    ssl_dhparam /path/to/dhparam;

    # old configuration
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (63072000 seconds)
    add_header Strict-Transport-Security "max-age=63072000" always;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    # replace with the IP address of your resolver
    resolver 127.0.0.1;
}

防止 MIME 类型混淆攻击

add_header X-Content-Type-Options nosniff;

HSTS（HTTP Strict Transport Security，严格传输安全）

HSTS 简单说就是在一定时间内强制客户端使用 HTTPS 访问页面。原理如下：

在服务器响应头中添加 Strict-Transport-Security，可以设置 max-age

用户访问时，服务器种下这个头

下次如果使用 HTTP 访问，只要 max-age 未过期，客户端会进行内部跳转，可以看到 307 Redirect Internel 的响应码（注意是客户端浏览器相应的，这里给服务器省下了一次 302 跳转）

变成 HTTPS 访问源服务器

这个过程有效避免了中间人对 80 端口的劫持。但是这里存在一个问题：如果用户在劫持状态，并且没有访问过源服务器，那么源服务器是没有办法给客户端种下 Strict-Transport-Security 响应头的（都被中间人挡下来了）。如何解决？请自行谷歌 HSTS preload。

需要注意的是，只有启用 preload 之后才是严格意义上安全的 HTTPS。否则都可能在最薄弱环节被攻破。比如：

允许 SSL 连接但不强制从 HTTP 跳转到 HTTPS，用户访问 HTTP 被劫持

部署了 HSTS，但用户第一次访问是 HTTP 的，Strict-Transport-Security 的响应头没有作用的机会，还是被劫持

不过，即使你启用了 preload 也不是 100% 高枕无忧了，一旦客户端被恶意软件安装了恶意的根证书，这些措施就都没有用了。所以不要轻易安装根证书，不要随意安装可疑软件（尤其在 Windows 上）。比如，Google 曾在2015 年报告说 CNNIC （中国互联网络信息中心）签发的一个中级 CA 签发了一个伪造的 Google 证书，从而导致 Google 和 Mozilla 在其产品中取消了对 CNNIC 后继签发的证书信任。

如何解决呢？请看后文的 DNS CAA。

开启 HSTS

add_header Strict-Transport-Security "max-age=6307200; includeSubdomains; preload";

以上语句开启了 HSTS，并设置有效期为“6307200秒”（6个月），包括子域名(根据情况可删掉)，预加载到浏览器缓存(根据情况可删掉，注意加入后需要向 hstspreload.org 提交申请)。

注意如果要申请preload，所有子域名都必须使用 HTTPS，且max-age至少设置为一年。有关preload的更多信息可以前往上述网址查看。

提醒一下，只有443端口的监听需要设定 HSTS，80端口不需要增加 header。

DNS CAA 保护

DNS CAA 保护可以使域持有人可以指定允许为其域签发证书的 CA。它会在 DNS 下发 IP 的同时，同时下发一条资源记录，标记该域名下使用的证书必须由某证书颁发机构颁发。比如本站使用了 Let’s Encrypt 颁发的免费证书，我可以同时使用 CAA 技术标记本站使用的 SSL 证书必须由 Let’s Encrypt 颁发，这样就可以（在一定程度上）解决上面所述的问题。

并不是所有 DNS 服务器都支持 CAA 保护，支持 CAA 记录的国外 DNS 服务这里有比较详细的记录：https://sslmate.com/caa/support 。国内的话， CloudXNS 是支持的。

开启方法

在你的 DNS 服务的后台添加一条 CAA 记录：

Name 可以直接填写顶级域名，会自动应用到多级域名

CAA data 填写 0 issue "证书颁发机构域名"，如果你用 Let’s Encrypt 颁发的免费证书，CAA data 部分直接填写 0 issue "letsencrypt.org" 即可。

你还可以添加一条为 0 iodef "mailto:你的邮箱" 的 CAA 记录，表示如果发现违背 CAA 记录的情况给这个邮箱发邮件通知

 

Ivker的私人blog