※TCP は詳しくないので間違いあるかも
記事のメモ。
Windows の HTTP スタックには他にも HTTP.sys があるが、基本 IIS 向けのカーネルモードドライバとして動作する HTTP リスナーで、クライアントアプリには超使いにくいやつなんで今回は省略。
なお .NET Framework の System.Net.HttpListener の中身は HTTP.sys なので、アレもサーバー以外では超絶使いにくい。
さて巷ではJVNVU#98282440: 「提督業も忙しい！」(KanColleViewer) がオープンプロキシとして動作する問題が話題ですが、FiddlerCore は何も考えないで実装すると恐らくこうしてしまうような仕様です。クソですね。。
とりあえず適当に FiddlerCore を使ったアプリケーションを立ち上げてみましょう。
[csharp]
FiddlerApplication.Startup(55555, FiddlerCoreStartupFlags.Default);
[/csharp]
するとあら不思議、0.0.0.0:55555でListningされてしまいます。
[raw]
C:\Windows\system32>netstat -a -b -n -o -p TCP
アクティブな接続
プロトコル ローカル アドレス 外部アドレス 状態 PID
…(中略)…
TCP 0.0.0.0:55555 0.0.0.0:0 LISTENING 6688
[FiddlerTest.vshost.exe]
[/raw]
これではアプリが立ち上がってる間は外部からHTTPプロキシとして利用できてしまいます。
知らず知らずのうちに他所様への攻撃の踏み台にされて、ある日突然警察がやってくるなんてこともあるかもしれません。怖いですね。
で、どうすればいいかというと、127.0.0.1:55555でLisningするようにできればローカルプロセスしかアクセスできなくなるので、そう変更したいですね？
これはごく簡単で、AllowRemoteClientsをfalseにしてやればOKです。
[csharp]
FiddlerApplication.Startup(55555
, FiddlerCoreStartupFlags.RegisterAsSystemProxy
| FiddlerCoreStartupFlags.ChainToUpstreamGateway
| FiddlerCoreStartupFlags.MonitorAllConnections
| FiddlerCoreStartupFlags.CaptureLocalhostTraffic);
[/csharp]
Flagなので指定しなければOK。
[raw]
C:\Windows\system32>netstat -a -b -n -o -p TCP
アクティブな接続
プロトコル ローカル アドレス 外部アドレス 状態 PID
…(中略)…
TCP 127.0.0.1:55555 0.0.0.0:0 LISTENING 7128
[FiddlerTest.vshost.exe]
[/raw]
つまりFiddlerCoreStartupFlags.Defaultがイカンわけです。
でも FiddlerCore は Fiddler.exe のUI以外の部分を抜き出したものなわけですから、Fiddler.exe 自体がそういうもんだという可能性もあります。
参照: FiddlerCore – Fiddler Proxy Engine for your .NET Applications
ここで Fiddler.exe および FiddlerCore のデフォルト値を見てみましょう。
参考リンク以上のことは特に調べていないけど、覚え書き。
モジュール有効化
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so LoadModule ldap_module modules/mod_ldap.so
認証設定
AuthType Basic
AuthName "auth example"
AuthBasicProvider ldap
AuthLDAPUrl "ldap://domaincontroller.domainname.local:3268/DC=domainname,DC=local?sAMAccountName?sub?(objectClass=*)"
AuthzLDAPAuthoritative Off
AuthLDAPBindDn "domainuser"
AuthLDAPBindPassword "password"
Require valid-user
basedn : 検索の起点となる識別名(DN)を指定します。
attribute : 検索対象の属性です。sAMAccountNameはWindowsのログイン名になります。
scope : 検索する深さを指定します。one(１階層のみ検索)またはsub(下位の階層も検索)です。
filter : 検索のLDAPフィルターです。(objectClass=*)となっているのでツリー上の全てのオブジェクトを検索します。
portをActiveDirectoryのグローバルカタログ(ポート3268)にすれば、basednでOUを指定しなくてもディレクトリ全体が検索範囲になることが分かりました。(グローバルカタログはフォレスト内の全ドメインの全オブジェクトから、ひんぱんに利用する属性のみを抽出したものです。)
Active Directoryでは、標準的な構成の場合認証前に権限のあるユーザで接続をしなければいけません。 そのユーザ名とパスワードをAuthLDAPBindDN、AuthLDAPBindPasswordで指定します。
require valid-user を指定するには、authz_user_moduleのロードとAuthzLDAPAuthoritative Offが必要。
require ldap-userとかならこれらは必要ない。
※あまり詳しい事は調べてない。
内部httpサーバーが302responseを返した際に、Locationヘッダをhttpsに書き換えてくれないため、httpにリダイレクトされてしまう。
回避策は調べてない。
Squid3では’Front- End-Https: On’で対処可能な模様？
※ RFC7230 時点の情報に更新 → HTTP/1.1 のコネクション管理の理解メモ – CAT EARS
HTTPリクエストの処理中(長いAPサーバーの処理等)にタイムアウトなどでTCPコネクションが切断された場合、HTTPクライアントはRFC2616に従い同じリクエストを勝手に再送する事がある。(SHOLDとなっているのでその場合の方が多いかと)
なので、場合によっては二重POSTとなってしまう。。
非冪等メソッドの自動再試行は不可。
これはHTTPベースのプロトコル(SOAPやAMF、WebDAV等のRPC)全てに当てはまるため、RPCを使用する際には注意が必要である。
失敗パターンは リクエスト送信→失敗→再送信→失敗→切断(エラー?) が標準動作。
RFC2616 8.1.4 Practical Considerations より抜粋
A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request
at the same time that the server has decided to close the “idle”
connection. From the server’s point of view, the connection is being
closed while it was idle, but from the client’s point of view, a
request is in progress.This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see section 9.1.2). Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s). Confirmation by
user-agent software with semantic understanding of the application
MAY substitute for user confirmation. The automatic retry SHOULD NOT
be repeated if the second sequence of requests fails.
参考: