与 Nginx 的 HTTPS 相关的两篇翻译文章要点记录

近期由于 HTTPS 漏洞的问题,公司领导要求把 HTTPS 相关使用完善起来,鉴于之前对 nginx 的理解非常的肤浅,所以本着边学边做的原则展开对相关文章的研究。

【知识点】

为什么要使用 HTTPS:
SSL 虽然不完美,但是可以使得被窃听的成本大大的提高;
为了让别人不为隐私问题担忧,加密保护默认应该开启;
如果你的客户是从使用 HTTPS 的网站上过来的,那么你就可以通过 Google Analytics 获取到更完整的 referrer 信息。

最简配置

server {
    listen 80;
    server_name konklone.com;
    return 301 https://$host$request_uri;
}
 
server {
    listen 443 ssl;
    server_name konklone.com;
 
    ssl_certificate /path/to/unified.crt;
    ssl_certificate_key /path/to/my-private-decrypted.key;
}
 
# for a more complete, secure config:
# 这里有一个更完整的配置,支持 SPDY、HSTS(Http Strict Transport Security)、SSL session resumption 和 Perfect Forward Secrecy 。
# https://gist.github.com/konklone/6532544

这里贴出 https://gist.github.com/konklone/6532544 中的内容

server {
    listen 80;
    server_name konklone.com;
    return 301 https://$host$request_uri;
} 
# optional: the 'spdy' at the end of the listen command below turns on SPDY support.
 
server {
    listen 443 ssl spdy;
    server_name konklone.com;
 
    # required: path to certificate and private key
    # the .crt may omit the root CA cert, if it's a standard CA that ships with clients.
    ssl_certificate /path/to/unified.crt;
    ssl_certificate_key /path/to/my-private-decrypted.key;
 
    # optional: tell browsers to require SSL (warning: difficult to change your mind)
    add_header Strict-Transport-Security max-age=31536000;
 
    # optional: prefer certain ciphersuites, to enforce Perfect Forward Secrecy and avoid known vulnerabilities.
    # done in consultation with:
    #   http://ggramaize.wordpress.com/2013/08/02/tls-perfect-forward-secrecy-support-with-apache/
    #   https://www.ssllabs.com/ssltest/analyze.html
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA;
 
    # optional: turn on session resumption, using a 10 min cache shared across nginx processes
    # as recommended by http://nginx.org/en/docs/http/configuring_https_servers.html
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;
    keepalive_timeout   70;
 
    # nginx 1.5.9+ ONLY
    ssl_buffer_size 1400; # 1400 bytes to fit in one MTU
 
    # SPDY header compression (0 for none, 1 for fast/less compression, 9 for slow/heavy compression)
    spdy_headers_comp 6;
 
    # OCSP stapling - means nginx will poll the CA for signed OCSP responses, 
    # and send them to clients so clients don't make their own OCSP calls.
    # http://en.wikipedia.org/wiki/OCSP_stapling
    # 
    # while the ssl_certificate above may omit the root cert if the CA is trusted,
    # ssl_trusted_certificate below must point to a chain of all certs
    # in the trust path - (your cert, intermediary certs, root cert)
    #
    # 8.8.8.8 below is Google's public DNS server. nginx will use it to talk to the CA.
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8;
    ssl_trusted_certificate /path/to/all-certs-in-chain.crt;
}

当你的 web 服务器(nginx)会被用于代理后端 app 服务器(例如 Sinatra、Django 或 Express),你可能会希望 nginx 将自己正在使用 HTTPS 这件事情告知后端的 app 服务器,以便后端 app 服务器知道应该保留将当前 HTTPS 信息以用于重定向。否则,你将会在(例如)执行了 HTTPS POST + HTTP redirect + HTTPS redirect 之后,得到一个包含混合内容的警告信息。

# inside server block...
location / {
   proxy_set_header X-Forwarded-Proto $scheme;
 
 
   # ...other proxy settings...
}

给出了一个线上 SSL 测试工具的 网址 。
https://www.ssllabs.com/ssltest/analyze.html

如果你的网站使用了 HTTPS,那么你需要确保所有被链接的资源,包括 images、stylesheets 和 JavaScript 等,均要支持 HTTPS 访问。如果你没这么做,那么用户的浏览器可能就会“抱怨”了。比如,新版的 Firefox 将会在安全页面上完全屏蔽掉不安全的内容。

建议备份你已经得到的密钥和证书。

文中涉及到的技术名词:

【 SPDY 】
【 HSTS 】
【 SSL session resumption 】
【 Perfect Forward Secrecy 】

另外一处讲解什么是 Perfect Forward Secrecy 的文章(以下内容来自 http://www.perfectforwardsecrecy.com/ )

The security of communications transmitted across the Internet can be improved by using public key cryptography. However if the public and private keys used in those communications are compromised it can reveal the data exchanged in that session as well as the data exchanged in previous sessions.
 
The concept of Perfect Forward Secrecy (PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future. Online systems such as IPSEC can negotiate new keys for every communication and if a key is compromised only the specific session it protected will be revealed.
 
For Perfect Forward Secrecy to exist the key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material must not be used to derive any more keys.
 
Cisco offers Perfect Foward Secrecy as a parameter for VPN and LAN-to-LAN tunnel sessions. The Internet Key Exchange (IKE) Policy settings can use Diffie-Hellman Group algorithms. Virtru uses the AES-256 algorithm to encrypt messages with perfect forward secrecy before it leaves a device.
 
Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key.
 
Forward Secrecy has been used as a synonym for Perfect Forward Secrecy but there is a subtle difference between the two. Perfect Forward Secrecy has the additional property that an agreed key will not be compromised even if agreed keys derived from the same long-term keying material in a subsequent run are compromised.
 
In April 2014, a news article by the Electronic Frontier Foundation (EFF) was posted in reponse to the OpenSSL Heartbleed bug. Why the Web Needs Perfect Forward Secrecy More Than Ever… “At this moment, forward secrecy is more crucial than ever before.”
 
The FHMQV-C protocol (Fully Hashed MQV plus C for ‘key confirmation’) uses perfect forward secrecy. The compromise of a static private key does not compromise any of the session keys, and this can be demonstrated through analysis of FHMQV with session key expiration.

还没有评论,快来抢沙发!

发表评论

  • 😉
  • 😐
  • 😡
  • 😈
  • 🙂
  • 😯
  • 🙁
  • 🙄
  • 😛
  • 😳
  • 😮
  • emoji-mrgree
  • 😆
  • 💡
  • 😀
  • 👿
  • 😥
  • 😎
  • ➡
  • 😕
  • ❓
  • ❗
  • 67 queries in 0.379 seconds