HOME»情報処理安全確保支援士掲示板»平成29年度春 午後2問2
投稿する
特にそんなことはないと思いますが、VPNの技術は複雑なのでややこしい話になりがちですね。
私もVPN技術の理解度は、あまり自信がありません。
基本的にどの方式でも共通している事は以下の通りです
① 元の通信内容をカプセル化してSSL通信のデータ部にそのまま乗っけます（トンネリング）。この通信はSSLの機能によって暗号化されます。
② 通常のインターネット回線を使って、①を相手の拠点のVPN装置に送信します。
③ VPN装置はその通信内容を復号して中身を取り出し、その中身から宛先を調べて本来の相手にその中身を送信（中継）します
なお、インターネット上では通信もアプリケーションもhttpsを使う事が多いからなのか（FWなんかでも追加の設定が要らなくて済む）、多くの製品ではSSL-VPNの方式に関わらず、実際にはhttps通信を用いてSSL-VPNを実現しています（httpのボディ部に元の通信内容を格納してSSL通信で暗号化、つまりhttps通信を行う）
これはブラウザ上で動くWebアプリケーションに使う方式です。イメージ的には社内PCのブラウザから別拠点の社内のサーバにアクセスしている感じでしょうか。通常、PC側は特に問題無くインターネット上のサーバにhttps通信できますが、外部のLANの中でしか公開されていないサーバにはアクセスできません。これを外部LAN側に置かれているVPN装置をリバースプロキシとして動作させる事で、予め決められたユーザのみ、VPN装置を中継する事で外部LAN側の中にあるサーバと通信する事ができます。
ポートフォワーディング方式はブラウザ以外のアプリケーションで実現したい場合に利用されます。
アプリケーションはローカルの専用モジュールに通信を送り、専用モジュールが相手拠点のVPN装置にその通信を送ります。
ではなぜポートフォワーディング方式と言うのかというと、本来、アプリケーションはそれぞれ専用のポートを使用して通信を行いますが、そのポートを相手拠点のFWが通すとは限りません。ですが、通常、SSL-VPNではTCP/443（httpsと同じ）を使うので、どのようなアプリケーションが使われてもそのポートだけ許可しておけばよくなります。このポートが変換されて転送される様子からポートフォワーディングという名前が付いたそうです。
SSL-VPNを使って、異なる拠点間でありながら同一ネットワークを実現する技術です。
イメージとしては、SSL-VPNで繋がれたマシン全てが一つのL2スイッチで繋がれている感じです。
ですので、例えばarpを飛ばすと、ブロードキャストで送信されるので、拠点をまたいで全てのPCにarpリクエストが転送されます。
これが一番難しい方式ですが、仕組みとしてはポートフォワーディング方式とあまり変わりません。専用モジュールを使って、通信を相手拠点のVPN装置に送信するだけです。
ポートフォワーディングと違うのは、①で解説しているカプセル化の範囲です。
あまり深く触れませんでしたが、他の方式ではカプセル化の対象にしていないパケットのヘッダ部に付いているIPアドレスやポート番号なども全てカプセル化した上でVPN装置に送る事でL2フォワーディングを実現しています。
ここまで来ると、もうネスペの領域なので、私の説明もちょっと怪しい感じになってきてますが、結論としては、SSL-VPN=https通信で元の通信データをそのまま別拠点に転送する技術、と私は理解しています。
SFTPのwikiにはこうあります。
「SFTPは、SSH上で実行されるFTPではなく、IETF SECSHワーキンググループによってゼロから設計された新しいプロトコルである。」
ここに書かれている通り、プロトコル上では、SFTPはSSHの上で動くものではありません。SSHの暗号化技術をFTPの仕様内に組み込んだFTPの進化系です。
ただ、現実的にはSFTPはOpenSSHのような有名なSSHアプリケーション内に組み込まれているせいかSSH上で動くものと認識されているケースが多いです。（アプリケーション上という意味では間違っていませんが、プロトコル上という意味では間違いです）
これはおおむねその通りかと思います。
つまり、この三者（telnet,ssh,SFTP）はTCP上に直に実装された全く別のアプリケーションプロトコルと言えます。
平成29年度春 午後2問2 [0540]
勉強中さん(No.1)
設問1（1）の回答はSMTP over SSLとなっています。
伺いたいのは、over SSLの仕組み等 についてです。
SSL（TLS）と聞くと、ブラウザとサーバ証明書導入済のWebサーバとの間での利用（HTTPS）をイメージしてしまいます。
そのためSMTP（その他、over SSLがあり得るようなプロトコル）において、 SSL通信が実現される仕組みが理解できていません。
ネット上等でもこれという情報にたどり着けておらず、申し訳ありませんが質問させて頂きます。
伺いたいのは、over SSLの仕組み等 についてです。
SSL（TLS）と聞くと、ブラウザとサーバ証明書導入済のWebサーバとの間での利用（HTTPS）をイメージしてしまいます。
そのためSMTP（その他、over SSLがあり得るようなプロトコル）において、 SSL通信が実現される仕組みが理解できていません。
ネット上等でもこれという情報にたどり着けておらず、申し訳ありませんが質問させて頂きます。
2020.09.29 08:53
グルタミンさん(No.2)
SSL/TLSプロトコルはOSI参照モデルで言うところのトランスポート層より上からセッション層あたりのプロトコルと言われています。ただしこれはイメージの話で厳密にそう定義されているわけではありません
下記では、ひとまずその辺りの層のプロトコルという前提で解説します。
SMTPはHTTPと同様で、アプリケーション層のプロトコルです。
そしてこの二つは、ご存じかと思いますが、両方ともTCPを使っています。
TCP通信のデータ部を使ってHTTPやSMTP通信を実現しています。
これと同様にSSL/TLS通信も専用のヘッダとデータ部（正確にはTLSレコードプロトコル）を持ち、そのデータ部を使って上位のプロトコルの通信を行います。
この時、データ部はSSL/TLS層の機能で自動で暗号化されるので、上位のプロトコルは平文をそのまま通信に渡してしまって問題ありません。
イメージ的には、以下のような階層で成り立ちます。
アプリケーションプロトコル（HTTP,SMTP等）
SSL/TLS
TCP（UDP）
IP
このようにSSL/TLSはTCPと同じように、上位のプロトコルがなんであっても同じようにその下に敷いて使う事ができます。逆に下の層がTCPである必要もありません（QUIC等ではUDPの上にSSL/TLSが乗っかっています）
また、SSL/TLSはTCPの３ハンドシェイク同様に、TLSハンドシェイクと呼ばれる本通信の前のやりとり（暗号スイートや証明書の交換）を行う事で通信を確立します。この流れも押さえておくといいかもしれません。
下記では、ひとまずその辺りの層のプロトコルという前提で解説します。
SMTPはHTTPと同様で、アプリケーション層のプロトコルです。
そしてこの二つは、ご存じかと思いますが、両方ともTCPを使っています。
TCP通信のデータ部を使ってHTTPやSMTP通信を実現しています。
これと同様にSSL/TLS通信も専用のヘッダとデータ部（正確にはTLSレコードプロトコル）を持ち、そのデータ部を使って上位のプロトコルの通信を行います。
この時、データ部はSSL/TLS層の機能で自動で暗号化されるので、上位のプロトコルは平文をそのまま通信に渡してしまって問題ありません。
イメージ的には、以下のような階層で成り立ちます。
アプリケーションプロトコル（HTTP,SMTP等）
SSL/TLS
TCP（UDP）
IP
このようにSSL/TLSはTCPと同じように、上位のプロトコルがなんであっても同じようにその下に敷いて使う事ができます。逆に下の層がTCPである必要もありません（QUIC等ではUDPの上にSSL/TLSが乗っかっています）
また、SSL/TLSはTCPの３ハンドシェイク同様に、TLSハンドシェイクと呼ばれる本通信の前のやりとり（暗号スイートや証明書の交換）を行う事で通信を確立します。この流れも押さえておくといいかもしれません。
2020.09.29 13:08
グルタミンさん(No.3)
補足
通常、証明書はアプリケーションに対してではなく、そのPC（OS）に対してインストールされます。
そのファイルをWebサーバアプリケーションやブラウザが参照して使っているだけです。
同様に他のアプリケーション（メールサーバやメールクライアント）も、PC内の証明書を参照して使う事ができます。
例えば、windowsであれば、コマンドラインで「certlm.msc」と叩くと、証明書の管理アプリが起動します。
この中には、リモートデスクトップ（のアクセス先）等もあり、HTTPS通信だけで証明書が使われているわけではないことが確認できると思います。
通常、証明書はアプリケーションに対してではなく、そのPC（OS）に対してインストールされます。
そのファイルをWebサーバアプリケーションやブラウザが参照して使っているだけです。
同様に他のアプリケーション（メールサーバやメールクライアント）も、PC内の証明書を参照して使う事ができます。
例えば、windowsであれば、コマンドラインで「certlm.msc」と叩くと、証明書の管理アプリが起動します。
この中には、リモートデスクトップ（のアクセス先）等もあり、HTTPS通信だけで証明書が使われているわけではないことが確認できると思います。
2020.09.29 13:53
勉強中さん(No.4)
この投稿は投稿者により削除されました。(2020.09.29 23:08)
2020.09.29 23:08
勉強中さん(No.5)
グルタミンさん
ありがとうございます。
補足のところでわからなくなってしまったのですが、over SSLはサーバ側のサーバ証明書をもとに実現するものと理解しています。
そのため、以下の通り理解しているのですが、違いますでしょうか？
・サーバ証明書はサーバOSにインストール
※アプリケーション単位ではなく、OS単位にインストール。どのアプリケーションのover SSLにも共通して使える。
・PCのOS（やブラウザ）には、必要な場合に限り、信頼するサーバ証明書として登録
※サーバ証明書が信頼済み認証局の発行しているものなら、個別にPCへの登録は不要。
理解が異なっている場合、指摘頂けますと幸いです。
ありがとうございます。
補足のところでわからなくなってしまったのですが、over SSLはサーバ側のサーバ証明書をもとに実現するものと理解しています。
そのため、以下の通り理解しているのですが、違いますでしょうか？
・サーバ証明書はサーバOSにインストール
※アプリケーション単位ではなく、OS単位にインストール。どのアプリケーションのover SSLにも共通して使える。
・PCのOS（やブラウザ）には、必要な場合に限り、信頼するサーバ証明書として登録
※サーバ証明書が信頼済み認証局の発行しているものなら、個別にPCへの登録は不要。
理解が異なっている場合、指摘頂けますと幸いです。
2020.09.29 23:09
グルタミンさん(No.6)
この投稿は投稿者により削除されました。(2020.09.30 02:00)
2020.09.30 02:00
グルタミンさん(No.7)
申し訳ありません。補足についてですが、これは私が間違っていました。
証明書はただのテキストデータ（ファイル）ですので、OS上で管理しなきゃいけない決まりがあるわけではなく。特にlinuxの場合ですと、普通にサーバ等のアプリケーション毎に決まったディレクトリ内に証明書ファイルを置いておく形が一般的のようです。
その認識でだいたい合っていると思います。
ただ、サーバ証明書を信頼して登録するというケースは多分無いんじゃないでしょうか？
サーバ証明書は通信してきた相手の認証時に使うだけですし、通信の度に本人か確認しないとなりすましを防げないので、サーバ証明書（あるいはクライアント証明書）は通信の度に使い捨てるものという認識です。
少し例を挙げてみます
・クライアント A
・Webサーバ B
・Bのサーバ証明書にデジタル署名をした中間認証局 C
前提知識として、SSL/TLS通信の場合、通信の度に毎回、TLSハンドシェイク時に互いの持つ証明書を交換します。交換は任意なので、認証をしてもらう必要がない側は証明書を送りません。
Aにインストールされているのは通常、「Cのルート認証局のルート証明書」だけです。「Cの中間証明書」はインストールできますが、していなくても問題ありません。
「Bのサーバ証明書」はBとのSSL/TLS通信の時にTLSハンドシェイクで送られてくるので、アプリケーション（ブラウザ）上で確認できますが、AのPCにインストールされるわけでありません。基本的に通信の度にその通信が本人のものか確認しないとなりすましの対策にならないので、サーバ証明書の情報が必要なのは、基本的にその通信の間だけです。
Bには通常、「Bのサーバ証明書」と「Cの中間証明書」と「Cのルート認証局のルート証明書」がインストールされています。「Bのサーバ証明書」以外も必要な理由についてですが、SSL通信では、証明書を送る場合、自分の証明書を認証する上位の証明書を含めた全て(証明書チェーン)を送る必要があるからです。
少し古いですが、TLSハンドシェイクの解説はIPAのサイトにもあるので、URLを置いておきます
https://www.ipa.go.jp/security/pki/071.html
※ TLS1.3では少し流れが変わるので、あくまで参考程度で。
証明書はただのテキストデータ（ファイル）ですので、OS上で管理しなきゃいけない決まりがあるわけではなく。特にlinuxの場合ですと、普通にサーバ等のアプリケーション毎に決まったディレクトリ内に証明書ファイルを置いておく形が一般的のようです。
> PCのOS（やブラウザ）には、必要な場合に限り、信頼するサーバ証明書として登録
> ※サーバ証明書が信頼済み認証局の発行しているものなら、個別にPCへの登録は不要。
その認識でだいたい合っていると思います。
ただ、サーバ証明書を信頼して登録するというケースは多分無いんじゃないでしょうか？
サーバ証明書は通信してきた相手の認証時に使うだけですし、通信の度に本人か確認しないとなりすましを防げないので、サーバ証明書（あるいはクライアント証明書）は通信の度に使い捨てるものという認識です。
少し例を挙げてみます
・クライアント A
・Webサーバ B
・Bのサーバ証明書にデジタル署名をした中間認証局 C
前提知識として、SSL/TLS通信の場合、通信の度に毎回、TLSハンドシェイク時に互いの持つ証明書を交換します。交換は任意なので、認証をしてもらう必要がない側は証明書を送りません。
Aにインストールされているのは通常、「Cのルート認証局のルート証明書」だけです。「Cの中間証明書」はインストールできますが、していなくても問題ありません。
「Bのサーバ証明書」はBとのSSL/TLS通信の時にTLSハンドシェイクで送られてくるので、アプリケーション（ブラウザ）上で確認できますが、AのPCにインストールされるわけでありません。基本的に通信の度にその通信が本人のものか確認しないとなりすましの対策にならないので、サーバ証明書の情報が必要なのは、基本的にその通信の間だけです。
Bには通常、「Bのサーバ証明書」と「Cの中間証明書」と「Cのルート認証局のルート証明書」がインストールされています。「Bのサーバ証明書」以外も必要な理由についてですが、SSL通信では、証明書を送る場合、自分の証明書を認証する上位の証明書を含めた全て(証明書チェーン)を送る必要があるからです。
少し古いですが、TLSハンドシェイクの解説はIPAのサイトにもあるので、URLを置いておきます
https://www.ipa.go.jp/security/pki/071.html
※ TLS1.3では少し流れが変わるので、あくまで参考程度で。
2020.09.30 02:58
勉強中さん(No.8)
グルタミンさん
ありがとうございます。（頂いた内容で理解を深めるようにします。）
関連する（？）別の疑問について質問させて頂けませんか？
VPNの実現方式1つにSSL－VPNがあると思います。
このSSLはNo.2でご回答頂いた仕組みと異なりますか？
SSL－VPNの方式は以下があると思いますが、No.2で教えて頂いたSSLと仕組みが異なっているのでしょうか。
・リバプロ方式（Webブラウザのみ）
・ポートフォワーディング方式（Webブラウザ＋Javaアプレット等）
・L2フォワーディング方（Webブラウザ＋Javaアプレット等）
わかりにくい質問で申し訳ないです。
ありがとうございます。（頂いた内容で理解を深めるようにします。）
関連する（？）別の疑問について質問させて頂けませんか？
VPNの実現方式1つにSSL－VPNがあると思います。
このSSLはNo.2でご回答頂いた仕組みと異なりますか？
SSL－VPNの方式は以下があると思いますが、No.2で教えて頂いたSSLと仕組みが異なっているのでしょうか。
・リバプロ方式（Webブラウザのみ）
・ポートフォワーディング方式（Webブラウザ＋Javaアプレット等）
・L2フォワーディング方（Webブラウザ＋Javaアプレット等）
わかりにくい質問で申し訳ないです。
2020.09.30 20:35
グルタミンさん(No.9)
> このSSLはNo.2でご回答頂いた仕組みと異なりますか？
特にそんなことはないと思いますが、VPNの技術は複雑なのでややこしい話になりがちですね。
私もVPN技術の理解度は、あまり自信がありません。
基本的にどの方式でも共通している事は以下の通りです
① 元の通信内容をカプセル化してSSL通信のデータ部にそのまま乗っけます（トンネリング）。この通信はSSLの機能によって暗号化されます。
② 通常のインターネット回線を使って、①を相手の拠点のVPN装置に送信します。
③ VPN装置はその通信内容を復号して中身を取り出し、その中身から宛先を調べて本来の相手にその中身を送信（中継）します
なお、インターネット上では通信もアプリケーションもhttpsを使う事が多いからなのか（FWなんかでも追加の設定が要らなくて済む）、多くの製品ではSSL-VPNの方式に関わらず、実際にはhttps通信を用いてSSL-VPNを実現しています（httpのボディ部に元の通信内容を格納してSSL通信で暗号化、つまりhttps通信を行う）
> リバプロ方式（Webブラウザのみ）
これはブラウザ上で動くWebアプリケーションに使う方式です。イメージ的には社内PCのブラウザから別拠点の社内のサーバにアクセスしている感じでしょうか。通常、PC側は特に問題無くインターネット上のサーバにhttps通信できますが、外部のLANの中でしか公開されていないサーバにはアクセスできません。これを外部LAN側に置かれているVPN装置をリバースプロキシとして動作させる事で、予め決められたユーザのみ、VPN装置を中継する事で外部LAN側の中にあるサーバと通信する事ができます。
> ポートフォワーディング方式
ポートフォワーディング方式はブラウザ以外のアプリケーションで実現したい場合に利用されます。
アプリケーションはローカルの専用モジュールに通信を送り、専用モジュールが相手拠点のVPN装置にその通信を送ります。
ではなぜポートフォワーディング方式と言うのかというと、本来、アプリケーションはそれぞれ専用のポートを使用して通信を行いますが、そのポートを相手拠点のFWが通すとは限りません。ですが、通常、SSL-VPNではTCP/443（httpsと同じ）を使うので、どのようなアプリケーションが使われてもそのポートだけ許可しておけばよくなります。このポートが変換されて転送される様子からポートフォワーディングという名前が付いたそうです。
> L2フォワーディング
SSL-VPNを使って、異なる拠点間でありながら同一ネットワークを実現する技術です。
イメージとしては、SSL-VPNで繋がれたマシン全てが一つのL2スイッチで繋がれている感じです。
ですので、例えばarpを飛ばすと、ブロードキャストで送信されるので、拠点をまたいで全てのPCにarpリクエストが転送されます。
これが一番難しい方式ですが、仕組みとしてはポートフォワーディング方式とあまり変わりません。専用モジュールを使って、通信を相手拠点のVPN装置に送信するだけです。
ポートフォワーディングと違うのは、①で解説しているカプセル化の範囲です。
あまり深く触れませんでしたが、他の方式ではカプセル化の対象にしていないパケットのヘッダ部に付いているIPアドレスやポート番号なども全てカプセル化した上でVPN装置に送る事でL2フォワーディングを実現しています。
ここまで来ると、もうネスペの領域なので、私の説明もちょっと怪しい感じになってきてますが、結論としては、SSL-VPN=https通信で元の通信データをそのまま別拠点に転送する技術、と私は理解しています。
2020.10.01 00:44
勉強中さん(No.10)
グルタミンさん
ありがとうございます。こんがらがってたことが解決に至る目処が立ってきました。
更に追加質問となりますが...
SSHについても伺えませんでしょうか。
疑問は、telnetに大体する方式としてのSSHと、FTPに対するSFTPを実現する位置付けとしてのSSHです。
telnetについては大体プロトコル。
FTPについてはSFTPを実現する黒子的な位置付けになっていると思います。
この関係性が分からずにおります。
教えて頂けますとありがたいです。
ありがとうございます。こんがらがってたことが解決に至る目処が立ってきました。
更に追加質問となりますが...
SSHについても伺えませんでしょうか。
疑問は、telnetに大体する方式としてのSSHと、FTPに対するSFTPを実現する位置付けとしてのSSHです。
telnetについては大体プロトコル。
FTPについてはSFTPを実現する黒子的な位置付けになっていると思います。
この関係性が分からずにおります。
教えて頂けますとありがたいです。
2020.10.01 09:44
グルタミンさん(No.11)
> FTPについてはSFTPを実現する黒子的な位置付けになっていると思います。
SFTPのwikiにはこうあります。
「SFTPは、SSH上で実行されるFTPではなく、IETF SECSHワーキンググループによってゼロから設計された新しいプロトコルである。」
ここに書かれている通り、プロトコル上では、SFTPはSSHの上で動くものではありません。SSHの暗号化技術をFTPの仕様内に組み込んだFTPの進化系です。
ただ、現実的にはSFTPはOpenSSHのような有名なSSHアプリケーション内に組み込まれているせいかSSH上で動くものと認識されているケースが多いです。（アプリケーション上という意味では間違っていませんが、プロトコル上という意味では間違いです）
> telnetについては大体プロトコル
これはおおむねその通りかと思います。
つまり、この三者（telnet,ssh,SFTP）はTCP上に直に実装された全く別のアプリケーションプロトコルと言えます。
2020.10.01 13:28