個人的な技術のブログで同時発売このホワイトペーパーでは、詳細はMengchuoすることができます
HTTPの問題
オンラインの友人は皆知って取得し、インターネットは非常に安全ではありません。特に、公共の場所で、無料Wi-Fi、おそらくちょうど餌の攻撃者がたくさん。私は通常そうであり、マスターキーを使用したい、と。それは我々が通常のオンラインのリスクが存在するものであるかもしれませんか？
1.情報漏洩、プライバシー、アカウントのパスワードなど盗まれることがあります。
2.改ざんは、データが第三者、あるいは移植広告によって修飾することができる受信しました。
3.偽造は、非標的部位は、サーバーのサイトを訪問しました。このようなようにドメインスプーフィング、ドメイン名乗っ取り、フィッシングサイトととして。
あなたはサンダルを着用する隣に住んでいることが、言葉は少し恥ずかしがり屋王、夜の死者への1つは、あなたのすべての動きをのぞき始めました！盗難や他のサイトのログイン情報の場合は91幸いなことに、様々なショッピングサイトのコミュニティで一緒に映画を見にあなたを同行......私はそれのいくつかについて考えることを恐れていませんよ！
なぜ人々は、あなたがそれにアクセスできるデータを得るのですか？TCP / IP上であり、様々なハンドシェイクの一部理解がロールメロンは早けれhttpプロトコルのために、心の中で明らかなように腐っ下品だったバック手を振っていたどのように多くの友人に基づいていくつかのネットワークがありました。httpプロトコルは、最上層は、TCP / IP参照モデルに位置しており、アプリケーション層です。ターゲットマシンに物理層を介してユーザデータのカプセル化層、アプリケーション層、トランスポート層、ネットワーク層、リンク層の後。人々があなたのパケットを得れば、あなたは簡単に情報データを得ることができるので、これらの層では、データは、暗号化されません。
データがもはやないように、データのプライバシーを保護するために「裸の。」送信するデータは、それが非常に必要である暗号化されています。ここでは、暗号化アルゴリズムは、非対称暗号化アルゴリズムのクラスがあり、1は、対称暗号化アルゴリズムで、2つのカテゴリに分けることができます。
対称暗号化
対称暗号化アルゴリズムを使用して暗号化と復号化は、ある同じ鍵。特定の条件下では、対称暗号化は、データ伝送のセキュリティの問題を解決することができます。たとえば私は、Webサイトにログオンすると、アカウント名とパスワードを入力する必要があり、クライアント情報、王は、パケットをキャプチャすることができたとしても、彼は、コンテンツデータを取得することはできません、送信前にこの時間は対称暗号化を形成するためにログオンデータは暗号化されています。しかし、データ・サーバを受けた後も、復号鍵を知らない暗号化されたデータパケットのサーバーを送信するためにあなたを強制的に無知な外観です！
これは、通信の前に、クライアントとサーバがすべきではない最初のキー相談し、それを？クライアントは、サーバーに必要なデータを通知することができ、我々はこのxxxxの暗号化と復号鍵後にそれを使用し、オンにし、サーバーはクライアントに伝えています！
このようなコンテンツは、送信を暗号化することができ、そのプロセスは、キー交渉上の図の最初のステップであり、セキュリティ上の問題もあります！ケースで王は、傍受データキーのネゴシエーションを、そして王の伝送のためのフォローアップのデータの暗号化は、暗号化されていないに等しいであることを！したがって、対称暗号鍵ネゴシエーションの問題！
非対称暗号化
対称暗号化の問題に基づいて、非対称暗号化が行われています。非対称暗号化アルゴリズムが必要とする鍵ペアのセット、それぞれ公開鍵と秘密鍵を、2つのキーが対になっています。コンテンツを解読するために、公開鍵暗号の秘密鍵を使用する必要があり、暗号化されたコンテンツを復号化するための秘密鍵は、公開に必要！自分自身の保存、サーバーの秘密鍵では、公開鍵をクライアントに送信されます。申請後に暗号化することができ、公開鍵を取得するために、クライアントがサーバーに送信され、この時も王を傍受した後、王は、送信されたコンテンツを復号化するための秘密鍵なしで、ことができなかったので、クライアントはサーバーのデータに送信することを確認してください「セキュリティ」！公開鍵は、ネットワークを介してクライアントに送信する必要があるため、サーバの秘密鍵暗号化はまだ傍受し、王を復号化し、非対称暗号化効率が低いことができるように、しかし、同じことは王、内容によって傍受することができます。
对称加密和非对称加密都存在密钥传输的问题，但是至少非对称加密可以保证客户端传输给服务端的内容无法被“破解”，而对称加密算法性能又比较好，那我们是不是可以这样子呢。第一次通信的时候服务端发送公钥给客户端，由客户端产生一个对称密钥，通过服务端的公钥加密后发送给服务端，后续的交互中都通过对称密钥进行加密传输。也就是说先通过非对称密钥加密对称密钥，通过对称密钥加密实际请求的内容。
上面的方案看起来天衣无缝，小王拿到数据后貌似就无偿下手了，但是真的就天意无缝了吗？我们看看下图
也就是说小王可以伪装成服务器，与客户端进行通信。类似于你与服务端之间多了一个中间商！也就是说协商密钥的过程依然存在漏洞！
有点脑阔疼！还能不能让我安全的上网了！就没有更安全的机制了么？ 在协商密钥的过程中，客户端怎么能确定对方是真正的目标服务器呢？怎么证明服务器的身份呢？我们先了解一下数字证书！
数字证书
我们生活中有各种证，有能证明自己是个有身份的人的身份证，有能证明自己读了几年书的毕业证。这些证都是由某些权威机关认证、无法伪造的，能证明自己身份的凭据。那服务器是不是也能有个类似身份证的东西，在与服务器进行通信的时候证明自己确实是目标服务器而不是小王伪造的呢？在生活中这些证件都是事实在在能看得见摸得着的，而计算机中的证书是虚拟的，看得见但是摸不着，是数据形式记录的，所以叫数字证书！
客户端第一次与服务器进行通信的时候，服务器需要出示自己的数字证书，证明自己的身份以及自己的公钥，类似如下（实际上就是一堆数据，这里为了直观）
那这个数字证书怎么产生的呢？总不能是服务器自己造一个吧？上面说到了我们生活中的证书是由权威机构颁发的、无法伪造的，比如身份证就是由派出所发证、毕业证由教育部发证，如果需要验证真假，只需要上相关的系统输入编号查询就能查到了！那我们数字证书也应该有这两个特性-权威机构颁发、防伪！
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的原理是否懂了呢，反正我奶奶看完已经懂了！手动狗头(*￣︶￣)