ブログの移動：原理概要HTTPS
いくつかの内部インターフェイスは、HTTPSを使用する必要が会社のサーバー上の最近のプロジェクトなので、波を研究するために時間がかかります。我々は、送信時に暗号化データにはない知っているのHttp、機密情報の伝達に大きなセキュリティ上のリスクがあります。そのため、HTTPSベースでのhttpは、データ伝送のセキュリティを保護するためにSSL（セキュアソケットレイヤー）暗号化を追加しました。今日では、TLSを使用すると、実際にSSLのアップグレード版です。具体的な概念は、ウィキペディアのhttpsを参照することができ
ます。https紹介
原理は模索1.https
HTTPSのセキュア情報保護機構は、実際には、一つの文章に要約することができます。非対称暗号化することにより、対称秘密鍵を交渉するために、クライアントとサーバは、その後、CSは、暗号化されたデータを復号化データ交換を完了するために、対称秘密鍵の両端に使用しました。そのため、データ転送は、実際には対称暗号化を取っているとき。確かにこの文の前提を理解するには、我々が議論されていない、対称および非対称暗号化の原則を理解する必要があります。
原理の概要
SSL暗号化メカニズムの一般的な手順：
- クライアントがリクエストを送信します
- サーバー証明書が返されます
- そして、証明書の公開鍵を検証するためにクライアントを削除
- クライアントは、乱数を生成し、サーバの公開鍵を使用して、それを暗号化し、サーバーへの結果の暗号文
- 乱数を取得するために、秘密鍵を使用して、サーバーの解読
- それぞれの両端は、ネゴシエーションが完了した対称鍵によって乱数を生成します
デジタル証明書とデジタル署名
詳細な説明に先立ち、デジタル証明書は、全体のSSL暗号化とネクタイの中核です、私はデジタル、デジタル証明書の原因と原則についてお話したいと思い、手を振りました。まず、前非対称暗号化を用いて送信すると、クライアントは、攻撃の存在、すなわち、中間当事者が、その後、自身の秘密鍵を介して取得し、クライアントにサーバ自身の公開鍵を交換する公開鍵を使用して、サーバの公開鍵を取得する必要がありますコンテンツの非対称暗号化は盗聴や改ざんを達成するために、クライアントから送信されました。下に示すように、理解を容易にするために、インターネットは、直接私と一緒に絵をもたらしています。
サードパーティパブリックプロセスの取得を防止するために、置換の破壊などがあったので、そこ機構証明書、署名された映像番組サーバ証明書であること、及び検証の一般的なプロセスの下であろう。
証明書は、3つの部分が含まれています
- 証明書の内容（公開鍵サーバー、サーバー情報など）
- 暗号化アルゴリズム（暗号化アルゴリズム、ハッシュアルゴリズム）
- 密文（使用哈希算法计算证书内容得到哈希摘要，再使用CA私钥加密该摘要即得到密文，该过程称为数字签名）
验证数字证书
- 客户端验证服务器证书时，需要获取到你的上一级CA证书，从而得到取CA公钥，使用CA公钥对证书中的密文解密得到哈希摘要，同时客户端使用同样的哈希算法对服务器证书内容计算得到另一个哈希摘要，若这两个摘要相等，则证明证书合法。
上述的哈希签名也称为数字指纹法，该方法的精髓在于，相同的明文通过哈希计算得到的摘要，一定是相同的，而只要两份明文只要有一丝丝区别，其对应的哈希值也是不同的。因此，若第三方替换了证书中的公钥，根据证书内容计算出的新的摘要一定与密文中的摘要有所差异的，故可以轻松地判断证书不合法。
疑问
（1）既然是使用上级CA证书来验证服务器证书，那如何证明上级CA证书的合法性？
- 这涉及到一个证书信任链的问题。上级证书通过更高一级的CA根证书来确定其合法性，这是一个递归向上的过程，直到最顶层根证书。顶层CA根证书是整个安全体系的根本。
（2）前文提到的攻击方式，只替换公钥显然是不行，那如果第三方把整个证书都替换成自己的证书（因为CA机构可以给任何人签名，黑客也可以），这样的话客户端的验证是不是可以通过？
- 答案当然是否定的，很简单，因为证书内容里的服务器信息是唯一的、不可复制的，例如域名，若替换整个证书，域名也会变成黑客自己的域名，浏览器不会接受域名和请求内容不匹配的证书。比如说，浏览器请求了 baidu.com，结果返回了个google.com的证书，毫无疑问会立即排除掉。
保证了服务器公钥安全抵达客户端手中，后续的对话秘钥的协商便也能顺理成章地进行。因此https所采用的SSL机制是绝对安全的，几乎没有人能够破解。当然，有得必有失，https花费的开销也远高于http。
SSL握手过程
https握手原理图
理解了上文所讲的证书机制，其实SSL加密机制也基本容易理解了，下面细究一下SSL握手过程，此处结合上方交互原理图进行分析
（1） Client Helllo。客户端发送初次请求，请求内容包含版本信息，加密套件候选列表，压缩算法候选列表，随机数random_1，扩展字段等信息，以明文传输；
（2）服务器选择客户端支持的加密套件、压缩算法、协议版本等，生成随机数random_2；
（3）服务器将上述算法以及随机数等发送给客户端；
（4）服务器发送服务器数字证书；
（5）客户端接收服务器选择的算法以及随机数等，验证数字证书。若证书验证通过，或者用户接受了不可信证书，客户端获取服务器公钥，同时会生成随机数random_3，并使用服务器公钥加密该随机数得到密文；
（6）客户端将第五步得到的密文传给服务器，由于公钥加密的内容只能使用私钥解开，所以random_3无法被窃听；
（7）Change cipher Spec。客户端通知服务器协商完成；
- 此时客户端已存有三个随机数random_1、random_2和random_3，前两个是可以被截获的，第三个是私密的，根据这三者可计算得出对话秘钥，即enc_key=Fuc(random_1, random_2, random_3)
（8）客户端结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，并使用对话秘钥enc_key和算法将其加密，得到密文encrypted_handshake_message，将其发送给服务器进行验证；
（9）服务器使用私钥解密第六步得到的密文，得到随机数random_3，此时服务器也拥有了三个随机数random_1、random_2和random_3，同样可计算出对话秘钥enc_key，至此双方共享对称加密秘钥的目的已达成；计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
（10）同様に図7及び図8に示すように、サーバは、クライアントのネゴシエーションが完了した通知し、送信encrypted_handshake_messageを算出します。クライアント検証encrypted_handshake_message同様に、ハンドシェイクが完了しています。
ハンドシェイクが完了した後、サーバーとクライアントが同じ秘密鍵の対話enc_keyを使用して、メッセージの内容は、安全な通信のために暗号化されています。