https的原理入门

现在基本上互联网上访问的地址都是使用HTTPS协议了，只有局域网才会使用HTTP协议，因此了解HTTPS十分重要。

HTTP存在的问题

上过网的朋友都知道，网络是非常不安全的。尤其是公共场所有很多免费的WIFI，或许只是攻击者的一个诱饵。那么我们平时上网可能会存在哪些风险呢？

1.泄密。个人隐私，账户密码等信息可能会被盗取。

2.篡改。收到的数据可能会被第三方修改，或被植入广告等。

3.假冒。访问的站点不是目标服务器站点，比如域名欺骗、域名劫持和钓鱼网站等。

为什么别人能获取你上网的数据呢？有过一定网络基础的朋友多少都对TCP/IP有些了解，对各种握手挥手早已背的滚瓜烂熟，对HTTP协议也是早已了然于心。HTTP协议是应用层的协议，位于TCP/IP参考模型的最上层。用户数据经过应用层、传输层、网络层和链路层的层层封装之后经过物理层发送到目标机器。在这几层中，数据都没有经过加密处理，所以一旦别人获取到你的数据包，就能轻易地获取到数据的信息。

因此为了保护数据隐私，需要对传输的数据进行加密处理。目前而言，加密算法可分为两大类，一类是对称加密算法，还有一类是非对称加密算法。

对称加密算法

对称加密算法的加密和解密都是使用同一个密钥。在一定的条件下，对称加密可以解决数据传输安全性的问题。比如在登陆某个网站的时候，需要填写账号和密码进行登陆，客户端把登陆的表单信息进行对称加密后再传输，这时候就算有第三方截获数据包，他也无法获取数据的内容，因为数据已经加密了。只要服务器与客户端在通信之前协好密钥，就能实现数据的加密传输。

这样，内容是可以加密传输了，但是在客户端与服务端协商密钥的过程中却同样会存在安全问题，一旦第三方截获了协商密钥的数据，那后续的加密传输的数据对第三方来说相当于未加密。因此对称加密算法存在密钥协商的问题。

非对称加密算法

基于对称加密算法存在的问题，又有了非对称加密算法。非对称加密算法需要一组密钥对，分别是公钥和私钥，这两个密钥是成对出现的。公钥加密的内容需要用私钥解密，私钥加密的内容需要用公钥解密。私钥由服务器自己保存，公钥发送给客户端。客户端拿到公钥之后就可以对请求进行加密后发送给服务端了。这时候就算被第三方截获，第三方也没有私钥去解密发送的内容，这样就确保了客户端发送到服务端时数据的安全。但是由于公钥也需要通过网络发送给客户端，同样也能被第三方截获，这样服务器私钥加密后的内容依然可以被第三方截获并解密，并且非对称加密的效率非常低。

对称加密和非对称加密都存在密钥传输的问题，但是至少非对称加密可以保证客户端传输给服务端的内容无法被破解（需要私钥，私钥只在服务器上），而对称加密算法的性能又比较好，那我们就可以平衡一下两种算法的优缺点：第一次通信的时候服务端发送公钥给客户端，由客户端产生一个对称密钥，通过服务端的公钥加密后发送给服务端，后续的交互中通过对称密钥进行加密传输，也就是说先通过非对称密钥加密对称密钥，通过对称密钥加密实际请求的内容。

上面的方案看起来好像天衣无缝，第三方拿到数据之后貌似无从下手了，但是真的是这样吗？在这里有个漏洞，第三方可以伪装成服务器与客户端进行通信，类似客户端与服务端之间多了一个中间商。也就是说，协商密钥的过程仍然存在漏洞。那么，客户端在协商密钥的过程中如何确定对方是真正的目标服务器就成了一个需要迫切解决的问题。

数字证书

我们生活中有各种证，有能证明自己是个有身份的人的身份证，有能证明自己读了几年书的毕业证。这些证都是由某些权威机关认证、无法伪造的、能证明自己身份的凭证。那服务器是不是也能有个类似身份证的东西，在与服务器进行通信的时候能证明自己确实是目标服务器而不是第三方伪造的呢？在生活中这些证书都是实实在在能看得见摸得着的，而计算机中的证书是虚拟的，看得见但是摸不着，是数据形式记录的，所以叫数字证书。

