https的原理

Http存在的问题

  上过网的朋友都知道，网络是很是不安全的。尤为是公共场所不少免费的wifi，或许只是攻击者的一个诱饵。还有你们平时喜欢用的万能钥匙，等等。那咱们平时上网可能会存在哪些风险呢？
  1. 泄密，我的隐私、帐户密码等信息可能会被盗取。
  2. 篡改，收到的数据可能被第三方修改过，或被植入广告等。
  3. 假冒，访问的站点非目标服务器站点。如域名欺骗、域名劫持、钓鱼网站等。

  可能住你隔壁穿人字拖、说话都略显羞涩的小王，一到夜深人静的时候就开始偷窥你的一举一动！陪你一块儿看91某社区的电影还好，万一窃取了各购物网站或其余站点的登陆信息就……是否是想一想有些惧怕呢！

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

  为了保护数据隐私，让数据再也不“裸奔”。对须要传输的数据进行加密处理就颇有必要了。目前而言，加密算法能够分两大类，一类是对称加密算法，还有一类是非对称加密算法。

对称加密

  对称加密算法的加密和解密都是用同一个密钥。在必定条件下，对称加密能够解决数据传输安全性的问题。好比我在登陆某个网站的时候，须要填写帐户名和密码进行登陆，客户端把登陆的表单信息进行对称加密后再传输，这时候就算小王截获数据包，他也没法获取数据的内容，由于数据已经被加密了。可是服务器收到数据后也是一脸懵逼，你发来的加密的数据包服务器也不知道解密的密钥！

  那是否是客户端与服务端在通讯以前应该先协商密钥呢？客户端能够通知服务器须要开启数据传输了，而后服务器告诉客户端，我们之后用xxxx这个密钥进行加密解密吧！

  这样内容是能够加密传输了，可是上图中第一步协商密钥的过程又一样存在安全的问题！万一小王截获了协商密钥的数据，那后续加密传输的数据对小王来讲无异于未加密！因此，对称加密存在密钥协商的问题！

非对称加密

  基于对称加密存在的问题，又有了非对称加密。非对称加密算法须要一组密钥对，分别是公钥和私钥，这两个密钥是成对出现的。公钥加密的内容须要用私钥解密，私钥加密的内容须要用公钥解密！私钥由服务器本身保存，公钥发送给客户端。客户端拿到公钥后就能够对请求进行加密后发送给服务端了，这时候就算被小王截获，小王没有私钥也没法解密发送的内容，这样确保了客户端发送到服务端数据的“安全”！可是因为公钥也须要经过网络发送给客户端，一样能被小王截获，这样服务器私钥加密后的内容依然能够被小王截获并解密，而且非对称加密的效率很低。

  对称加密和非对称加密都存在密钥传输的问题，可是至少非对称加密能够保证客户端传输给服务端的内容没法被“破解”，而对称加密算法性能又比较好，那咱们是否是能够这样子呢。第一次通讯的时候服务端发送公钥给客户端，由客户端产生一个对称密钥，经过服务端的公钥加密后发送给服务端，后续的交互中都经过对称密钥进行加密传输。也就是说先经过非对称密钥加密对称密钥，经过对称密钥加密实际请求的内容。

  上面的方案看起来完美无缺，小王拿到数据后貌似就无偿下手了，可是真的就天意无缝了吗？咱们看看下图

  也就是说小王能够假装成服务器，与客户端进行通讯。相似于你与服务端之间多了一个中间商！也就是说协商密钥的过程依然存在漏洞！

  有点脑阔疼！还能不能让我安全的上网了！就没有更安全的机制了么？ 在协商密钥的过程当中，客户端怎么能肯定对方是真正的目标服务器呢？怎么证实服务器的身份呢？咱们先了解一下数字证书！

数字证书

  咱们生活中有各类证，有能证实本身是个有身份的人的身份证，有能证实本身读了几年书的毕业证。这些证都是由某些权威机关认证、没法伪造的，能证实本身身份的凭据。那服务器是否是也能有个相似身份证的东西，在与服务器进行通讯的时候证实本身确实是目标服务器而不是小王伪造的呢？在生活中这些证件都是事实在在能看得见摸得着的，而计算机中的证书是虚拟的，看得见可是摸不着，是数据形式记录的，因此叫数字证书！

  客户端第一次与服务器进行通讯的时候，服务器须要出示本身的数字证书，证实本身的身份以及本身的公钥，相似以下（实际上就是一堆数据，这里为了直观）

  那这个数字证书怎么产生的呢？总不能是服务器本身造一个吧？上面说到了咱们生活中的证书是由权威机构颁发的、没法伪造的，好比身份证就是由派出所发证、毕业证由教育部发证，若是须要验证真假，只须要上相关的系统输入编号查询就能查到了！那咱们数字证书也应该有这两个特性-权威机构颁发、防伪！

CA机构

  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就是经过上面说到的那些手段来解决网络上可能存在的数据泄密、篡改、假冒的这些问题，保证网络传输的安全的啦！

  看到这里的你，对HTTPS的原理是否懂了呢，反正我奶奶看完已经懂了！手动狗头(*￣︶￣)

转自：http://www.javashuo.com/article/p-oagbweaw-bs.html