記事は Github/ブログと同期されます
人々はいくつかの非常に重要なことを処理するために Web トランザクションを使用します。強力なセキュリティ保証がなければ、人々は安心してオンライン ショッピングや銀行取引を行うことができません。企業は、アクセスを厳しく制限せずに重要なドキュメントを Web サーバーに置くことはできません。 Web には安全な形式の HTTP が必要です。
現在、いくつかの 認証の提供 (Basic 認証 および Digest 認証) と メッセージ整合性チェック (概要 A qop="auth-int" への軽量アプローチ)。これらの方法は、多くのネットワーク トランザクションにはうまく機能しますが、大規模なショッピング、銀行取引、または機密データへのアクセスには十分強力ではありません。これらのより重要なトランザクションでは、セキュリティを確保するために HTTP とデジタル暗号化を組み合わせる必要があります。 提供认证(基本认证和 摘要认证 )和报文完整性检查(摘要 qop="auth-int")的轻量级方法。对很多网络事务来说，这些方法都是很好用的， 但对大规模的购物、银行事务，或者对访问机密数据来说，并不足够强大。这些更 为重要的事务需要将 HTTP 和数字加密技术结合起来使用，才能确保安全。
HTTP 的安全版本要高效、可移植且易于管理，不但能够适应不断变化的情况而且还应 该能满足社会和政府的各项要求。我们需要一种能够提供下列功能的 HTTP 安全技术。
服务器认证 (客户端知道它们是在与真正的而不是伪造的服务器通话)。
客户端认证 (服务器知道它们是在与真正的而不是伪造的客户端通话)。
完整性 (客户端和服务器的数据不会被修改)。
加密 (客户端和服务器的对话是私密的，无需担心被窃听)。
效率 (一个运行的足够快的算法，以便低端的客户端和服务器使用)。
普适性 (基本上所有的客户端和服务器都支持这些协议)。
管理的可扩展性 (在任何地方的任何人都可以立即进行安全通信)。
适应性 (能够支持当前最知名的安全方法)。
在社会上的可行性 (满足社会的政治文化需要)。
在这个数字加密技术的入门介绍中，我们会讨论以下内容。
密钥：改变密码行为的数字化参数。
对称密钥加密系统：编 / 解码使用相同密钥的算法。
不对称密钥加密系统：编 / 解码使用不同密钥的算法。
公开密钥加密系统：一种能够使数百万计算机便捷地发送机密报文的系统。
数字签名：用来验证报文未被伪造或篡改的校验和。
数字证书：由一个可信的组织验证和签发的识别信息。
密码学基于一种名为密码(cipher)的秘密代码。密码是一套编码方案——一种特 殊的报文编码方式和一种稍后使用的相应解码方式的结合体。加密之前的原始报文通常被称为 明文(plaintext 或 cleartext)。使用了密码之后的编码报文通常被称作 密文(ciphertext)。
用密码来生成保密信息已经有数千年了。传说 尤利乌斯·凯撒(Julius Caesar) 曾使用过一种三字符循环移位密码，报文中的每个字符都由字母表中三个位置之后的字符来取代。在现代的字母表中，“A”就应该由“D”来取代，“B”就应该由“E” 来取代，以此类推。
随着技术的进步，人们开始制造一些机器，这些机器可以用复杂得多的密码来快速、 精确地对报文进行编解码。这些密码机不仅能做一些简单的旋转，它们还可以替换 字符、改变字符顺序，将报文切片切块，使代码的破解更加困难。
往往在现实中，编码算法和编码机都可能会落入敌人的手中，所以大部分机器上都有一些号盘，可以将其设置为大量不同的值以改变密码的工作方式。即使机器被盗，没有正确的号盘设置(密钥值)，解码器也无法工作。
这些密码参数被称为 密钥(key)
cipher と呼ばれる秘密コードに基づいています。暗号は、メッセージをエンコードする特定の方法と、後でそれをデコードする対応する方法の組み合わせであるエンコード スキームです。暗号化前の元のメッセージは通常、平文 (平文または平文) と呼ばれます。パスワードを使用した後のエンコードされたメッセージは、通常、ciphertext と呼ばれます。 🎜🎜パスワードは何千年もの間、機密情報を生成するために使用されてきました。伝説によれば、Julius Caesar は、メッセージ内の各文字をアルファベットの 3 つ後の文字に置き換える 3 文字の循環シフト暗号を使用しました。現代のアルファベットでは、「A」は「D」に、「B」は「E」に置き換えられます。 🎜keysと呼ばれます。復号化プロセスを正しく進めるには、正しいキーを暗号化マシンに入力する必要があります。暗号キーを使用すると、暗号マシンが複数の仮想暗号マシンであるかのように見え、それぞれが異なるキー値を持つため、動作も異なります。 🎜🎜平文メッセージ P、符号化関数 E、およびデジタル符号化キー e が与えられると、符号化された暗号文 C を生成できます。復号関数 D と復号鍵 d により、暗号文 C を元の平文 P に復号できます。もちろん、エンコード/デコード関数は相互の逆関数です。P のエンコードをデコードすると、元のメッセージ P に戻ります。 🎜🎜🎜🎜🎜🎜 多くのデジタル暗号化アルゴリズムは、エンコード時とデコード時に同じキー値を使用するため、対称キー暗号化テクノロジーと呼ばれます。これらを総称してキー k と呼びます。 对称密钥(symmetric-key) 加密技术，这是因为它们在编码时使用的密钥值和解码时 一样(e=d)。我们就将其统称为密钥 k。
流行的对称密钥加密算法包括：DES、Triple-DES、RC2 和 RC4。
保持密钥的机密状态是很重要的。在很多情况下，编 / 解码算法都是众所周知的，因此密钥就是唯一保密的东西了。好的加密算法会迫使攻击者试遍每一个可能的密钥，才能破解代码。用暴力去尝试 所有的密钥值称为 枚举攻击(enumeration attack)。
对称密钥加密技术的缺点之一就是发送者和接收者在互相对话之前，一定要有一个共享的保密密钥。
比如 Alice(A)、Bob(B)和 Chris(C)都想与 Joe 的 五金商店(J) 对话。A、B 和 C 都要建立自己与 J 之间的保密密钥。A 可能需要密钥 KAJ，B 可能需要密钥 KBJ，C 可能需要密钥 KCJ。每对通信实体都需要自己的私有密钥。如果有 N 个节点， 每个节点都要和其他所有 N-1 个节点进行安全对话，总共大概会有 N2 个保密密钥: 这将是一个管理噩梦。
公开密钥加密技术没有为每对主机使用单独的加密 / 解密密钥，而是使用了两个非对称密钥：一个用来对主机报文编码，另一个用来对主机报文解码。
所有公开密钥非对称加密系统所面临的共同挑战是，要确保即便有人拥有了下面所有的线索，也无法计算出保密的私有密钥:
公开密钥 (是公有的，所有人都可以获得);
一小片拦截下来的密文 (可通过对网络的嗅探获取);
一条报文及与之相关的密文 (对任意一段文本运行加密器就可以得到)。
RSA算法 就是一个满足了所有这些条件的流行的公开密钥加密系统，它是在 MIT 发明的，后来由 RSA 数据安全公司将其商业化。即使有了公共密钥、任意一段明文、用公共密钥对明文编码之后得到的相关密文、RSA 算法自身，甚至 RSA 实现 的源代码，破解代码找到相应的私有密钥的难度仍相当于对一个极大的数进行质因数分解的困难程度，这种计算被认为是所有计算机科学中最难的问题之一。因此， 如果你发现了一种能够快速地将一个极大的数字分解为质因数的方法，就不仅能够入侵瑞士银行的账户系统，而且还可以获得图灵奖了。
任何人只要知道了其公开密钥，就可以向一台公共服务器发送安全报文，所以非对称的公开密钥加密系统是很好用的。两个节点无须为了进行安全的通信而先交换私有密钥。
但公开密钥加密算法的计算可能会很慢。实际上它混合使用了对称和非对称策略。 比如，比较常见的做法是在两节点间通过便捷的公开密钥加密技术建立起安全通信， 然后再用那条安全的通道产生并发送临时的随机对称密钥，通过更快的对称加密技 术对其余的数据进行加密。（SSH和HTTPS都是这样的）
除了加 / 解密报文之外，还可以用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证明报文未被篡改过。这种技术被称为数字签名(digital signing)。
数字签名是附加在报文上的特殊加密校验码。数字签名通常是用 非对称公开密钥
一般的な対称キー暗号化アルゴリズムには次のものがあります:DES 、Triple-DES、RC2、および RC4。
鍵を秘密にしておくことが重要です。多くの場合、エンコード/デコードのアルゴリズムはよく知られているため、秘密にされるのはキーだけです。優れた暗号化アルゴリズムでは、攻撃者はコードを解読する前に、考えられるすべてのキーを試行する必要があります。ブルートフォースを使用してすべてのキー値を試すことは、列挙攻撃と呼ばれます。 欠点
対称キー暗号化テクノロジーの欠点の 1 つは、送信者と受信者が相互に通信する前に を持っている必要があることです。 たとえば、アリス (A)、ボブ (B)、クリス (C) は全員、ジョーの金物店 (J) と話したいと考えています。 A、B、C はすべて、J との間で秘密鍵を確立する必要があります。 A はキー KAJ を必要とし、B はキー KBJ を必要とし、C はキー KCJ を必要とする場合があります。通信エンティティの各ペアには、独自の秘密キーが必要です。 N 個のノードがある場合、各ノードは他の N-1 個のノードすべてと安全に通信する必要があり、合計で約 N2 個の秘密鍵が存在することになり、これは
管理の悪夢🎜になります。 🎜🎜公開キー暗号化🎜🎜 ホストのペアごとに個別の暗号化/復号化キーを使用する代わりに、公開キー暗号化では 2 つの非対称キー を使用します: 🎜 1 つはホスト メッセージのエンコード用、もう 1 つは次の目的で使用されます。ホストメッセージをデコードします🎜。 🎜🎜RSA🎜🎜 すべての公開鍵非対称暗号化システムが直面する共通の課題は、たとえ誰かが次のすべての手がかりを持っていたとしても、秘密の秘密鍵を計算できないようにすることです: 🎜署名 し、誰がメッセージを書いたかを示し、証明することもできます。メッセージが改ざんされていないことを確認します。このテクノロジーは、デジタル署名と呼ばれます。 🎜🎜🎜デジタル署名は、メッセージ🎜に添付される特別な暗号化された検証コードです。デジタル署名は通常、非対称公開キー テクノロジーを使用して生成されます。秘密キーは所有者だけが知っているため、作成者の秘密キーは一種の「指紋」として使用できます。 🎜🎜🎜🎜🎜🎜🎜🎜 RSA 暗号化システムは、D が入力として秘密鍵を使用しているため、復号化関数 D を署名関数として使用します。デコード関数は単なる関数であるため、任意の入力で使用できることに注意してください。同様に、RSA 暗号化システムでは、D 関数と E 関数は、どの順序で適用されても互いに打ち消し合います。したがって、D(E(stuff)) = 物と同様に、E(D(stuff)) = 物です。 🎜🎜🎜注意🎜🎜🎜秘密鍵と公開鍵はペアであり、両方とも暗号化および復号化でき、ペアで使用できます🎜。 RSA の原理は、2 つの大きな素数 (p, q) の積 (n) は逆に解くのが難しいため、pq は等価であり、公開鍵と秘密鍵も等価であるということです。 🎜秘密鍵の暗号化と公開鍵の復号化は、「秘密鍵の所有者」の一意の身元を証明することができ、署名に使用されます。
公開鍵暗号化と秘密鍵復号化により、送信された情報は「秘密鍵所有者」のみが復号化できるようになります（データの暗号化と送信に秘密鍵が使用されている場合、公開鍵所有者によって復号化されます） (所有者が多数いる可能性があります) 誰かが) 復号化して情報の保護を失います)
インターネット上の「ID カード」 - デジタル証明書。 デジタル証明書 (証明書造幣局に似ており、「証明書」と呼ばれることが多い) には、信頼できる組織によって保証されているユーザーまたは会社に関する情報が含まれています。 数字证书(通常被称作“certs”，有点像 certs 牌薄荷糖)中包含了由某个受信任组织担保的用户或公司的相关信息。
数字证书中还包含一组信息，所有这些信息都是由一个官方的 证书颁发机构(CA) 以数字方式签发的。
而且，数字证书通常还包括对象的公开密钥，以及对象和所用签名算法的描述性信息。任何人都可以创建一个数字证书，但并不是所有人都能够获得受人尊敬的签发 权，从而为证书信息担保，并用其私有密钥签发证书。典型的证书结构如图所示。
不幸的是，数字证书没有单一的全球标准。就像不是所有印刷版 ID 卡都在同样的位 置包含了同样的信息一样，数字证书也有很多略有不同的形式。 不过好消息就是现 在使用的大多数证书都以一种标准格式—— X.509 v3，来存储它们的信息。X.509 v3 证书提供了一种标准的方式，将证书信息规范至一些可解析字段中。不同类型的证 书有不同的字段值，但大部分都遵循X.509 v3结构。
基于 X.509 证书的签名有好几种，(其中)包括 Web 服务器证书、客户端电子邮件 证书、软件代码签名证书和证书颁发机构证书。
通过 HTTPS 建立了一个安全 Web 事务之后，现代的浏览器都会自动获取所连接服 务器的数字证书。如果服务器没有证书，安全连接就会失败。
浏览器收到证书时会对签名颁发机构进行检查。如果这个机构是个很有权威的公共签名机构，浏览器可能已经知道其公开密钥了(浏览器会预先安装很多签名颁发机构的证书)。
如果对签名颁发机构一无所知，浏览器就无法确定是否应该信任这个签名颁发机构， 它通常会向用户显示一个对话框，看看他是否相信这个签名发布者。签名发布者可 能是本地的 IT 部门或软件厂商。
HTTPS 是最流行的 HTTP 安全形式。它是由网景公司首创的，所有主要的浏览器和 服务器都支持此协议。
使用 HTTPS 时，所有的 HTTP 请求和响应数据在发送到网络之前，都要进行加密。 HTTPS 在 HTTP 下面提供了一个传输级的密码安全层——可以使用 SSL，也可以使用其后继者—— 传输层安全(Transport Layer Security，TLS)。由于 SSL 和 TLS 非常类似，所以我们不太严格地用术语 SSL 来表示 SSL 和 TLS。
不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。
窃听风险（eavesdropping）：第三方可以获知通信内容。
篡改风险（tampering）：第三方可以修改通信内容。
冒充风险（pretending）：第三方可以冒充他人身份参与通信。
SSL/TLS协议是为了解决这三大风险而设计的，希望达到：
所有信息都是加密传播，第三方无法窃听。
具有校验机制，一旦被篡改，通信双方会立刻发现。
配备身份证书，防止身份被冒充。
SSL（Secure Socket Layer）是安全套接层，TLS（Transport Layer Security）是传输层安全协议
認証局 (CA) によってデジタル的に発行されます。 さらに、デジタル証明書には通常、オブジェクトの公開鍵に加え、オブジェクトと使用される署名アルゴリズムに関する説明情報も含まれます。デジタル証明書は誰でも作成できますが、誰もが証明書情報を保証し、秘密キーを使用して証明書を発行する尊敬される発行機関を持っているわけではありません。典型的な証明書の構造を図に示します。 
X.509 v3証明書
🎜残念ながら、デジタル証明書には単一の世界標準はありません。すべての印刷された ID カードに同じ場所に同じ情報が含まれているわけではないのと同様に、デジタル証明書にもわずかに異なる形式が多数あります。 しかし幸いなことに、現在使用されているほとんどの証明書は、情報を標準形式X.509 v3 で保存しています。 X.509 v3 証明書は、証明書情報を多数の解析可能なフィールドに形式化する標準的な方法を提供します。証明書の種類が異なればフィールド値も異なりますが、ほとんどは X.509 v3 構造に従います。 🎜🎜X.509 証明書に基づく署名には、Web サーバー証明書、クライアント電子メール証明書、ソフトウェア コード署名証明書、認証局証明書など、いくつかの種類があります。 🎜🎜証明書を使用してサーバーを認証する🎜🎜 HTTPS を介して安全な Web トランザクションを確立した後、最新のブラウザは接続されたサーバーのデジタル証明書を自動的に取得します。サーバーに証明書がない場合、安全な接続は失敗します。 🎜🎜ブラウザは証明書を受け取るときに署名機関を確認します。この組織が非常に権威のある公開署名機関である場合、ブラウザはその公開鍵をすでに知っている可能性があります (ブラウザには多くの署名機関からの証明書がプリインストールされています)。 🎜🎜 署名機関について何も知らない場合、ブラウザはその署名機関を信頼すべきかどうかを判断できず、通常は、ユーザーが署名発行者を信頼するかどうかを確認するダイアログ ボックスを表示します。署名の発行者は、地元の IT 部門またはソフトウェア ベンダーである場合があります。 🎜🎜HTTPS🎜🎜HTTPS は、HTTP セキュリティの最も一般的な形式です。 Netscape によって先駆的に開発され、すべての主要なブラウザとサーバーでサポートされています。 🎜🎜 HTTPS を使用する場合、すべての HTTP リクエストと応答データはネットワークに送信される前に暗号化されます。 HTTPS は、SSL またはその後継である Transport Layer Security (TLS) を使用して、HTTP の下にトランスポート レベルの暗号化セキュリティ層を提供します。 SSL と TLS は非常に似ているため、SSL と TLS の両方を指すために、SSL という用語をあまり厳密に使用しません。 🎜🎜🎜🎜🎜🎜SSL/TLS🎜🎜SSL/TLSを使用しないでくださいHTTP通信は暗号化されない通信です。平文で拡散されるすべての情報には 3 つの大きなリスクが伴います。 🎜盗聴のリスク (盗聴): 通信内容が第三者に知られる可能性があります。 🎜🎜🎜🎜改ざん: 第三者が通信内容を変更する可能性があります。 🎜🎜🎜🎜ふり: 第三者は、他人になりすまして通信に参加できます。 🎜🎜SSL (Secure Socket Layer) はセキュア ソケット レイヤ、TLS (Transport Layer Security) はトランスポート レイヤ セキュリティ プロトコルで、SSL3 に基づいて構築されています。 .0 プロトコル仕様。SSL3.0 の後継バージョンです。 SSL は、バージョン 3.0 までは大規模に展開および適用されませんでした。 TLS バージョンと SSL の明らかな違いは、サポートされる暗号化アルゴリズムが異なることです。現在使用されている最新のプロトコルは TLS1.2 プロトコルです。バージョン 1.3 はまだドラフト段階です。 🎜🎜🎜🎜🎜🎜🎜 HTTPS スキーム 🎜🎜 セキュア HTTP はオプションになりました。クライアント (Web ブラウザーなど) に Web リソース上でトランザクションを実行するようリクエストすると、URL スキームがチェックされます: 🎜URL スキームが http の場合、クライアントはサーバー ポート 80 (デフォルト) への接続を開き、古い HTTP コマンドを送信します。
URL スキームが https の場合、クライアントはサーバー ポート 443 (デフォルト) への接続を開き、サーバーと「ハンドシェイク」し、いくつかの SSL セキュリティ パラメーターをバイナリ形式でサーバーと交換し、暗号化を付加します。 HTTPコマンド。
SSL は HTTP とは完全に異なるバイナリ プロトコルであり、そのトラフィックは別のポートで伝送されます (SSL は通常、ポート 443 で伝送されます)。 SSL トラフィックと HTTP トラフィックの両方がポート 80 に到着すると、ほとんどの Web サーバーはバイナリ SSL トラフィックを不正な HTTP として解釈し、接続を閉じます。セキュリティ サービスを HTTP 層にさらに統合すると、複数の宛先ポートを使用する必要がなくなり、実際には深刻な問題は発生しません。
暗号化通信を開始する前に、クライアントとサーバーはまず接続を確立し、パラメータを交換する必要があります。このプロセスはハンドシェイクと呼ばれます。クライアントの名前をアリス、サーバーの名前をボブとすると、ハンドシェイク プロセス全体を次の図で示すことができます。
ハンドシェイクフェーズは 5 つのステップに分かれています:
Alice はプロトコルのバージョン番号、クライアントが生成した 乱数 (クライアントランダム)、およびサポートされている暗号化を与えます。クライアントメソッド。 随机数（Client random），以及客户端支持的加密方法。
鲍勃确认双方使用的加密方法，并给出数字证书、以及一个 服务器生成的随机数（Server random）。
爱丽丝确认数字证书有效，然后生成一个新的 随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成 对话密钥（session key），用来加密接下来的整个对话过程。
上面的五步，画成一张图，就是下面这样：
握手阶段有三点需要注意：
生成对话密钥一共需要三个随机数。
握手之后的对话使用 对话密钥（session key） 加密（对称加密），服务器的公钥和私钥只用于加密和解密 对话密钥（session key）（非对称加密），无其他作用。
服务器公钥放在服务器的数字证书之中。
整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于 第三个随机数（Premaster secret）能不能被破解。
虽然理论上，只要服务器的公钥足够长（比如2048位），那么 Premaster secret 可以保证不被破解。但是为了足够安全，我们可以考虑把握手阶段的算法从默认的 RSA算法，改为 Diffie-Hellman算法（简称DH算法）。
采用 DH算法 后，Premaster secret 不需要传递，双方只要交换各自的参数，就可以算出这个随机数。
上图中，第三步和第四步由传递 Premaster secret 变成了传递 DH算法 所需的参数，然后双方各自算出 Premaster secret。这样就提高了安全性。
SSL 支持双向认证，将服务器证书承载回客户端，再将客户端的证书回送给服务器。 而现在，浏览时并不经常使用客户端证书。大部分用户甚至都没有自己的客户端证书。服务器可以要求使用客户端证书，但实际中很少出现这种情况。
SSL 自身不要求用户检查 Web 服务器证书，但大部分现代浏览器都会对证书进行简 单的完整性检查，并为用户提供进行进一步彻查的手段。网景公司提出的一种 Web 服务器证书有效性算法是大部分浏览器有效性验证技术的基础。验证步骤如下所述：
日期检测
サーバーによって生成された乱数 (サーバーランダム) を渡しました。 🎜🎜🎜🎜アリスはデジタル証明書が有効であることを確認し、新しい乱数 (プレマスター シークレット) を生成し、デジタル証明書内の公開キーを使用して乱数を暗号化し、それをボブに送信します。 。 🎜🎜🎜🎜ボブは秘密鍵を使用して、アリスから送信された乱数を取得します (つまり、Premaster Secret)。 🎜🎜🎜🎜アリスとボブは、前の 3 つの乱数を使用して、合意された暗号化方式に従って セッション キー を生成します。このキーは、その後の会話プロセス全体の暗号化に使用されます。 🎜🎜🎜上記の 5 つのステップを図に描くと次のようになります: 🎜🎜🎜
🎜🎜🎜ハンドシェイクフェーズ中に注意すべき点が 3 つあります: 🎜🎜🎜🎜 会話キーを生成するには、合計 3 つの乱数が必要です。 🎜🎜🎜🎜ハンドシェイク後の会話は、セッション キーを使用して暗号化されます (対称暗号化)。サーバーの公開キーと秘密キーは、セッション キーの暗号化と復号化にのみ使用されます。 /code> (非対称暗号化)、その他の効果はありません。 🎜🎜🎜🎜サーバーの公開キーはサーバーのデジタル証明書に配置されます。 🎜🎜🎜DH アルゴリズムのハンドシェイク フェーズ🎜🎜 ハンドシェイク フェーズ全体は暗号化されておらず (暗号化することもできません)、すべて平文です。したがって、誰かが通信を盗聴した場合、両者が選択した暗号化方式と、3 つの乱数のうち 2 つを知ることができます。通話全体のセキュリティは、<code>3 番目の乱数 (プレマスター シークレット) を解読できるかどうかにのみ依存します。 🎜🎜理論上は、サーバーの公開キーが十分に長い (たとえば、2048 ビット) 限り、Premaster Secret は解読されないことが保証されます。しかし、十分な安全性を確保するために、ハンドオーバー段階でアルゴリズムをデフォルトの RSA アルゴリズムから Diffie-Hellman アルゴリズム (略して DH アルゴリズム) に変更することを検討できます。 🎜🎜 DH アルゴリズム を使用した後は、Premaster Secret を渡す必要はありません。乱数を計算するために、両者は独自のパラメータを交換するだけで済みます。 🎜🎜🎜🎜🎜🎜上の図では、3番目と4番目のステップからPremaster Secret を渡し、DH アルゴリズム で必要なパラメータを渡すと、両者が個別に Premaster Secret を計算します。これによりセキュリティが向上します。 🎜🎜サーバー証明書🎜🎜 SSL は双方向認証をサポートしており、サーバー証明書をクライアントに送り返し、次にクライアントの証明書をサーバーに送り返します。 現在、ブラウジング時にクライアント証明書が使用されることはほとんどありません。ほとんどのユーザーは自分のクライアント証明書さえ持っていません。サーバーはクライアント証明書を必要とする場合がありますが、実際にはこれが必要になることはほとんどありません。 🎜🎜サイト証明書の有効性🎜🎜 SSL 自体はユーザーに Web サーバー証明書を確認する必要はありませんが、最新のブラウザーのほとんどは証明書の簡単な整合性チェックを実行し、ユーザーにさらなる調査を行う手段を提供します。 Netscape によって提案された Web サーバー証明書の有効性アルゴリズムは、ほとんどのブラウザーの有効性検証テクノロジの基礎になっています。検証手順は以下で説明されています: 🎜🎜🎜🎜日付検出 まず、ブラウザは証明書の開始日と終了日をチェックして、証明書がまだ有効であることを確認します。証明書の有効期限が切れているか、アクティブ化されていない場合、証明書の有効性の検証は失敗し、ブラウザにエラー メッセージが表示されます。 🎜
签名颁发者可信度检测 每个证书都是由某些 证书颁发机构(CA) 签发的，它们负责为服务器担保。证书有不同的等级，每种证书都要求不同级别的背景验证。比如，如果申请某个电 子商务服务器证书，通常需要提供一个营业的合法证明。
任何人都可以生成证书，但有些 CA 是非常著名的组织，它们通过非常清晰的流 程来验证证书申请人的身份及商业行为的合法性。因此，浏览器会附带一个签名颁发机构的受信列表。如果浏览器收到了某未知(可能是恶意的)颁发机构签发的证书，那它通常会显示一条警告信息。
签名检测 一旦判定签名授权是可信的，浏览器就要对签名使用签名颁发机构的公开密钥， 并将其与校验码进行比较，以查看证书的完整性。
站点身份检测 为防止服务器复制其他人的证书，或拦截其他人的流量，大部分浏览器都会试着 去验证证书中的域名与它们所对话的服务器的域名是否匹配。服务器证书中通常 都包含一个域名，但有些 CA 会为一组或一群服务器创建一些包含了服务器名称 列表或通配域名的证书。如果主机名与证书中的标识符不匹配，面向用户的客户 端要么就去通知用户，要么就以表示证书不正确的差错报文来终止连接。
SSL 是个复杂的二进制协议。除非你是密码专家，否则就不应该直接发送原始的 SSL 流量。幸运的是，借助一些商业或开源的库，编写 SSL 客户端和服务器并不十 分困难。
OpenSSL 是 SSL 和 TLS 最常见的开源实现。OpenSSL 项目由一些志愿者合作开发， 目标是开发一个强壮的、具有完备功能的商业级工具集，以实现 SSL 和 TLS 协议以 及一个全功能的通用加密库。可以从 http://www.openssl.org 上获得 OpenSSL 的相 关信息，并下载相应软件。
强烈推荐一本书：HTTP 权威指南
超详解析 | CDN HTTPS优化实践，全网一分钟生效
图解SSL/TLS协议
HTTP 权威指南
記事は Github/ブログと同期されます
人々はいくつかの非常に重要なことを処理するために Web トランザクションを使用します。強力なセキュリティ保証がなければ、人々は安心してオンライン ショッピングや銀行取引を行うことができません。企業は、アクセスを厳しく制限せずに重要なドキュメントを Web サーバーに置くことはできません。 Web には安全な形式の HTTP が必要です。
現在、いくつかの 認証の提供 (Basic 認証 および Digest 認証) と メッセージ整合性チェック (概要 A qop="auth-int" への軽量アプローチ)。これらの方法は、多くのネットワーク トランザクションにはうまく機能しますが、大規模なショッピング、銀行取引、または機密データへのアクセスには十分強力ではありません。これらのより重要なトランザクションでは、セキュリティを確保するために HTTP とデジタル暗号化を組み合わせる必要があります。 提供认证(基本认证和 摘要认证 )和报文完整性检查(摘要 qop="auth-int")的轻量级方法。对很多网络事务来说，这些方法都是很好用的， 但对大规模的购物、银行事务，或者对访问机密数据来说，并不足够强大。这些更 为重要的事务需要将 HTTP 和数字加密技术结合起来使用，才能确保安全。
HTTP 的安全版本要高效、可移植且易于管理，不但能够适应不断变化的情况而且还应 该能满足社会和政府的各项要求。我们需要一种能够提供下列功能的 HTTP 安全技术。
服务器认证 (客户端知道它们是在与真正的而不是伪造的服务器通话)。
客户端认证 (服务器知道它们是在与真正的而不是伪造的客户端通话)。
完整性 (客户端和服务器的数据不会被修改)。
加密 (客户端和服务器的对话是私密的，无需担心被窃听)。
效率 (一个运行的足够快的算法，以便低端的客户端和服务器使用)。
普适性 (基本上所有的客户端和服务器都支持这些协议)。
管理的可扩展性 (在任何地方的任何人都可以立即进行安全通信)。
适应性 (能够支持当前最知名的安全方法)。
在社会上的可行性 (满足社会的政治文化需要)。
在这个数字加密技术的入门介绍中，我们会讨论以下内容。
密钥：改变密码行为的数字化参数。
对称密钥加密系统：编 / 解码使用相同密钥的算法。
不对称密钥加密系统：编 / 解码使用不同密钥的算法。
公开密钥加密系统：一种能够使数百万计算机便捷地发送机密报文的系统。
数字签名：用来验证报文未被伪造或篡改的校验和。
数字证书：由一个可信的组织验证和签发的识别信息。
密码学基于一种名为密码(cipher)的秘密代码。密码是一套编码方案——一种特 殊的报文编码方式和一种稍后使用的相应解码方式的结合体。加密之前的原始报文通常被称为 明文(plaintext 或 cleartext)。使用了密码之后的编码报文通常被称作 密文(ciphertext)。
用密码来生成保密信息已经有数千年了。传说 尤利乌斯·凯撒(Julius Caesar) 曾使用过一种三字符循环移位密码，报文中的每个字符都由字母表中三个位置之后的字符来取代。在现代的字母表中，“A”就应该由“D”来取代，“B”就应该由“E” 来取代，以此类推。
随着技术的进步，人们开始制造一些机器，这些机器可以用复杂得多的密码来快速、 精确地对报文进行编解码。这些密码机不仅能做一些简单的旋转，它们还可以替换 字符、改变字符顺序，将报文切片切块，使代码的破解更加困难。
往往在现实中，编码算法和编码机都可能会落入敌人的手中，所以大部分机器上都有一些号盘，可以将其设置为大量不同的值以改变密码的工作方式。即使机器被盗，没有正确的号盘设置(密钥值)，解码器也无法工作。
这些密码参数被称为 密钥(key)
cipher と呼ばれる秘密コードに基づいています。暗号は、メッセージをエンコードする特定の方法と、後でそれをデコードする対応する方法の組み合わせであるエンコード スキームです。暗号化前の元のメッセージは通常、平文 (平文または平文) と呼ばれます。パスワードを使用した後のエンコードされたメッセージは、通常、ciphertext と呼ばれます。 🎜🎜パスワードは何千年もの間、機密情報を生成するために使用されてきました。伝説によれば、Julius Caesar は、メッセージ内の各文字をアルファベットの 3 つ後の文字に置き換える 3 文字の循環シフト暗号を使用しました。現代のアルファベットでは、「A」は「D」に、「B」は「E」に置き換えられます。 🎜keysと呼ばれます。復号化プロセスを正しく進めるには、正しいキーを暗号化マシンに入力する必要があります。暗号キーを使用すると、暗号マシンが複数の仮想暗号マシンであるかのように見え、それぞれが異なるキー値を持つため、動作も異なります。 🎜🎜平文メッセージ P、符号化関数 E、およびデジタル符号化キー e が与えられると、符号化された暗号文 C を生成できます。復号関数 D と復号鍵 d により、暗号文 C を元の平文 P に復号できます。もちろん、エンコード/デコード関数は相互の逆関数です。P のエンコードをデコードすると、元のメッセージ P に戻ります。 🎜🎜🎜🎜🎜🎜 多くのデジタル暗号化アルゴリズムは、エンコード時とデコード時に同じキー値を使用するため、対称キー暗号化テクノロジーと呼ばれます。これらを総称してキー k と呼びます。 对称密钥(symmetric-key) 加密技术，这是因为它们在编码时使用的密钥值和解码时 一样(e=d)。我们就将其统称为密钥 k。
流行的对称密钥加密算法包括：DES、Triple-DES、RC2 和 RC4。
保持密钥的机密状态是很重要的。在很多情况下，编 / 解码算法都是众所周知的，因此密钥就是唯一保密的东西了。好的加密算法会迫使攻击者试遍每一个可能的密钥，才能破解代码。用暴力去尝试 所有的密钥值称为 枚举攻击(enumeration attack)。
对称密钥加密技术的缺点之一就是发送者和接收者在互相对话之前，一定要有一个共享的保密密钥。
比如 Alice(A)、Bob(B)和 Chris(C)都想与 Joe 的 五金商店(J) 对话。A、B 和 C 都要建立自己与 J 之间的保密密钥。A 可能需要密钥 KAJ，B 可能需要密钥 KBJ，C 可能需要密钥 KCJ。每对通信实体都需要自己的私有密钥。如果有 N 个节点， 每个节点都要和其他所有 N-1 个节点进行安全对话，总共大概会有 N2 个保密密钥: 这将是一个管理噩梦。
公开密钥加密技术没有为每对主机使用单独的加密 / 解密密钥，而是使用了两个非对称密钥：一个用来对主机报文编码，另一个用来对主机报文解码。
所有公开密钥非对称加密系统所面临的共同挑战是，要确保即便有人拥有了下面所有的线索，也无法计算出保密的私有密钥:
公开密钥 (是公有的，所有人都可以获得);
一小片拦截下来的密文 (可通过对网络的嗅探获取);
一条报文及与之相关的密文 (对任意一段文本运行加密器就可以得到)。
RSA算法 就是一个满足了所有这些条件的流行的公开密钥加密系统，它是在 MIT 发明的，后来由 RSA 数据安全公司将其商业化。即使有了公共密钥、任意一段明文、用公共密钥对明文编码之后得到的相关密文、RSA 算法自身，甚至 RSA 实现 的源代码，破解代码找到相应的私有密钥的难度仍相当于对一个极大的数进行质因数分解的困难程度，这种计算被认为是所有计算机科学中最难的问题之一。因此， 如果你发现了一种能够快速地将一个极大的数字分解为质因数的方法，就不仅能够入侵瑞士银行的账户系统，而且还可以获得图灵奖了。
任何人只要知道了其公开密钥，就可以向一台公共服务器发送安全报文，所以非对称的公开密钥加密系统是很好用的。两个节点无须为了进行安全的通信而先交换私有密钥。
但公开密钥加密算法的计算可能会很慢。实际上它混合使用了对称和非对称策略。 比如，比较常见的做法是在两节点间通过便捷的公开密钥加密技术建立起安全通信， 然后再用那条安全的通道产生并发送临时的随机对称密钥，通过更快的对称加密技 术对其余的数据进行加密。（SSH和HTTPS都是这样的）
除了加 / 解密报文之外，还可以用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证明报文未被篡改过。这种技术被称为数字签名(digital signing)。
数字签名是附加在报文上的特殊加密校验码。数字签名通常是用 非对称公开密钥
一般的な対称キー暗号化アルゴリズムには次のものがあります:DES 、Triple-DES、RC2、および RC4。
鍵を秘密にしておくことが重要です。多くの場合、エンコード/デコードのアルゴリズムはよく知られているため、秘密にされるのはキーだけです。優れた暗号化アルゴリズムでは、攻撃者はコードを解読する前に、考えられるすべてのキーを試行する必要があります。ブルートフォースを使用してすべてのキー値を試すことは、列挙攻撃と呼ばれます。 欠点
対称キー暗号化テクノロジーの欠点の 1 つは、送信者と受信者が相互に通信する前に を持っている必要があることです。 たとえば、アリス (A)、ボブ (B)、クリス (C) は全員、ジョーの金物店 (J) と話したいと考えています。 A、B、C はすべて、J との間で秘密鍵を確立する必要があります。 A はキー KAJ を必要とし、B はキー KBJ を必要とし、C はキー KCJ を必要とする場合があります。通信エンティティの各ペアには、独自の秘密キーが必要です。 N 個のノードがある場合、各ノードは他の N-1 個のノードすべてと安全に通信する必要があり、合計で約 N2 個の秘密鍵が存在することになり、これは
管理の悪夢🎜になります。 🎜🎜公開キー暗号化🎜🎜 ホストのペアごとに個別の暗号化/復号化キーを使用する代わりに、公開キー暗号化では 2 つの非対称キー を使用します: 🎜 1 つはホスト メッセージのエンコード用、もう 1 つは次の目的で使用されます。ホストメッセージをデコードします🎜。 🎜🎜RSA🎜🎜 すべての公開鍵非対称暗号化システムが直面する共通の課題は、たとえ誰かが次のすべての手がかりを持っていたとしても、秘密の秘密鍵を計算できないようにすることです: 🎜署名 し、誰がメッセージを書いたかを示し、証明することもできます。メッセージが改ざんされていないことを確認します。このテクノロジーは、デジタル署名と呼ばれます。 🎜🎜🎜デジタル署名は、メッセージ🎜に添付される特別な暗号化された検証コードです。デジタル署名は通常、非対称公開キー テクノロジーを使用して生成されます。秘密キーは所有者だけが知っているため、作成者の秘密キーは一種の「指紋」として使用できます。 🎜🎜🎜🎜🎜🎜🎜🎜 RSA 暗号化システムは、D が入力として秘密鍵を使用しているため、復号化関数 D を署名関数として使用します。デコード関数は単なる関数であるため、任意の入力で使用できることに注意してください。同様に、RSA 暗号化システムでは、D 関数と E 関数は、どの順序で適用されても互いに打ち消し合います。したがって、D(E(stuff)) = 物と同様に、E(D(stuff)) = 物です。 🎜🎜🎜注意🎜🎜🎜秘密鍵と公開鍵はペアであり、両方とも暗号化および復号化でき、ペアで使用できます🎜。 RSA の原理は、2 つの大きな素数 (p, q) の積 (n) は逆に解くのが難しいため、pq は等価であり、公開鍵と秘密鍵も等価であるということです。 🎜秘密鍵の暗号化と公開鍵の復号化は、「秘密鍵の所有者」の一意の身元を証明することができ、署名に使用されます。
公開鍵暗号化と秘密鍵復号化により、送信された情報は「秘密鍵所有者」のみが復号化できるようになります（データの暗号化と送信に秘密鍵が使用されている場合、公開鍵所有者によって復号化されます） (所有者が多数いる可能性があります) 誰かが) 復号化して情報の保護を失います)
インターネット上の「ID カード」 - デジタル証明書。 デジタル証明書 (証明書造幣局に似ており、「証明書」と呼ばれることが多い) には、信頼できる組織によって保証されているユーザーまたは会社に関する情報が含まれています。 数字证书(通常被称作“certs”，有点像 certs 牌薄荷糖)中包含了由某个受信任组织担保的用户或公司的相关信息。
数字证书中还包含一组信息，所有这些信息都是由一个官方的 证书颁发机构(CA) 以数字方式签发的。
而且，数字证书通常还包括对象的公开密钥，以及对象和所用签名算法的描述性信息。任何人都可以创建一个数字证书，但并不是所有人都能够获得受人尊敬的签发 权，从而为证书信息担保，并用其私有密钥签发证书。典型的证书结构如图所示。
不幸的是，数字证书没有单一的全球标准。就像不是所有印刷版 ID 卡都在同样的位 置包含了同样的信息一样，数字证书也有很多略有不同的形式。 不过好消息就是现 在使用的大多数证书都以一种标准格式—— X.509 v3，来存储它们的信息。X.509 v3 证书提供了一种标准的方式，将证书信息规范至一些可解析字段中。不同类型的证 书有不同的字段值，但大部分都遵循X.509 v3结构。
基于 X.509 证书的签名有好几种，(其中)包括 Web 服务器证书、客户端电子邮件 证书、软件代码签名证书和证书颁发机构证书。
通过 HTTPS 建立了一个安全 Web 事务之后，现代的浏览器都会自动获取所连接服 务器的数字证书。如果服务器没有证书，安全连接就会失败。
浏览器收到证书时会对签名颁发机构进行检查。如果这个机构是个很有权威的公共签名机构，浏览器可能已经知道其公开密钥了(浏览器会预先安装很多签名颁发机构的证书)。
如果对签名颁发机构一无所知，浏览器就无法确定是否应该信任这个签名颁发机构， 它通常会向用户显示一个对话框，看看他是否相信这个签名发布者。签名发布者可 能是本地的 IT 部门或软件厂商。
HTTPS 是最流行的 HTTP 安全形式。它是由网景公司首创的，所有主要的浏览器和 服务器都支持此协议。
使用 HTTPS 时，所有的 HTTP 请求和响应数据在发送到网络之前，都要进行加密。 HTTPS 在 HTTP 下面提供了一个传输级的密码安全层——可以使用 SSL，也可以使用其后继者—— 传输层安全(Transport Layer Security，TLS)。由于 SSL 和 TLS 非常类似，所以我们不太严格地用术语 SSL 来表示 SSL 和 TLS。
不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。
窃听风险（eavesdropping）：第三方可以获知通信内容。
篡改风险（tampering）：第三方可以修改通信内容。
冒充风险（pretending）：第三方可以冒充他人身份参与通信。
SSL/TLS协议是为了解决这三大风险而设计的，希望达到：
所有信息都是加密传播，第三方无法窃听。
具有校验机制，一旦被篡改，通信双方会立刻发现。
配备身份证书，防止身份被冒充。
SSL（Secure Socket Layer）是安全套接层，TLS（Transport Layer Security）是传输层安全协议
認証局 (CA) によってデジタル的に発行されます。 さらに、デジタル証明書には通常、オブジェクトの公開鍵に加え、オブジェクトと使用される署名アルゴリズムに関する説明情報も含まれます。デジタル証明書は誰でも作成できますが、誰もが証明書情報を保証し、秘密キーを使用して証明書を発行する尊敬される発行機関を持っているわけではありません。典型的な証明書の構造を図に示します。
X.509 v3証明書
🎜残念ながら、デジタル証明書には単一の世界標準はありません。すべての印刷された ID カードに同じ場所に同じ情報が含まれているわけではないのと同様に、デジタル証明書にもわずかに異なる形式が多数あります。 しかし幸いなことに、現在使用されているほとんどの証明書は、情報を標準形式X.509 v3 で保存しています。 X.509 v3 証明書は、証明書情報を多数の解析可能なフィールドに形式化する標準的な方法を提供します。証明書の種類が異なればフィールド値も異なりますが、ほとんどは X.509 v3 構造に従います。 🎜🎜X.509 証明書に基づく署名には、Web サーバー証明書、クライアント電子メール証明書、ソフトウェア コード署名証明書、認証局証明書など、いくつかの種類があります。 🎜🎜証明書を使用してサーバーを認証する🎜🎜 HTTPS を介して安全な Web トランザクションを確立した後、最新のブラウザは接続されたサーバーのデジタル証明書を自動的に取得します。サーバーに証明書がない場合、安全な接続は失敗します。 🎜🎜ブラウザは証明書を受け取るときに署名機関を確認します。この組織が非常に権威のある公開署名機関である場合、ブラウザはその公開鍵をすでに知っている可能性があります (ブラウザには多くの署名機関からの証明書がプリインストールされています)。 🎜🎜 署名機関について何も知らない場合、ブラウザはその署名機関を信頼すべきかどうかを判断できず、通常は、ユーザーが署名発行者を信頼するかどうかを確認するダイアログ ボックスを表示します。署名の発行者は、地元の IT 部門またはソフトウェア ベンダーである場合があります。 🎜🎜HTTPS🎜🎜HTTPS は、HTTP セキュリティの最も一般的な形式です。 Netscape によって先駆的に開発され、すべての主要なブラウザとサーバーでサポートされています。 🎜🎜 HTTPS を使用する場合、すべての HTTP リクエストと応答データはネットワークに送信される前に暗号化されます。 HTTPS は、SSL またはその後継である Transport Layer Security (TLS) を使用して、HTTP の下にトランスポート レベルの暗号化セキュリティ層を提供します。 SSL と TLS は非常に似ているため、SSL と TLS の両方を指すために、SSL という用語をあまり厳密に使用しません。 🎜🎜🎜🎜🎜🎜SSL/TLS🎜🎜SSL/TLSを使用しないでくださいHTTP通信は暗号化されない通信です。平文で拡散されるすべての情報には 3 つの大きなリスクが伴います。 🎜盗聴のリスク (盗聴): 通信内容が第三者に知られる可能性があります。 🎜🎜🎜🎜改ざん: 第三者が通信内容を変更する可能性があります。 🎜🎜🎜🎜ふり: 第三者は、他人になりすまして通信に参加できます。 🎜🎜SSL (Secure Socket Layer) はセキュア ソケット レイヤ、TLS (Transport Layer Security) はトランスポート レイヤ セキュリティ プロトコルで、SSL3 に基づいて構築されています。 .0 プロトコル仕様。SSL3.0 の後継バージョンです。 SSL は、バージョン 3.0 までは大規模に展開および適用されませんでした。 TLS バージョンと SSL の明らかな違いは、サポートされる暗号化アルゴリズムが異なることです。現在使用されている最新のプロトコルは TLS1.2 プロトコルです。バージョン 1.3 はまだドラフト段階です。 🎜🎜🎜🎜🎜🎜🎜 HTTPS スキーム 🎜🎜 セキュア HTTP はオプションになりました。クライアント (Web ブラウザーなど) に Web リソース上でトランザクションを実行するようリクエストすると、URL スキームがチェックされます: 🎜URL スキームが http の場合、クライアントはサーバー ポート 80 (デフォルト) への接続を開き、古い HTTP コマンドを送信します。
URL スキームが https の場合、クライアントはサーバー ポート 443 (デフォルト) への接続を開き、サーバーと「ハンドシェイク」し、いくつかの SSL セキュリティ パラメーターをバイナリ形式でサーバーと交換し、暗号化を付加します。 HTTPコマンド。
SSL は HTTP とは完全に異なるバイナリ プロトコルであり、そのトラフィックは別のポートで伝送されます (SSL は通常、ポート 443 で伝送されます)。 SSL トラフィックと HTTP トラフィックの両方がポート 80 に到着すると、ほとんどの Web サーバーはバイナリ SSL トラフィックを不正な HTTP として解釈し、接続を閉じます。セキュリティ サービスを HTTP 層にさらに統合すると、複数の宛先ポートを使用する必要がなくなり、実際には深刻な問題は発生しません。
暗号化通信を開始する前に、クライアントとサーバーはまず接続を確立し、パラメータを交換する必要があります。このプロセスはハンドシェイクと呼ばれます。クライアントの名前をアリス、サーバーの名前をボブとすると、ハンドシェイク プロセス全体を次の図で示すことができます。
ハンドシェイクフェーズは 5 つのステップに分かれています:
Alice はプロトコルのバージョン番号、クライアントが生成した 乱数 (クライアントランダム)、およびサポートされている暗号化を与えます。クライアントメソッド。 随机数（Client random），以及客户端支持的加密方法。
鲍勃确认双方使用的加密方法，并给出数字证书、以及一个 服务器生成的随机数（Server random）。
爱丽丝确认数字证书有效，然后生成一个新的 随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成 对话密钥（session key），用来加密接下来的整个对话过程。
上面的五步，画成一张图，就是下面这样：
握手阶段有三点需要注意：
生成对话密钥一共需要三个随机数。
握手之后的对话使用 对话密钥（session key） 加密（对称加密），服务器的公钥和私钥只用于加密和解密 对话密钥（session key）（非对称加密），无其他作用。
服务器公钥放在服务器的数字证书之中。
整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于 第三个随机数（Premaster secret）能不能被破解。
虽然理论上，只要服务器的公钥足够长（比如2048位），那么 Premaster secret 可以保证不被破解。但是为了足够安全，我们可以考虑把握手阶段的算法从默认的 RSA算法，改为 Diffie-Hellman算法（简称DH算法）。
采用 DH算法 后，Premaster secret 不需要传递，双方只要交换各自的参数，就可以算出这个随机数。
上图中，第三步和第四步由传递 Premaster secret 变成了传递 DH算法 所需的参数，然后双方各自算出 Premaster secret。这样就提高了安全性。
SSL 支持双向认证，将服务器证书承载回客户端，再将客户端的证书回送给服务器。 而现在，浏览时并不经常使用客户端证书。大部分用户甚至都没有自己的客户端证书。服务器可以要求使用客户端证书，但实际中很少出现这种情况。
SSL 自身不要求用户检查 Web 服务器证书，但大部分现代浏览器都会对证书进行简 单的完整性检查，并为用户提供进行进一步彻查的手段。网景公司提出的一种 Web 服务器证书有效性算法是大部分浏览器有效性验证技术的基础。验证步骤如下所述：
日期检测
サーバーによって生成された乱数 (サーバーランダム) を渡しました。 🎜🎜🎜🎜アリスはデジタル証明書が有効であることを確認し、新しい乱数 (プレマスター シークレット) を生成し、デジタル証明書内の公開キーを使用して乱数を暗号化し、それをボブに送信します。 。 🎜🎜🎜🎜ボブは秘密鍵を使用して、アリスから送信された乱数を取得します (つまり、Premaster Secret)。 🎜🎜🎜🎜アリスとボブは、前の 3 つの乱数を使用して、合意された暗号化方式に従って セッション キー を生成します。このキーは、その後の会話プロセス全体の暗号化に使用されます。 🎜🎜🎜上記の 5 つのステップを図に描くと次のようになります: 🎜🎜🎜🎜🎜🎜ハンドシェイクフェーズ中に注意すべき点が 3 つあります: 🎜🎜🎜🎜 会話キーを生成するには、合計 3 つの乱数が必要です。 🎜🎜🎜🎜ハンドシェイク後の会話は、セッション キーを使用して暗号化されます (対称暗号化)。サーバーの公開キーと秘密キーは、セッション キーの暗号化と復号化にのみ使用されます。 /code> (非対称暗号化)、その他の効果はありません。 🎜🎜🎜🎜サーバーの公開キーはサーバーのデジタル証明書に配置されます。 🎜🎜🎜DH アルゴリズムのハンドシェイク フェーズ🎜🎜 ハンドシェイク フェーズ全体は暗号化されておらず (暗号化することもできません)、すべて平文です。したがって、誰かが通信を盗聴した場合、両者が選択した暗号化方式と、3 つの乱数のうち 2 つを知ることができます。通話全体のセキュリティは、<code>3 番目の乱数 (プレマスター シークレット) を解読できるかどうかにのみ依存します。 🎜🎜理論上は、サーバーの公開キーが十分に長い (たとえば、2048 ビット) 限り、Premaster Secret は解読されないことが保証されます。しかし、十分な安全性を確保するために、ハンドオーバー段階でアルゴリズムをデフォルトの RSA アルゴリズムから Diffie-Hellman アルゴリズム (略して DH アルゴリズム) に変更することを検討できます。 🎜🎜 DH アルゴリズム を使用した後は、Premaster Secret を渡す必要はありません。乱数を計算するために、両者は独自のパラメータを交換するだけで済みます。 🎜🎜🎜🎜🎜🎜上の図では、3番目と4番目のステップからPremaster Secret を渡し、DH アルゴリズム で必要なパラメータを渡すと、両者が個別に Premaster Secret を計算します。これによりセキュリティが向上します。 🎜🎜サーバー証明書🎜🎜 SSL は双方向認証をサポートしており、サーバー証明書をクライアントに送り返し、次にクライアントの証明書をサーバーに送り返します。 現在、ブラウジング時にクライアント証明書が使用されることはほとんどありません。ほとんどのユーザーは自分のクライアント証明書さえ持っていません。サーバーはクライアント証明書を必要とする場合がありますが、実際にはこれが必要になることはほとんどありません。 🎜🎜サイト証明書の有効性🎜🎜 SSL 自体はユーザーに Web サーバー証明書を確認する必要はありませんが、最新のブラウザーのほとんどは証明書の簡単な整合性チェックを実行し、ユーザーにさらなる調査を行う手段を提供します。 Netscape によって提案された Web サーバー証明書の有効性アルゴリズムは、ほとんどのブラウザーの有効性検証テクノロジの基礎になっています。検証手順は以下で説明されています: 🎜🎜🎜🎜日付検出 まず、ブラウザは証明書の開始日と終了日をチェックして、証明書がまだ有効であることを確認します。証明書の有効期限が切れているか、アクティブ化されていない場合、証明書の有効性の検証は失敗し、ブラウザにエラー メッセージが表示されます。 🎜
签名颁发者可信度检测 每个证书都是由某些 证书颁发机构(CA) 签发的，它们负责为服务器担保。证书有不同的等级，每种证书都要求不同级别的背景验证。比如，如果申请某个电 子商务服务器证书，通常需要提供一个营业的合法证明。
任何人都可以生成证书，但有些 CA 是非常著名的组织，它们通过非常清晰的流 程来验证证书申请人的身份及商业行为的合法性。因此，浏览器会附带一个签名颁发机构的受信列表。如果浏览器收到了某未知(可能是恶意的)颁发机构签发的证书，那它通常会显示一条警告信息。
签名检测 一旦判定签名授权是可信的，浏览器就要对签名使用签名颁发机构的公开密钥， 并将其与校验码进行比较，以查看证书的完整性。
站点身份检测 为防止服务器复制其他人的证书，或拦截其他人的流量，大部分浏览器都会试着 去验证证书中的域名与它们所对话的服务器的域名是否匹配。服务器证书中通常 都包含一个域名，但有些 CA 会为一组或一群服务器创建一些包含了服务器名称 列表或通配域名的证书。如果主机名与证书中的标识符不匹配，面向用户的客户 端要么就去通知用户，要么就以表示证书不正确的差错报文来终止连接。
SSL 是个复杂的二进制协议。除非你是密码专家，否则就不应该直接发送原始的 SSL 流量。幸运的是，借助一些商业或开源的库，编写 SSL 客户端和服务器并不十 分困难。
OpenSSL 是 SSL 和 TLS 最常见的开源实现。OpenSSL 项目由一些志愿者合作开发， 目标是开发一个强壮的、具有完备功能的商业级工具集，以实现 SSL 和 TLS 协议以 及一个全功能的通用加密库。可以从 http://www.openssl.org 上获得 OpenSSL 的相 关信息，并下载相应软件。
强烈推荐一本书：HTTP 权威指南
超詳細な分析 | CDN HTTPS最適化実践、1分でネットワーク全体に効果的
図解SSL/TLSプロトコル
HTTP権威ガイド
私の記事が役に立ったと思われる場合は、お気軽にありがとうございます
コメント
時間ソート ダウンロード 途中でロード ...
コメントをもっと見る 
以上がHTTPSの詳しい説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