客户端第一次与服务器进行通信的时候，服务器需要出示自己的数字证书，证明自己的身份以及自己的公钥。那么这个数字证书怎么产生呢，总不能是服务器自己造一个把？上面说到了我们生活中的证书是由权威机构颁发的、无法伪造的，比如身份证就是由派出所发证、毕业证由教育部发证，如果需要验证真假，只需要上相关的系统输入编号查询就能查到了。那数字证书也应该有这两个特性：权威机构颁发和防伪。

CA机构

CA机构就是数字证书颁发的权威机构，负责颁发证书以及验证证书的合法性。如果服务器需要做一个有身份的服务器，就需要向CA机构提交申请（收费），需要提交站点的信息如域名、公司名称、公钥等，CA审批无误之后就可以给服务器颁发证书了。

客户端在拿到服务器的证书之后，就需要验证证书编号是否能在对应的CA机构查到，并且核对证书的基本信息，如证书上的域名是否与当前访问的域名一致等，还可以拿到证书中服务器的公钥信息用于协商对称密钥。

证书颁发了，可是怎么防止伪造，又怎么保证在传输过程中不被篡改呢？万一第三方截获到数字证书，又把公钥改成自己的那不是无法保证安全了？这时就需要数字签名了。

数字签名

与公司签过劳动合同的朋友应该都知道，在合同信息的填写中，是不能有涂改的，否则需要重新填写！并且在最后需要甲方和乙方签名并且盖章。一旦签名盖章后的合同就具有了法律的效力，合同就不能再修改。签名和盖章操作就是防止合同伪造，规定不能修改就防止了合同被篡改。

在实际生活中签名、盖章操作是实实在在的动作，作用在具体某个物体上的！但是我们的数字证书本身就是虚拟的，怎么去给一个虚拟的证书签名盖章呢？数字签名又是什么机制呢？

我们在做权限系统的时候，存储用户密码的时候都会经过MD5计算摘要后存储，在登录的时候计算用户填写的密码的MD5摘要与数据库存储的摘要进行对比，如果一致则密码正确，否则登录失败！MD5是不可逆的，且不同的数据计算出来的摘要是不一样的（当然也有极小的概率会hash碰撞），基于这个特性，就有了数字签名的思路。

服务器提交自己的基本信息想CA机构提出申请，CA机构在给服务器颁发证书的时候，会连同数字证书以及根据证书计算的摘要一同发送给服务器，且这个摘要是需要经过CA机构自己的私钥进行加密的。申请流程如下：

啥？不够直观？那我们再来个直观点的！通过下图我们能看到，CA给服务器颁发的证书是有自己专属的“公章”的。

哪些CA机构对于客户端来说是权威或者说是认可的呢？我们打开IE浏览器能看到客户端内置的CA机构的信息，包含了CA的公钥、签名算法、有效期等等...

  服务器在与客户端通信的时候，就会将数字证书和数字签名出示给客户端了。客户端拿到数字证书和数字签名后，先通过操作系统或者浏览器内置信任的CA机构找到对应CA机构的公钥对数字签名进行解密，然后采用同样的摘要算法计算数字证书的摘要，如果自己计算的摘要与服务器发来的摘要一致，则证书是没有被篡改过的！这样就防止了篡改！第三方拿不到CA机构的私钥，也就无法对摘要进行加密，如果是第三方伪造的签名自然也在客户端也就无法解密，这就防止了伪造！所以数字签名就是通过这种机制来保证数字证书被篡改和被伪造。具体流程如下：

啥？又不够直观？那我们继续...

这里需要注意一点，一个是CA机构的公钥，内置在客户端，用来解密数字签名！另一个是目标服务器的公钥，在数字证书内容里，用来协商对称密钥！

HTTPS

本文的标题是HTTPS，但是到目前为止HTTPS只字未提。其实HTTPS=HTTP+SSL，在HTTP层和TCP层之间加了一个SSL/TLS层。

 

SSL（Secure Sockets Layer，安全套接层），后来由于广泛应用，SSL标准化之后就改名为TLS（Transport Layer Security）了，其实HTTPS就是通过上面说的那些手段来解决网络上可能存在的数据泄密、篡改、假冒的这些问题，保证网络传输的安全。

 

转自：http://www.17coding.info/article/22

"无论对谁，太过热情，就会增加不被珍惜的概率。"