SSL / TLSプロトコルを示します
テンセント大学の教室のおかげNEXT後援サイト、テンセントの公式フロントエンドコース学ぶための無料トライアル。
http：// www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
今週は、CloudFlareのは、自分の秘密鍵はSSLリンクを使用して暗号化することができます提供していないあなたは、自分のCDN上のサイトを置く可用性キーレスサービスを発表しました。
私は命令CloudFlareの（読み取りここでおよびここ）、突然これは、SSL / TLSプロトコルの動作機構を説明するために使用することができる優れた例であることに気づきました。これは、イラストとフォローしやすいが装備されています。
今、私は半年前に私が書いたと、一例として、これらの写真を使用し、「SSL / TLSプロトコルの動作機構の概要は、」 SSLプロトコルを説明します。
まず、SSLハンドシェイクプロトコル
あなたが暗号化された通信を開始する前に、クライアントとサーバが最初に接続し、交流のパラメータを確立する必要があり、このプロセスはハンドシェーク（握手）と呼ばれています。
クライアントがアリスと呼ばれていると、ボブは、サーバーと呼ばれる、全体のプロセスは、次の図が示す手を振ることができます（クリックすると拡大します）。
ハンドシェイクステージは5つのステップに分かれています。
最初のステップ、アリスは、プロトコルのバージョン番号、（ランダムクライアント）乱数を生成するために、クライアントの暗号化方式与えられ、クライアントによってサポート。
第二段階は、両方のボブが使用する暗号化方式を確認し、デジタル証明書、およびサーバ（サーバランダム）によって生成された乱数を与えます。
第3のステップは、アリスは、デジタル証明書が有効であること、そして新しい乱数（このpremaster_secret）を生成し、デジタル証明書、ボブに送信された暗号化された乱数の公開鍵を用いて確認しました。
第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。
上面的五步，画成一张图，就是下面这样。
二、私钥的作用
握手阶段有三点需要注意。
（1）生成对话密钥一共需要三个随机数。
（2）握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
（3）服务器公钥放在服务器的数字证书之中。
从上面第二点可知，整个对话过程中（握手阶段和其后的对话），服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。
某些客户（比如银行）想要使用外部CDN，加快自家网站的访问速度，但是出于安全考虑，不能把私钥交给CDN服务商。这时，完全可以把私钥留在自家服务器，只用来解密对话密钥，其他步骤都让CDN服务商去完成。
上图中，银行的服务器只参与第四步，后面的对话都不再会用到私钥了。
三、DH算法的握手阶段
整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。
虽然理论上，只要服务器的公钥足够长（比如2048位），那么Premaster secret可以保证不被破解。但是为了足够安全，我们可以考虑把握手阶段的算法从默认的RSA算法，改为 Diffie-Hellman算法（简称DH算法）。
采用DH算法后，Premaster secret不需要传递，双方只要交换各自的参数，就可以算出这个随机数。
上記の図、第三工程および第四工程は、DHアルゴリズム転送前マスター秘密に必要なパラメータに移し、それぞれの計算された前マスター秘密れます。これは、セキュリティが向上します。
四、セッションの復元
ハンドシェイクは、SSL接続を確立するために使用されます。何らかの理由で、対話が中断された場合は、握手をする必要があります。
セッションIDと呼ばれ、他方はセッションチケットと呼ばれている。そして、元のセッションを復元するには、2つの方法があります。
私は、セッションIDは、すべての会話が数（セッションID）を持っているということだけであると思いました。1を再構築することなく、既存の「セッションキーを」会話が中断された場合、限りクライアントはこの番号を与えているとして、次の時間を再接続し、サーバーがレコード番号を持っている、双方は再使用することができます。
サーバは番号が存在確認クライアントセッションIDが与えられると、上記の図、双方は、もはや残りの段階ハンドシェークは、暗号化されたセッション鍵を既存の直接通信を行っています。
セッションIDは、現在、すべてのブラウザの方法でサポートされていますが、それは、セッションIDは、多くの場合、単一のサーバー上に残っているという欠点があります。クライアント要求が別のサーバーに送信されるのであれば、それは対話を再開することはできません。セッションチケットは、唯一のFirefoxとChromeブラウザで生まれ、この問題を解決することです。
上の図は、クライアントがセッションIDを送信するが、最後の対話のセッションチケットの際に経由送信され、サーバーを送信しません。セッションチケットは、セッションキーと暗号化の方法として、この対話の主なメッセージを含む、サーバのみが復号化できる、暗号化されています。サーバーは、解読するためにセッションキーを再生成した後、セッションチケットを受け取ると。
（終わり）