对 nginx 服务器的 https 配置

发布时间:1970-01-01  编辑:Mrs.默先森 

    HTTPS server
    server {
    listen 1500 ssl; #端口号
    server_name localhost; #主机地址

    1. ssl_certificate ./conf/server1.crt; #ssl 证书
    2. ssl_certificate_key ./conf/server1.key; #私钥
    3. ssl_session_cache shared:SSL:1m; #设置会话缓存为 1M ,可存放约 4000 个会话
    4. ssl_session_timeout 5m; #缓存超时时间为 5 分钟
    5. ssl_ciphers HIGH:!aNULL:!MD5; #用来强制用户连接只能引入 SSL/TLS 那些强壮的协议版本和强大的 ssl_prefer_server_ciphers on; 加密算法
    6. location / { #返回默认页面
    7. root html;
    8. index index.html index.htm;
    9. }
    10. location = /lua { #返回/data/nginx/conf/luafile.lua 文件执行后的结果
    11. content_by_lua_file /data/nginx/conf/luafile.lua;

    }`
    以上 ssl 证书和私钥是自己生成的。

    对用到的几个配置项进行一个简短的说明:

    ssl_certificate 和 ssl_certificate_key是一块来使用的。ssl_certificate是ssl的证书,ssl_certificate_key是 ssl证书的密钥。服务器证书是公开的,会被传送到每一个连接到服务器的客户端。而私钥不是公开的,需要存放在访问受限的文件中,当然,nginx主进程 必须有读取密钥的权限。私钥和证书可以存放在同一个文件中,这种情况下,证书文件同样得设置访问限制。当然,虽然证书和密钥存放在同一个文件,只有证书会 发送给客户端,密钥不会发送。

    ssl_protocols和ssl_ciphers指令可以用来强制用户连接只能引入SSL/TLS那些强壮的协议版本和强大的加密算法。

    CBC模式的加密算法容易受到一些攻击,尤其是BEAST攻击(参见CVE-2011-3389)。可以通过下面配置调整为优先使用RC4-SHA加密算法:
    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on; 依赖SSLv3和TLSv1协议的服务器密码将优先于客户端密码。

    SSL 操作需要消耗CPU资源,所以在多处理器的系统,需要启动多个工作进程,而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握 手,有两种方法可以将每个客户端的握手操作数量降到最低:第一种是保持客户端长连接,在一个SSL连接发送多个请求,第二种是在并发的连接或者后续的连接 中重用SSL会话参数,这样可以避免SSL握手的操作。会话缓存用于保存SSL会话,这些缓存在工作进程间共享,可以使用 ssl_session_cache指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟,可以使用 ssl_session_timeout加大它。

    测试:

    通过浏览器以 https 的方式来访问 nginx,默认页面:在地址栏输入:https://192.168.11.93:1500

    用程序以 https 的方式来访问 nginx的默认页面:

    测试 https 访问程序 https_test.lua

    # do

    #local common_path = ‘../open/lib/?.lua;’

    #local cpath = ‘../open/lib/?.so;’

    #package.path = common_path .. package.path

    #package.cpath = cpath .. package.cpath

    #local libhttps = require(“libhttps”)

    #local function send_data()

    #local request = “GET /lua HTTP/1.0\r\n\r\n” ..

    # ‘User-Agent:(X11; Linux x86_64)’..

    # ‘Content-Type:application/x-www-form-urlencoded’..

    # ‘Accept-Language: zh-cn,zh;q=0.5’..

    # ‘Host: 127.0.0.1:1500’..

    # ‘Accept: /\r\n’

    #local ret = libhttps.https(“127.0.0.1”,1500, request, string.len(request))

    #print(ret)

    #end

    #send_data()

    #end

    TLS:

    最新版本的TLS(Transport Layer Security,传输层安全协议)是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别,主要是它们所支持的加密算法不同,所以TLS与SSL3.0不能互操作。

      1.TLS与SSL的差异

      1)版本号:TLS记录格式与SSL记录格式相同,但版本号的值不同,TLS的版本1.0使用的版本号为SSLv3.1。

       2)报文鉴别码:SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了 相似的算法,两者差别在于SSLv3.0中,填充字节与密钥之间采用的是连接运算,而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。

      3)伪随机函数:TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块,是更安全的方式。

       4)报警代码:TLS支持几乎所有的SSLv3.0报警代码,而且TLS还补充定义了很多报警代码,如解密失败 (decryption_failed)、记录溢出(record_overflow)、未知CA(unknown_ca)、拒绝访问 (access_denied)等。

      5)密文族和客户证书:SSLv3.0和TLS存在少量差别,即TLS不支持Fortezza密钥交换、加密算法和客户证书。

      6)certificate_verify和finished消息:SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时,计算的输入有少许差别,但安全性相当。

      7)加密计算:TLS与SSLv3.0在计算主密值(master secret)时采用的方式不同。

      8)填充:用户数据加密之前需要增加的填充字节。在SSL中,填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中,填充后的数据长度可以是密文块长度的任意整数倍(但填充的最大长度为255字节),这种方式可以防止基于对报文长度进行分析的攻击。

      2.TLS的主要增强内容

      TLS的主要目标是使SSL更安全,并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上,提供了以下增强内容:

      1)更安全的MAC算法

      2)更严密的警报

      3)“灰色区域”规范的更明确的定义

      3.TLS对于安全性的改进

       1)对于消息认证使用密钥散列法:TLS 使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0还提供键控消息认 证,但HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。

      2)增强的伪随机功能(PRF):PRF生成密钥数据。在TLS中,HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。

      3)改进的已完成消息验证:TLS和SSLv3.0都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS将此已完成消息基于PRF和HMAC值之上,这也比SSLv3.0更安全。

      4)一致证书处理:与SSLv3.0不同,TLS试图指定必须在TLS之间实现交换的证书类型。

      5)特定警报消息:TLS提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

    数字证书:

    数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的权威性电子文档,由权威公正的第三方机构,即CA(例如中国各地方的CA公司)中心签发。数字证书分为:服务器证书,电子邮件证书,个人证书3类。数字证书的出现是为了解决为你的公钥找一个公正人,就是说确定这个公钥就是你的,你的数字证书由谁颁发呢,CA(证书授权机构),但是要注意的是这里CA只是个泛称,不是特指某个机构,目前国内的比较出名的CA为GlobalSign。证书的内容包括:电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。目前,证书的格式和验证方法普遍遵循X.509 国际标准。现在就是呢,你的证书是由CA用它的私钥加密后形成的,客户端拥有CA的公钥,收到证书后,你用CA的公钥解密然后取出服务器的公钥。这样就能确定是你请求的服务器的公钥。但是现在有一个问题,CA的公钥从那儿获得呢?答案在根证书内,根证书是一份特殊的证书,是CA认证中心给自己颁发的证书,是信任链的起始点。下载安装根证书意味着对这个CA认证中心的信任,就表明您对该根证书以下所签发的证书都表示信任。

    注:因为任何人都可以生成自己的(公钥,私钥)对,所以为了防止有人散布伪造的公钥骗取信任,就需要一个可靠的第三方机构来生成经过认证的(公钥,私钥)对。目前,世界上最主要的数字服务认证商是位于美国加州的Verisign公司,它的主要业务就是分发RSA数字证书。

    顺便介绍一下与数字证书相关的两个术语:.pfx与CRL

    .pfx文件

    pfx(个人信息交换,Personal Information Exchange)的文件。.pfx 文件包含一个证书和与之对应的私钥(PKCS #12 标准对该格式有所说明)。这类文件是高度敏感的,通常用于导入服务器上的密钥对或用于备份目的。在导出密钥对时,Windows 提供用密码加密 .pfx 文件;而在导入密钥对时,您必须再次提供此密码方可导入。

    公钥加密技术12号标准(Public Key Cryptography Standards #12,PKCS#12)为存储和传输用户或服务器私钥、公钥和证书指定了一个可移植的格式。它是一种二进制格式,这些文件也称为PFX文件。开发人员通常需要将PFX文件转换为某些不同的格式,如PEM或JKS,以便可以为使用SSL通信的独立Java客户端或WebLogic Server使用。

    RL:证书撤销

    当订户个人身份信息发生变化,或者订户私钥丢失、泄露或者疑似泄露时,证书订户应及时地向CA提出证书的撤销请求,CA也应及时地把此证书放入公开发布的证书撤销列表。证书的撤销也表示了证书生命的终结。CA一般采用证书撤销列表的方式将被撤销的证书告知其他订户,CRL中列举着所有在有效期内但被撤销的数字证书。

    ssl证书:

    SSL证书是数字证书的一种,即为上面的服务器证书,类似于驾驶证、护照和营业执照的电子副本。SSL证书通过在客户端浏览器和Web服务器之间建立一条SSL安全通道,Secure socket layer(SSL)安全协议是由Netscape Communication公司设计开发。该安全协议主要用来提供对用户和服务器的认证;对传送的数据进行加密和隐藏;确保数据在传送中不被改变,即数据的完整性,现已成为该领域中全球化的标准。由于SSL技术已建立到所有主要的浏览器和WEB服务器程序中,因此,仅需安装服务器证书就可以激活该功能了,即这样就可以激活SSL协议,实现数据信息在客户端和服务器之间的加密传输,可以防止数据信息的泄露。保证了双方传递信息的安全性,而且用户可以通过服务器证书验证他所访问的网站是否是真实可靠。

    ssl证书的颁发:

    ssl证书可以自己颁发,也可以向ssl提供商请求颁发(这里只谈技术问题,先不谈收费问题)。自己颁发是不受浏览器信任的,你每次访问的时候会提示你有危险信息。需要你自己选择是否继续。如果是ssl提供商颁发的证书的话就可以直接访问了。 下面说一下证书的生成过程(包括自己颁发和ssl提供商颁发)。

    1.进入你想创建证书和私钥的目录,例如:

    $ cd ./conf

    2.创建服务器私钥,命令会让你输入一个口令,你自定义输入一个就行了:

    $ openssl genrsa -des3 -out server.key 1024

    3.生成一个证书请求(CSR)会提示输入省份 城市 域名信息等,重要的是email,email一定要是你的域名后缀的,比如xuyafei@daoke.me 并且可以接收邮件。如果下面是自己颁发的话全部可以不用填,全部用默认的或空的。如果要是向ssl提供商请求的话就需要认真填写了。:

    $ openssl req -new -key server.key -out server.csr

    这样就有一个csr文件了,将这个文件提交给ssl提供商即可,一般半个钟头到一天的时间就会发给你证书。证书是crt为后缀的。如果是自己颁发,就继续往下走。

    4.在加载SSL支持的Nginx并使用上述私钥时除去必须的口令:

    $ cp server.key server.key.org

    $ openssl rsa -in server.key.org -out server.key

    5.最后生成证书(crt):

    $ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

    当然了这里只是自己颁发了证书,如果后面需要正规机构颁发,我这儿也储备了一篇文章,见我的csdn博客nginx中转的一篇文章。

    PolarSSL:

    PolarSSL源码,也许是最小巧的ssl代码库。高效、便于移植和集成。尤其适合嵌入式应用。越来越多的应用已经从只支持OpenSSL到可以支持PolarSSL。PolarSSL 宣布加入 ARM 公司。我很高兴的宣布从今天起 PolarSSL 成为了 ARM 的一部分,作为全世界嵌入式芯片最领先的公司 ARM 将为 PolarSSL 带来充分的支持,可以让 PolarSSL 得到更好的发展。我们将继续支持我们已有的客户,同时构建新的生态系统来将 PolarSSL 扩展到新的领域和客户。

    这儿为什么突然提到PolarSSL呢?因为上面说的生成证书的步骤其实只是通用的大致步骤,放在具体的https库生成的证书就未必可用,比如我按以上步骤生成的证书在基于PolarSSL库时就不能用,好在PolarSSL库的目录polarssl-1.2.8/programs/ssl下有一个CA-HOWTO.txt的文件,介绍了在PolarSSL库下如何生成ssl证书。按这个步骤生成的证书就可用了,其实在polarssl-1.2.8/tests/data_files目录下有已经生成好的测试证书,可以先直接拿来测试一下。

    Why Https ?:

    由加密一个“password”引发的“血案”,一开始的时候想得是找一个C或者lua的加密算法实现程序,然后两边加密,最后止于编码问题。转向https,一个系统的密码保护机制是否安全取决于两个方面,即密码传输的安全性和密码存储的安全性。新浪微博和MySQL都没有采用HTTPS/SSL传输密码。为了防止黑客在密码传输过程中窃听密码,它们只能在传输过程中加盐然后用SHA1算法加密。由于密码在传输过程中需要加盐,为了能够正常验证密码,因此在存储密码时只能存储没有加盐的SHA1算法的哈希值。因此密码的存储成为整个机制的短板。笔者曾写过一篇博客讨论如何安全地存储密码。感兴趣的读者请参考http://blog.csdn.net/cadcisdhht/article/details/19282407。

    我们没有必要在抛弃HTTPS/SSL的前提下试图去设计更加复杂的加密算法或者通讯协议。上述提到的两个方案是新浪微博和MySQL的程序员们花了大量精力设计出来的机制,尚且还有明显的漏洞。我不觉得每个程序员都有自信说自己比新浪微博或者MySQL的程序员更加优秀。

    HTTPS/SSL在传输过程中用证书加密,不需要加盐来提高传输的安全性。这样在存储密码的时候就可以采用加盐的机制,比如简单地采用加盐的SHA1算法,也可以采用Bcrypt或者PBKDF2。如此以来,在密码的传输和存储两个环节都取得很好的安全性。

    如果安全性对一个系统是至关重要的因素,那么就采用HTTPS/SSL吧。虽然部署HTTPS/SSL的系统有些麻烦,申请可信赖的CA的证书还要花钱,但和安全漏洞的潜在风险相比这些代价还是值得的。(业界已经达成共识,在传输用户密码等需要保密的信息时,尽可能采用HTTPS/SSL协议传输。)

    标签nginx


本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动。

陶太富博客 http://blog.taotaifu.cn

最新发布

最新评论

0.071128s