「 SSL/TLSはどのように機能するのですか? 」に対する彼の回答では、 Luc がSSLのしくみについて説明しています。
SSL(およびその後継であるTLS)は、TCPの上で直接動作するプロトコルです(ただし、UDPなどのデータグラムベースのプロトコルの実装もあります)。これにより、上位層のプロトコル(安全な接続を提供しながら、HTTPなど)を変更せずにそのままにしておくことができます。SSLレイヤーの下では、HTTPはHTTPSと同じです。
彼の最初の文では、上位層のプロトコルは変更しないでおくことができると述べています。
彼はどういう意味ですか? OSIレイヤーは知っていますが、ここにはいくつかの知識の問題があると思います。
OSIレイヤーはパッケージとして考える必要があります。
グラスを発送したいとしましょう。私は広告目的でオリジナルパッケージを選びました。Niceが私の製品であり、「グラス」体験に追加できるものを示しています。それが私のプロトコルの上位層です。
それから、輸送で壊れないように、柔らかいものを詰めた箱に入れました。これは2番目のレイヤーです。
次に、私の発送部門がこの箱をより大きなパッケージに入れ、ラベルを自宅に発送します。もう一度、別のレイヤー。
次に、輸送業者はこの箱を他の多くの箱が入ったトラックに入れ、運転手に別の配達センター、もう一度別の層に行くように指示します。
私たちが知っていることでは、トラックの運転手は知る必要はありません:
荷物の機密を守りたいとしましょう。好奇心旺盛なドライバーは、パッケージを改ざんして内部を確認したり、パッケージを盗んで再販したりする可能性があるためです。
パッケージのソフトコーティングガラスをロッカー付きの金属製の箱に入れるプロトコルを使用できます。中を覗いたり商品を受け取ったりすることができないため、トラックの運転手による改ざんから保護します。それは下層を保護しません、それでも彼はすべてのフレットを湖に捨てることができました、これはサービス拒否です。さらに、私のロッカーは中身を気にしません。それはあなたのガラスかもしれません、それは花かもしれません、それは空かもしれません。しかし、それはまだあなた(そして荷主)以外の誰かが何が入っているかを知るのを避ける目的を果たします。
OSIのプロトコルについても同様です。下層は上層で何が起こっているかを気にしません。これは、別のエージェントがデコード/処理するために残されます。
明確にするために編集します。「変更しない」と言っても、情報が処理されないという意味ではありません。特にSSLの場合、SSL層のペイロードは上位層のパケットの暗号化です。ただし、SSLが反対側で動作している場合、元のパケットは変更されずに復号化されます。
OSIは単なるモデルであり、実際にはレイヤーが不鮮明または存在しない可能性がありますが、レイヤー化プロトコルの概念は、特定のレイヤーを変更して、上下のレイヤーをそのままにすることです。
例として:
したがって、重要な部分は、各レイヤーが隣接するレイヤーとどのようにインターフェースするかです。
物理的なアイテムを輸送するという@ M'vyの比喩は、ここでは非常に適切です。
TCPはアプリケーションにストリームインターフェイスを提供します。詳細が漏れるいくつかの例外がありますが、一般的にTCPソケットが開かれ、その後、両側が一連のバイトを他方に送信します。これらのバイトはそのまま配信され、順番に、リモートエンドが接続を閉じるまで(通知されます)。アプリケーションは、ストリームインターフェースについて知る必要があるだけです。基盤となるネットワークハードウェアの詳細について知る必要はありません。輻輳制御、ウィンドウサイズ、パケットの再送信、または /パケットがあることを知る必要があります。
TLSはTCPの上に置かれ、認証および暗号化サービスを提供します。また、 /はアプリケーションにストリームインターフェイスを提供します。フードの下で行われている追加の要素、新しい潜在的なエラー条件、およびアプリケーションがソケットをクエリする新しいメタデータ(たとえば、リモート証明書とその発行者に関する情報)はたくさんありますが、基本的な操作は同じです。指定されたアドレスに接続し、バイトを送信し、バイトを受信し、接続を閉じ、リモートで閉じることが通知されます。
これの要点は、TCPによって提供されるストリーム上で動作できるすべてのアプリケーションレベルのプロトコルは、ストリーム上で動作できる also SSLによって提供され、アプリケーション自体に基本的な変更はありません。実際、アプリケーションが使用する暗号化に関する情報、またはリモートパーティの証明書、またはそのいずれかに関する情報を受信することが重要ではないと考えられる場合は、次のようなプロキシを使用できます。 stunnel TLS暗号化接続との変換TCP接続と非暗号化接続。たとえば、クライアントマシンのstunnelは、通常の(非TLSサポート)接続を許可できます。 IMAPサーバーをポイントするメールクライアント_localhost:143
_がIMAPSサーバーに接続する_mymailserver:993
_、またはサーバーマシンのstunnelが_externalip:443
_でHTTPS接続をリッスンし、それらを_internalserver:80
_にプロキシする、それ自体がTLSを実装していなくても、internalserver
(HTTPサーバー)が世界と安全に通信できるようにします。
Http Https
+------------------+ +------------------+
|7 http methods | | http methods | <---same No change needed
+------------------+ +------------------+
|6 data:ex)"$1000" | | data:ex)"kf4d3s1"| <---data encrypted
+------------------+ +------------------+
|5 Sock: | | Sock: |
+------------------+ +------------------+
|4 TCP : | | TCP: |
+------------------+ +------------------+
|3 IP : | | IP : |
+------------------+ +------------------+
|2 PPP: | | PPP: |
+------------------+ +------------------+
|1 RJ45: | | RJ45: |
+------------------+ +------------------+
7. Application Layer -> Http
6. Presentation Layer -> MIME SSL TLS XDR <---- This is what you want
5. Session Layer -> Sockets
4. Transport Layer -> TCP UDP SCTP DCCP
3. Network Layer -> IP IPsec ICMP IGMP OSPF RIP
2. Data link Layer -> PPP,SBTV,SLIP
1. Physical Layer -> FDDI, B8ZS, V.35, V.24, RJ45.
暗号化を追加するための交渉/ハンドシェイクの変更方法のみ。
HTTPSは送信前にHTTPメッセージ(データ)を暗号化し、到着時に復号化します
これは、道路上の車の移動と同じです。道路は固定媒体であり、その上で多くのタイプの車両が走行できるため、道路で走行するための新しい車両を作成する場合、車両はその道路で走行できるタイヤを備えている必要があります。
同様に、イーサネットを1つの媒体と考えると、IPv4やIPv6などのさまざまなネットワークプロトコルを伝送できます。つまり、ここでのポイントは、ネットワークモデルが非常にモジュール化されているため、特定のインターフェイス仕様に準拠している限り、好きなように置き換えることができるということです。
したがって、モジュラー設計では、内部処理が何であれ、何らかの方法で入力が与えられ、次のモジュールで理解できる出力を生成することが重要であることは重要ではないと指定しています。
高レベルのプロトコルは、SSLで変更せずに使用すると安全でない場合があります。サイドチャネル攻撃の可能性があります。
他の人がよく説明したように、SSLを使用すると、暗号化されていないストリームを暗号化されたストリームにラップできます。理論的には、送信されるデータに関する情報が漏洩することはありません。実際には、常に漏洩する1つのデータ、つまり送信されるデータの量があります。
これは許容できるリークのように聞こえますが、場合によってはそうです。ただし、 CRIME攻撃 や このVOIPへの攻撃 など、データが圧縮され、圧縮率が異なるという事実を利用する多くの攻撃があります。メッセージの内容に応じて、メッセージの内容に関する情報を収集します。
リクエストとレスポンスの正確なタイミングなど、他のリークされたデータを使用して、他のサイドチャネル攻撃も可能になる場合があります。
上位層のプロトコルは、下位層の詳細を気にしません。彼らは単に下位層が何らかの方法で実装されていると想定し、そこから進めます。 TCP/IPモデルでは、次の4つの層があります。
OSIは2つのマシンの接続を処理する物理層を定義します。 TCP/IPはサポートしていませんが、ここで考えると便利です。ツイストペア、同軸、CAT6、および電波は、マシンを接続するためのいくつかの一般的な方法ですが、レーザービーム、音波、そしてはい、 キャリアピジョン を含むほとんどすべてのものを使用できます。
2つの直接接続されたマシン間での信号の取得を処理するリンク層。 802.11ファミリ(Wi-Fi)、802.3ファミリ(イーサネット)、およびPPP(モデム)はおそらく今日最も人気のあるリンク層プロトコルですが、他にもあります。
インターネットレイヤー。2つのマシン間で直接接続されていないマシンのチェーンを介して信号を取得します。これは、IPv4とIPv6の両方でIPが存在する場所です。
トランスポート層。信号を使用可能なデータストリームに変換するロジスティックスを処理します。 TCP=およびUDPは、あまり知られていないプロトコルと同様に、ここにあります。
アプリケーション層。トランスポート層によって組み立てられたデータを解釈します。これは、HTTP、FTP、POP、IMAPなど、私たちがよく耳にするほとんどのプロトコルです。
HTTPはアプリケーション層に存在します。これは、互いに直接接続されていない可能性があるマシン間でデータのストリームを取得するための有意義な方法がすでにあることを前提としています。あなたがそれを持っている限り、HTTPはデータストリームがどこから来たかを気にしません。技術的には、基本的なトランスポートでTCP/IPを使用する必要さえありませんが、実際にはほとんど誰もが使用します。
SSL/TLSは毎日の目的でトランスポート層に存在します(問題の技術的な真実はより複雑ですが、エンドユーザーには影響しません) 。つまり、TCP/IPと同様に、送信するデータのストリームを提供し、受信時にデータのストリームを取得します。特に、SSL/TLSはそのデータストリームの内容を気にしません。好きなように渡すことができ、それが機能します。
どちらのレイヤーも他のレイヤーが行うことを気にしないので、自由に入れ替えることができます。 HTTPは、必要なストリームを取得している間は満足です。その間、基礎となるプロトコルがこれらのストリームに対して何をするかは気にしないので、その下で任意のトランスポート層プロトコルを使用できます。 TCP/IP(およびSSL/TLS)は、データの内容を気にしません。ただし、反対側の結果のデータがユーザーが送信したものとまったく同じに見えるようにする必要がある場合を除き、任意のアプリケーションを使用できます。それらとのレイヤープロトコル
OSIレイヤーを知っている
はい、最初の間違いです-しかし、他の回答からわかるように、これはよくある誤解です。 TCP/IPはOSIではありません。これはOSIよりも前から存在していますが、数年前です。そして、それは同じものであることさえ意図していませんでした。 TCP/IPはネットワークプロトコル(の一部の層)であり、OSIは完全なネットワークプロトコルを設計する方法のモデルです。 OSIの観点からTCP/IPを説明しようとすると、すぐに行き詰まってしまいます。 HTTP/2 over TCP/IP? 4つの異なるセッションレイヤー、スタックの少なくとも2つの個別のレイヤーで圧縮が行われます。
SSLまたはTLSは、双方向ストリームインターフェイスを介して非対称通信を実装する方法です。つまり、TCP/IP、IPX/SPX、Unixドメインソケット、(全二重)名前付きパイプ、RS-232で実行できるということです。しかし、最後にTCP/IP以外のデータネットワークを使用したのはいつですか。
LucはSSL/TLSがUDPの上で実行できると言っても間違いはありません。彼は全体の話をしているのではありません。そのようなアーキテクチャの場合、TLSとUDPの間に追加のレイヤーがあり、ストリームの再構成、エラー回復、帯域幅管理を実装しています。