Hao4K影音

宅嗨网NAS设置HTTPS技巧前言最近半年都在开发AquarHome的流媒体组件，最近开发完成终于可以喘口气做一些总结了。开发的时候发现无论是websocket还是流媒体服务，都要求服务端使用https,否则无法集成这两项能力，于是我把AquarHome的服务协议从htp切换成了https。这个过程中重新梳理了一遍https协议的相关概念，在此分享出来供需要的人参考。文章的技术性很强，篇幅也不短，但其中对核心概念的解释可以作为一个手册在需要的时候给你解惑，自签名证书的生成与配置也可以在需要的时候解决问题。可以先收藏，等到需要配置https的时候再拿出来详细参考。其实现如今在公网上访问的大多数网站都是https协议了，https协议可以说是现在互联网的安全的基石。但是安全算法中的各种概念和流程总让人晕头转向，这些内容即使对于一个专业的程序员（比如说我）来说理解起来也并非易事，那么对于一个普通的NAS玩家就更是天书一般。本文就试图对https背后的协议进行简单描述，以求建立起对整个htps协议的大体直觉，最终我们将自签名证书应用在自己的服务上，并且让我们的浏览器认可这个证书。握手流程HTTPS协议的核心是基于Ssl协议，而ssl协议简单来讲就是是通过一系列握手过程保证连接安全性的一种机制。S$!的大概思路是，使用安全但复杂的非对称加密方式(RSA)让客户端传输一个加解密口令给服务端，收到以后服务端就用这个口令与客户端进行高效的对称加密通信。非对称加密的流程中，客户端需要获取一个服务端指定的公钥（实际中的载体是证书），用这个公钥给口令加密，然后发给服务端，服务端用私钥解密后就开始对称加密的阶段了。中间人问题与基于CA机构的解决方式那么如果现在有个“中间人”拿着自己生成的公钥欺骗客户端说：“我手里这个就是服务端的公钥，给你用吧。”客户端使用这个公钥传上去口令信息就会被“中间人”知道，“中间人”知道口令后用真正的公钥替客户端走完了与服务端的握手环节，那么后续客户端在网络上的信息对于“中间人”来说就都是可以解密出来的，这调链路上的信息就全都被“中间人”监听了。这就是“中间人”攻击。那客户端直接找服务端要公钥行不行？也不行，因为客户端并不“认识”服务端，他没有能力判断这个P地址就是服务端的地址。那么如何避免这个问题呢？简单说就是不相信来历不明的公钥。具体来说，在网络上有几家有公信力的平台(CA机构)，任何提供服务的服务器都可以把自己的公钥放在这里（要钱的），而客户端如果想访问哪个服务，就问这个平台要公钥，平台负责把公钥发出去。就好比大家都为了保险，都把钥匙挂在东方明珠的塔尖上，因为东方明珠的塔尖只有一个，且大家都认识，所以没办法造假。CA机构（有公信力的大平台）实际的操作方式是用自己的私钥对服务器的证书（公钥)的全文进行签名，然后把签名、CA机构自己的公钥以及有https需求的服务端证书一起打包成一个经过CA机构签发的证书。用前面的例子就是一把塔尖杆上的每一把钥匙又放进单独的盒子里，每个盒子都可以用东方明珠塔下面的同一把钥匙打开取出来。这里面东方明珠塔下面的钥匙，也就是CA机构自己的公钥及相关信息，因为没人替他提供托管服务了处于这整个链路的根源处，所以叫根证书。因为权威的CA机构也就那么几家，所以很多浏览器直接内置了大部分CA机构的根证书，相当于就那几把钥匙天天要使，于是自己配了一套，需要的时候直接用。简单总结就是，客户端用对少数几个“一定不是中间人”的CA机构的信任来规避中间人问题。CA证书签发流程及客户端校验流程从前面的介绍可以知道，如果想在互联网上用https协议，就得找一个CA机构来签发自己的证书，大概步骤如下：1.在业务服务器上生成一对RSA密钥，openssl生成的密钥通常以.key结尾，其中同时包含了公钥和私钥信息。2.业务服务器使用密钥对生成一个网站证书，其中的核心内容是公钥，后缀名通常是.ct。3.使用网站证书向某个CA机构发出一个签发申请，这个申请通常以一个后缀名是.csr的文件表示。其中包含了.ct的全部信息以及发出申请的公司信息等信息。4.CA机构收到签发申请后，用CA机构自己的私钥对申请中的网站证书生成个签名，然后把这个签名以及原网站证书打包生成一个新的CA签发证书。业务服务器拿到这个CA签发的证书就可以把这个证书挂在nginx或者别的网关上提供https服务了。证书签发完成后，客户端如何使用呢？流程如下：1.当客户端需要访问业务服务器的https接口时，他从这个服务器上请求下来个证书。2.客户端看到这个证书上面有某个CA机构的签名，于是他从CA机构请求一个CA根证书（如果自己已经内置了改CA机构的根证书，就不需要再请求了）的来尝试对签名进行解密，解密成功，说明这张证书确实是这个CA机构签发的，可以信赖。3.客户端生成一个对称加密的密钥，然后从第一步中的证书上把公钥提取出来，用这个公钥对对称密钥加密。把这个报文发给业务服务器。4.业务服务器接收到对称加密的密钥后，客户端就可以开始业务数据的传输了。自建CA证书与自签名证书对于正规的企业来说，因为有稳定的网络出口P和域名，以及充足的资金支持，为SSL证书支付一笔费用是完全可以接收且容易办到的。但对于个人应用来说就不同了，个人用户很少会拥有固定P地址，对于费用也非常敏感，那么难道个人搭建的系统就不配用https吗？当然不是，因为CA机构本质上也只是一对密钥加上一个证书在起作用而已，我们可以自己生成这两样东西，然后给自己的证书进行签发。虽然CA机构不是公认的，但只要浏览器安装了我们自己生成的根证书，那他的效力与正常CA机构的效力是基本相同的。这种自己构建一个CA机构的证书在国内几乎所有的博客中都直接将上述这种自建CA机构签发的证书称作自签名证书，但如果你看国外论坛，就会发现，自签名证书指的并不是这种证书。自签名证书指的是另一种更极端的签发形式。因为业务服务器自己就有一对公私钥，而签发其实只是需要用私钥对包含公钥的证书进行一个签名即可，那我完全可以直接用自己的私钥给自己签名，自己充当自己的CA机构，这才是真正的自