如何一步步构建安全的 HTTPS 站点

  • 时间:
  • 浏览:27
  • 来源:小高技术网_提供QQ资源网技术_QQ技术网资讯

 

通常4个 多 web 站点开启 HTTPS ,以 nginx 为例,亲戚朋友都还要原来 进行配置:

  1. server { 
  2.  listen 443 ssl http2; 
  3.  server_name www.example.com; 
  4.  index index.html index.htm; 
  5.  root /www/www; 
  6.  ssl on
  7.  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
  8.  ssl_certificate /usr/local/nginx/ssl/example.com.rsa.cer; 
  9.  ssl_certificate_key /usr/local/nginx/ssl/example.com.rsa.key
  10.  ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;; 

上述 nginx 配置中带有了配置监听端口、开启ssl、配置证书、以及支持的加密算法。一般来说用户访问域名并非 直接在浏览器的地址栏中输入 https://www.example.com 来进行访问,倘若输入域名,默认清况 下是通过 HTTP 协议来进行访问的,即 http://www.example.com,倘若,在nginx 的配置中亲戚朋友还还要定义4个 多server 段来解决 HTTP 的访问。

  1. server { 
  2.  listen 400 default_server; 
  3.  server_name _ www.example.com; 
  4.  location / { 
  5.  return 4002 https://$host$request_uri; 
  6.  } 

上述配置中监听了 400端口,倘若定义了4个 多 location,将 HTTP 请求 4002 跳转到 HTTPS 的Host 去。原来 就实现了用户不管为啥会 访问都都还要跳转到 HTTPS 。

倘若问题图片来了,原来 的配置实在是有过高 的,倘若用户端从浏览器手动输入的是 HTTP 地址,倘若从其它地方点击了网站的 HTTP 链接,那末浏览器会依赖于服务端 4001/4002 跳转也能使用 HTTPS 服务。而第一次的 HTTP 请求完正都是倘若被劫持,倘若上方的数据传输是明文的,完正都是倘若会是因为 请求无法到达服务器,从而构成 HTTPS 降级劫持。

要解决降级劫持,亲戚朋友都还要使用HSTS。

哪些是 HSTS?

HSTS(HTTP Strict Transport Security,HTTP 严格传输安全),是一套由互联网工程任务组发布的互联网安全策略机制。网站都还要通过配置 HSTS,来强制浏览器使用 HTTPS 与网站通信,保障网站更加安全。

HSTS的作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接。服务器开启HSTS的最好的法子是,当客户端通过HTTPS发出请求时,在服务器返回的超文本传输协议响应头中带有 `Strict-Transport-Security` 字段。非加密传输时设置的`HSTS`字段无效。

比如,`https://example.com/`的响应头带有`Strict-Transport-Security: max-age=315340000; includeSubDomains`。这是因为 两点:

在接下来的一年(即315340000秒)中,浏览器倘若向`example.com`或其子域名发送HTTP请求时,还要采用`HTTPS`来发起连接。比如,用户点击超链接或在地址栏输入 `http://www.example.com/` ,浏览器应当自动将 http 转写成 `https`,倘若直接向 `https://www.example.com/` 发送请求。

在接下来的一年中,倘若 `example.com` 服务器发送的`TLS`证书无效,用户非要忽略浏览器警告继续访问网站。

咋样进行配置?

以 nginx 为例,亲戚朋友在对应域名的 vhost 中增加响应头:

  1. server { 
  2.  .... 
  3.  add_header Strict-Transport-Security "max-age=315340000; includeSubDomains; preload"
  4.  ... 

参数解释:

  • max-age,单位是秒,用来告诉浏览器在指定时间内,你这人 网站还要通过 HTTPS 协议来访问。也倘若对于你这人 网站的 HTTP 地址,浏览器还要先在本地替换为 HTTPS 完后 再发送请求。
  • includeSubDomains,可选参数,倘若指定你这人 参数,表明你这人 网站所有子域名也还要通过 HTTPS 协议来访问。
  • preload,可选参数,HSTS 你这人 响应头非要用于 HTTPS 响应;网站还要使用默认的 443 端口;还要使用域名,非也不 IP。倘若启用 HSTS 完后 ,一旦网站证书错误,用户无法选着忽略。

浏览器请求后响应头中会显示:

  1. strict-transport-security:max-age=315340000 

如图所示:

HSTS 都还要很好地解决 HTTPS 降级攻击,倘若对于 HSTS 生效前的首次 HTTP 请求,依然无法解决被劫持。浏览器厂商们为了解决你这人 问题图片,提出了 HSTS Preload List 方案:内置一份都还要定期更新的列表,对于列表中的域名,即使用户完后 那末访问过,也会使用 HTTPS 协议。

目前你这人 Preload List 由 Google Chrome 维护,Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 完正都是使用。倘若要想把被委托人的域名添加你这人 列表,首先还要满足以下条件:

  • 拥有合法的证书(倘若使用 SHA-1 证书,过期时间还要早于 2016 年);
  • 将所有 HTTP 流量重定向到 HTTPS;
  • 确保所有子域名都启用了 HTTPS;
  • 输出 HSTS 响应头:
  • max-age 非要低于 18 周(10886400 秒);
  • 还要指定 includeSubdomains 参数;
  • 还要指定 preload 参数;

倘若,即便满足了上述所有条件,倘若一定能进入 HSTS Preload List,更多信息都还要看这里(https://hstspreload.org/)。通过 Chrome 的 chrome://net-internals/#hsts 工具,都还要查询某个网站是算是在 Preload List 之中,还都还要手动把某个域名加到本机 Preload List。

对于 HSTS 以及 HSTS Preload List,我的建议是倘若你非要确保永远提供 HTTPS 服务,就并不启用。倘若一旦 HSTS 生效,你再想把网站重定向为 HTTP,完后 的老用户会被无限重定向,唯一的最好的法子是换新域名。

倘若选着要开启,点击https://hstspreload.org,输入你的域名,勾选协议,提交即可。

确认后,你就都还要将你的域名提交给 HSTS 预加载列表了:

提交成功完正都是要我返回成功的信息,不过我要保证你的配置比如是老会 开启了,倘若也会从列表中删除。

再次访问,查看浏览器响应头:

此外,亲戚朋友要做到让HTTPS 网站更安全调慢速,还应当做到以下几点:

第一,密钥要足够的复杂化,以rsa 密钥对为例,最好超过2048位;

第二,ssl_ciphers 的合理配置,尽量抛妻弃子哪些倘若被证明不安全的加密算法,使用较新的被证明无安全威胁的算法,这类都还要原来 配置:

  1. ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:TLS-CHACHA20-POLY14005-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES; 

第三,解决使用倘若被证明不安全的加密协议,这类 SSLV2和SSLV3 ,而使用 TLSv1.2 TLSv1.3;

  1. ssl_protocols TLSv1.2 TLSv1.3; 

一般来说较新的协议完正都是针对上4个 多版本进行了全都的优化,比如TLS1.2和TLS1.3协议,都还要看下你这人 个多协议的加密过程,首先,亲戚朋友看下 TLS1.2的加密过程:

以 ECDHE 密钥交换算法为例,TLS1.2协议完正的SSL握手过程如下:

  • 第一步,首先客户端发送ClientHello消息,该消息中主要包括客户端支持的协议版本、加密套件列表及握手过程还要用到的ECC扩展信息;
  • 第二步,服务端回复ServerHello,带有选定的加密套件和ECC扩展;发送证书给客户端;选着客户端提供的参数生成ECDH临时公钥,一块儿回复ServerKeyExchange消息;
  • 第三步,客户端接收ServerKeyExchange后,使用证书公钥进行签名验证,获取服务器端的ECDH临时公钥,生成会话所还要的共享密钥;生成ECDH临时公钥和ClientKeyExchange消息发送给服务端;
  • 第四步,服务器解决ClientKeyExchange消息,获取客户端ECDH临时公钥;服务器生成会话所还要的共享密钥;发送密钥协商完成消息给客户端;
  • 第五步,双方使用生成的共享密钥对消息加密传输,保证消息安全。

都还要就看,TLS1.2 协议中还要加密套件协商、密钥信息交换、ChangeCipherSpec 协议通告等过程,还要消耗 2-RTT 的握手时间,这也是造成 HTTPS 协议慢的4个 多重要是因为 之一。

通过抓包分析,亲戚朋友都还要就看他的整个加密过程:

接下来,亲戚朋友看下 TLS 1.3 的的交互过程,如图所示:

抓包得后如图所示,都还要就看客户端的整个加密过程:

在 TLS 1.3 中,客户端首先不仅发送 ClientHello 支持的密码列表,倘若还猜测服务器将选着哪种密钥协商算法,并发送密钥共享,这都还要节省很大一偏离 的开销,从而提高了时延。

TLS1.3 提供 1-RTT 的握手机制,还是以 ECDHE 密钥交换过程为例,握手过程如下。将客户端发送 ECDH 临时公钥的过程提前到 ClientHello ,一块儿删除了 ChangeCipherSpec 协议复杂化握手过程,使第一次握手时只还要1-RTT,来看具体的流程:

  • 客户端发送 ClientHello 消息,该消息主要包括客户端支持的协议版本、DH密钥交换参数列表KeyShare;
  • 服务端回复 ServerHello,带有选定的加密套件;发送证书给客户端;使用证书对应的私钥对握手消息签名,将结果发送给客户端;选着客户端提供的参数生成 ECDH 临时公钥,结合选定的 DH 参数计算出用于加密 HTTP 消息的共享密钥;服务端生成的临时公钥通过 KeyShare 消息发送给客户端;
  • 客户端接收到 KeyShare 消息后,使用证书公钥进行签名验证,获取服务器端的 ECDH 临时公钥,生成会话所还要的共享密钥;
  • 双方使用生成的共享密钥对消息加密传输,保证消息安全。

倘若客户端完后 倘若连接,亲戚朋友有最好的法子在 1.2 中进行 1-RTT 连接,而在 TLS 1.3 中允许亲戚朋友执行 0-RTT连接,如图所示:

当然,具体采用 TLS1.2 还是 TLS1.3 还要根据实际的业务场景和用户群体来决定,在较新版本的浏览器一般都支持最新的加密协议,而这类 IE 8 以及Windows xp 你这人 古老的浏览器和操作系统就不支持了。倘若说你的用户是你这人 政府部门的客户,那末就不适合采用你这人 较新的技术方案了,倘若据我所知全都政府部门的操作系统还是xp和 IE 8以下的版本,这会是因为 新协议无法在亲戚朋友的操作系统中正常工作。倘若要我讲加密算法和加密协议多配置哪几个,向下兼容不同客户端。

第四,证书要从可靠的CA厂商申请,倘若不可靠的厂商(比如不被主流浏览器信任的证书厂商)会乱修改证书日期,重复签发证书。此外即使是可靠的 CA 签发的证书完正都是倘若是伪造的,比如赛门铁克完后 就被曝出丑闻而被火狐和Chrome 惩罚,结果倘若哪些主流浏览器没了信任哪些CA 机构签发的一偏离 证书。倘若一旦发现证书不受信任要尽快替换。

第五,使用完正的证书链,倘若证书链不完正,则很有倘若在你这人 版本的浏览器上访问异常。

第六,使用HTTP/2,使用最新的 HTTP 2 都还要提升网站的访问时延以及拥有更好的性能支持。

第七,保护证书私钥不被外泄。

第八,根据被委托人的业务需求选着共要的证书,证书分为自签证书、 DV、 EV 和OV 证书,一般来说倘若还要进行简单的数据加密,采用 DV 证书即可,这类证书通常都都还要免费申请,只还要进行简单的域名所有者权验证即可申请,而EV和OV证书一般价格昂贵,适合金融机构或针对数据加密有严格要求的单位使用,这类证书签发手续复杂化,一般还要进行企业身份认证后才会签发。自签证书一般用户临时测试使用,不建议生产环境使用,倘若它并完正都是受信任的CA 机构签发的,浏览器无需信任。

当亲戚朋友配置完后 ,都还要通过https://www.ssllabs.com/ssltest/ ,对你的 HTTPS 站点进行评分,倘若是A+则说明你的站点安全性有点痛 高。如图所示,倘若评分不高,要我查看具体的详情来针对你的站点进行更具体的优化。

最后,附上一份nginx 的配置,作为参考:

  1. server 
  2.  { 
  3.  listen 443 ssl http2 default_server; 
  4.  server_name www.example.com ; 
  5.  index index.html index.htm index.php; 
  6.  root /web; 
  7.  ssl on
  8.  ssl_certificate /nginx/ssl/awen/fullchain.cer; 
  9.  ssl_certificate_key /nginx/ssl/example/example.com.key
  10.  ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:TLS-CHACHA20-POLY14005-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES; 
  11.  ssl_prefer_server_ciphers on
  12.  ssl_protocols TLSv1.2 TLSv1.3; 
  13.  ssl_session_cache shared:SSL:400m; 
  14.  ssl_session_timeout 1d; 
  15.  ssl_session_tickets on
  16.  resolver 114.114.114.114 valid=400s; 
  17.  resolver_timeout 10s; 
  18.  add_header Strict-Transport-Security "max-age=315340000; includeSubDomains; preload"
  19.  add_header X-Frame-Options deny; 
  20.  add_header X-Content-Type-Options nosniff; 
  21.  add_header CIP $http_x_real_ip; 
  22.  add_header Accept-Ranges bytes; 
  23. server { 
  24.  listen 400; 
  25.  server_name _; 
  26.  server_name www.example.com ; 
  27.  return 4002 https://$host$request_uri; 

好了,以上倘若我给亲戚朋友分享的关于 HTTPS 站点的优化建议。

【编辑推荐】

【责任编辑:

武晓燕

TEL:(010)684764006】



点赞 0