閲覧
ヘルプ
サインイン
この投稿は5年以上前のものです
Solved!
Uehara Y.
Community Manager
•
4.9K メッセージ
0
3327
2017年10月13日 01:00
社内フォーラムにあった有益情報をフォーラムに横流しします（投稿者からの許可はちゃんと取ってます）。
レスポンス(1)
Proxy環境において、CECTやNetworkCheckをしたときに、
GET https://:443/
GET https://:8443/
のテストが下図のようにHTTP Continuationとなって失敗する場合があります。
ここでいうContinuationとはHTTPヘッダを含まないHTTPデータのことです。
本来であればHTTPのStatusコード200が想定される状況ですが、
いくつかのProxyサーバの挙動によってこのような出力になることがあります。
--------------------- 2017/03/30 追記 ---------------------------------
パケットアナライザの種類やWiresharkのVersionによってはHTTP Continuationではなく、
TCP [PSH, ACK]と表示されることもあるようです。
データ部を見ると１６進数で 15 03 01 00 02 02 0a となっています。
HTTPの仕様にない動作であり、不明なバイナリであるためESRSサーバ側かProxyの不具合が疑われるところですが、
実は正常な動作です。
このデータの正体は、このパケットだけを抽出してWiresharkに読ませるとわかります。
実はこのデータはSSL/TLSのAlert Protocolであることが分かります。
15 Alert（TLSPlainTextタイプ）
03 01 Version
00 02 Length
02 Fatal（Alert Level）
0a unexpected message（Alert Description）
このデータ自体は異常ではありません。
Proxy経由で上記のGETメソッドを実施すると、たしかにESRSのサーバからこのメッセージが返ってきます。
これはHTTPSで待ち受けているポートにHTTPでアクセスしていることが原因と思われます。
本来正常であるはずのESRSサーバからのレスポンスがCECTやネットワークチェックでFailedとなるのはProxyの挙動に起因します。
CECTやネットワークチェックが想定しているProxyの動作は、ProxyがESRSサーバと接続を確立し、レスポンスを受けとった段階で
CECTやネットワークチェックスクリプトに対してHTTPのステータスコード２００を返すことです。
一方である種の実装（設定）のProxyサーバは、ESRSサーバから受け取ったデータを加工せずそのままCECTに転送するものがあります。
この場合、HTTPのステータスコード２００を確認できないため、CECTやネットワークチェックは失敗します。
CONNECTメソッドは問題なく接続できるので、実際のESRSの挙動には問題がないと思いますが、
ネットワークチェックが失敗するためProvisioningできません。
Proxy側で挙動を変えてもらうか、ネットワークチェックをバイパスする必要があります。
私が経験する限り、上記の動作をするProxyとしてBlueCoat社製のものがありました。
設定で変更可能なのか、ハードコーディングされているのかは不明ですが、
BlueCoat社のProxyの場合は、特にご注意ください。
BlueCoat社製のProxyだけでなく、トレンドマイクロのInterScan Webmanagerも事例として経験しました。
--------------------- 2017/04/20 追記 ---------------------------------
海外オフィスの社員から共有が情報共有がありました。
彼はCiscoとForefront TMGのProxyでもこの事象に遭遇したそうです。
--------------------- 2017/07/13 追記 ---------------------------------
以下のProxyでも報告がありました。
Vender名：Trend Micro
モデル名：InterScan Web Security Suite
バージョン：5.6 SP1
デル サポート リソース
もっと見る
すべて表示
Top
（投稿者からの許可はちゃんと取ってます）。
Uehara Y.
Community Manager
Community Manager
•
4.9K メッセージ
0
2017年10月13日 01:00
Proxy環境において、CECTやNetworkCheckをしたときに、
GET https://:443/
GET https://:8443/
のテストが下図のようにHTTP Continuationとなって失敗する場合があります。
ここでいうContinuationとはHTTPヘッダを含まないHTTPデータのことです。
本来であればHTTPのStatusコード200が想定される状況ですが、
いくつかのProxyサーバの挙動によってこのような出力になることがあります。
--------------------- 2017/03/30 追記 ---------------------------------
パケットアナライザの種類やWiresharkのVersionによってはHTTP Continuationではなく、
TCP [PSH, ACK]と表示されることもあるようです。
データ部を見ると１６進数で 15 03 01 00 02 02 0a となっています。
HTTPの仕様にない動作であり、不明なバイナリであるためESRSサーバ側かProxyの不具合が疑われるところですが、
実は正常な動作です。
このデータの正体は、このパケットだけを抽出してWiresharkに読ませるとわかります。
実はこのデータはSSL/TLSのAlert Protocolであることが分かります。
15 Alert（TLSPlainTextタイプ）
03 01 Version
00 02 Length
02 Fatal（Alert Level）
0a unexpected message（Alert Description）
このデータ自体は異常ではありません。
Proxy経由で上記のGETメソッドを実施すると、たしかにESRSのサーバからこのメッセージが返ってきます。
これはHTTPSで待ち受けているポートにHTTPでアクセスしていることが原因と思われます。
本来正常であるはずのESRSサーバからのレスポンスがCECTやネットワークチェックでFailedとなるのはProxyの挙動に起因します。
CECTやネットワークチェックが想定しているProxyの動作は、ProxyがESRSサーバと接続を確立し、レスポンスを受けとった段階で
CECTやネットワークチェックスクリプトに対してHTTPのステータスコード２００を返すことです。
一方である種の実装（設定）のProxyサーバは、ESRSサーバから受け取ったデータを加工せずそのままCECTに転送するものがあります。
この場合、HTTPのステータスコード２００を確認できないため、CECTやネットワークチェックは失敗します。
CONNECTメソッドは問題なく接続できるので、実際のESRSの挙動には問題がないと思いますが、
ネットワークチェックが失敗するためProvisioningできません。
Proxy側で挙動を変えてもらうか、ネットワークチェックをバイパスする必要があります。
私が経験する限り、上記の動作をするProxyとしてBlueCoat社製のものがありました。
設定で変更可能なのか、ハードコーディングされているのかは不明ですが、
BlueCoat社のProxyの場合は、特にご注意ください。
--------------------- 2017/03/30 追記 ---------------------------------
BlueCoat社製のProxyだけでなく、トレンドマイクロのInterScan Webmanagerも事例として経験しました。
--------------------- 2017/04/20 追記 ---------------------------------
海外オフィスの社員から共有が情報共有がありました。
彼はCiscoとForefront TMGのProxyでもこの事象に遭遇したそうです。
--------------------- 2017/07/13 追記 ---------------------------------
以下のProxyでも報告がありました。
Vender名：Trend Micro
モデル名：InterScan Web Security Suite
バージョン：5.6 SP1