この章では、HTTPS、HTTPS、どのようにHTTP通信プロセスが存在防ぐためにカモフラージュを使用するには、盗聴、改ざんやその他の問題の基本原則を説明します
、HTTPの欠点
通信プロセスにおけるHTTPは、次の3つのセキュリティ上の問題に直面するだろう。
- クリアテキストを使用して通信は（暗号化されていない）、コンテンツをタップすることができます。
- 通信当事者の身元を確認していない、変装が発生することがあります。
- メッセージの整合性を確認することができません、それが改ざんされた可能性があります。
1.1盗聴
暗号化機能を持っていないHTTP自体は、送信処理が平文で送信されます。
伝送ネットワークので、我々はこれらのデバイスのプロセスでは、多くのネットワーク・ノードや機器を経由して送信情報は、当社の情報を傍受する可能性があるといくつかの一般的に使用されるパケットキャプチャツールを介して直接盗聴することができます盗聴暗号化されていないネットワークトラフィック情報。
盗聴を防ぐために暗号化することにより
（A）は、通信を暗号化：コンテンツ盗聴の送信を防ぐために、我々のアプローチの一つは、トラフィックの暗号化、暗号化HTTP自体がないということですが、我々はできるHTTPとSSL（セキュア・ソケット・レイヤーセキュア・ソケット・レイヤー）またはTLS（トランスポートで組み合わせて使用するSUMMARY暗号化されたHTTPトランスポート・レイヤ・セキュリティ・転送プロトコル、セキュア）。
SSLとのセキュアな通信リンクを確立した後、HTTPトラフィックがこのルートで行うことができます。SSLは、HTTPと呼ばれるHTTPSと組み合わせて使用されている（セキュアHTTP）。
（B）暗号化されたコンテンツ：自体が暗号化された通信のコンテンツに参加する方法があります。この場合には、暗号化要求後にクライアントのHTTPパケットのために必要です。これは、全体の通信回線HTTPS暗号化された形式の方法と異なっているので、内容はまだ改ざんされる危険になります。ので、
1.2変装
誰がサーバに要求を開始することができるようにHTTPプロトコル自体は、認証のための他の通信を持っていません。
これは、セキュリティリスクの様々な存在する可能性がある通信相手を検証しません。
- クライアントは、要求がターゲット・サーバーに送信されたことを確認することができないレスポンスを返すか、サーバがターゲットサーバであるかどうか、それはサーバーを偽装していてもよいです。
- サーバーは、独自のクライアントが要求を開始し、彼自身のクライアントの応答がクライアントのターゲットである返すかを確認することができませんでした。
- 一部のサーバーだけで、特定のユーザーアクセスを与えたいので、通信者がアクセス権を持っているかどうかを確認することができません。
- サーバがDDoS攻撃を受けてもよいようにしても無意味な要求は、受け付けます。
偽造を防ぐために、他のパーティの証明書を識別することにより、
SSL暗号化だけでなく、治療するだけでなく、互いの身元を確認するために使用することができる証明書と呼ばれる手段の使用を提供します。
サーバとクライアントを証明するために、第三者機関によって発行された証明書は、実際に存在しています。
私たちは、通信当事者が証明書を使用してサーバーに期待されていることを証明することができます。ユーザーのために、だけでなく、個人情報の漏洩のリスクを低減します。
また、個人のアイデンティティの認証を完了するためにクライアント証明書の所有者は、サイトへのリンクを認証するために使用することができます。
1.3改ざん
HTTPプロトコルは、通常、透過度情報は、その情報が誤った情報が得られ、精度を失うことになる、改ざんされた、情報の完全性を確認することはできません。たとえば、Webサイト上のリソースをダウンロードしたい、とあなたは、ダウンロード要求を開始するとき、あなたのネットワーク伝送は、他の誰かによってハイジャックされた、あなたは受け取った人材を変更し、あなたは、リソースがあなたではありませんダウンロードされていますことが望ましいです。
したがって、要求または応答の送信は、攻撃者傍受攻撃の内容が改ざんされた時に中間者攻撃（man-in-the-middle攻撃、MITM）と呼ばれます。
改ざんを防止する方法
前の章では、Content-MD5エンティティヘッダフィールドは、しかし、のContent-MD5自体の値も改ざんされる可能性が高いので、フィールドが信頼性がないので、あなたは他の方法を必要とするコンテンツ配信を完全に保証するためにされたエンティティの内容を確認するために使用することができます言及しています改ざんされていません。
他のハッシュアルゴリズムによる送信完了の内容は信頼性がないかどうかを計算するために、我々は最終的に私たちは、この問題を解決するためにHTTPSにする必要があります。SSLは、認証と暗号化だけでなく、提供して要約機能を。
二、HTTPS
HTTPS = HTTP + 加密 + 认证 + 摘要2.1 HTTPSはHTTPのSSLハウジングを身に着けています
HTTPSは、新しいプロトコルのアプリケーション層ではありません。HTTP通信インタフェース部は、単にだけSSLおよびTLSプロトコルを置換します。
通常、HTTPとTCPの直接通信。SSLおよびTCP通信によって第1および上のSSL、SSL通信を使用する場合。だから、要するに、HTTPSはHTTPプロトコルSSLハウジングを着用しています。
SSLを使用した後、HTTPはHTTPSの暗号化、完全性と証明書の保護を持っています。
SSLプロトコルは、HTTPプロトコルとは独立しているので、他のプロトコルも、世界で最も広く使用されているネットワークセキュリティ技術であるSSLプロトコルを使用することができ、
2.2鍵公開鍵暗号技術を交換します
SSL暗号化方式の前にいえば最初の公開鍵暗号（公開鍵暗号）と呼ばれるSSL暗号化処理技術があり、見ることができます。
暗号化の近代的な方法は、暗号化アルゴリズムは公開されているが、鍵は秘密にされています。暗号化と復号化鍵が使用されます。キーなしで鍵を解読することはできません。逆に、キーを取得することができます誰もが情報を復号化します。キーは、攻撃者が取得することで、その暗号化は意味が失われます。
2.2.1共有暗号鍵のジレンマ
同じキーを使用して暗号化と復号化はまた、対称鍵暗号として知られている共通鍵暗号（共通鍵暗号方式）と呼ばれます。
共通鍵暗号の暗号化を使用するときは、キーの当事者との通信に送信する必要があり、その強迫観念鍵暗号方式を共有している安全な鍵を、維持する方法を見つける必要がある、主要な交通機関のセキュリティを考慮する必要があります。
2つの暗号化キー2.2.2を使用して公開鍵暗号方式
問題の公開鍵暗号の良い解決策は、鍵暗号化方式を共有しました。
非対称キーのカップルを使用して公開鍵暗号。一つは、秘密鍵（秘密鍵）と呼ばれ、他の公開鍵（公開鍵）と呼ばれています。名前が示すように、秘密鍵は誰が知ることができない、と公開鍵は、任意の慈悲の広がりは、誰でも取得することができますすることができます。
公開鍵暗号（非対称暗号化）を使用し、片側は、公開鍵を使って暗号化された暗号文を送信し、受信機は、情報が暗号化された後に取得解読するために、自身の秘密鍵を使用しています。このよう伝送では、あなたが鍵を送信しない、キーが離れて攻撃者それについて心配しないでくださいです。
2.2.3 HTTPSの暗号化ハイブリッド
共有暗号化キーと暗号化ミックスの公開鍵暗号方式を使用してHTTPS。
鍵は安全に送信することができた場合は、HTTPSを共有鍵暗号化方式、または公開鍵暗号の使用を使用して検討します。公開鍵暗号方式の速度は共通鍵暗号よりも遅くなるためです。HTTPSは完全に両方の利点、通信のための様々な方法の組み合わせを利用します。公開鍵暗号化鍵の交換の後、情報を送信した後、共通鍵暗号方式を使用して。
2.3は、公開鍵証明書の正しさを証明しました
残念ながら、公開鍵暗号方式自体は欠陥がある、公開鍵自体が本物であることを証明することができません。
上記課題を解決するためには、認証局（CA、認証局）及びその関係機関が発行した公開鍵証明書を使用することができます。
クライアント側とサーバー側でサードパーティの認証局の位置が真で、新しいベリサイン（VeriSign社は）非常によく知られた認証局そのうちの一つです。
私たちは、認証局の業務プロセスを説明下：
まず、サーバの運用スタッフは、公開鍵のデジタル機関に申請するように求められます、申請者の身元認証後に公開鍵CA、アプリケーションがデジタル署名されているでしょうし、署名した後、公開鍵を割り当て、公開鍵は、公開鍵証明書の中に一緒にバインドされています。
CAの公開鍵証明書は、クライアントとの通信のための公開鍵暗号を発行されます、公開鍵証明書は、デジタル証明書または直接呼び出す証明書呼び出すことができます。
受け取った証明書はクライアントが検証されたら、クライアントは二つのことを確認することができ、認証のためのCAの公開鍵デジタル署名証明書を使用することができます。
- 認証サーバの公開鍵メカニズムは、現実と効果的なメカニズムであるCA
- サーバーの公開鍵を信頼することができます
そして、これは、公開鍵本当の有効性を確認する目的を達成します。
安全機関の主要顧客に送信CA困難な作業ですので、ほとんどのブラウザは、一般的に内部公開鍵認証局に移植。
EV SSL証明書は、2.3.1組織の正当性を証明することができます
証明書の機能は、コンプライアンスのための通信サーバに当事者としてそれを証明することで、その他の役割は、サーバオペレータのビジネスは本物であるかどうかを確認することです。公務の信憑性を証明することができ、EV SSL証明書（拡張検証SSL証明書）です。
証明書の目的は、フィッシング攻撃（フィッシング）を防止することです。
クライアントの証明書を確認する2.3.2クライアント
HTTPSは、クライアント証明書を使用してクライアントを認証することができます。
三、セッションとクッキー管理アプリケーション
コンテンツについての章VIIIの話はあまりにも、最も重要な点は、このいずれかのノートに移動しました。
今、主にフォーム認証を使用して、ユーザーIDを認証し、一般的にクッキーセッション（セッション）を管理するために使用されます。
プロセスは、実質的に次のように
次のように具体的な手順は次のとおりです。
- かなりの部分へのクライアント・ユーザーIDパスワードログイン情報パケットは、通常、POSTメソッドを使用してサーバーに送信されました。
- Serverが生成し、セッションIDは、顧客を識別するために使用される問題、セッションIDは、サーバー側で同時に保存され、その後のSet-Cookieフィールドを介してクライアントにバインドされています。ところで、あなたは使用することができ
httponly、クロスサイトスクリプティング攻撃を防ぐためには、JavaScriptがクッキーを変更する無効にするプロパティを。 - クライアントセッションIDは、地元のクッキーに保存され、その後、次の訪問に置かれています。データベースから、受信したセッションIDを検証することによってユーザを識別するために、サーバは、ユーザに関連付けられた一連の情報を取る方法であってもよいです。