4月 262019
 

自作プロキシ (Nekoxy2) の HTTP/2 (RFC7540) 対応にあたっての私なりの理解をまとめました。
HTTP/2 の解説自体は他サイトのほうがわかりやすかったり正確だったりすると思うので、あくまでも参考程度に。

RFC においては SHOULD とか MUST とかの違いは重要ですが、ここに書くの面倒なので必要に応じて調べましょう。

HPACK(RFC7541) については RFC も別だし長いし記事を分けます。
HPACK 理解メモ – CAT EARS

Continue reading »

4月 192019
 

.NET Core 3.0 Preview 4 で HttpClient の HTTP/2 サポートが追加されたようですね。
Announcing .NET Core 3 Preview 4 | .NET Blog

今までの .NET Standard では SslStream 自体が HTTP/2 の事実上必須な機能(ALPN)に対応しておらず、.NET Standard 2.1 でようやくサポートされる見込みだったため、どうやらちゃんとくるようで一安心というところです。
(HttpClient についてはこれのせいかは不明ですが…… SocketsHttpHandler が HTTP/2 対応していなかったのは確か)

しかしながら .NET Framework 4.8 の方は .NET Standard 2.0 止まりになることになっているので、HTTP/2 サポートは今後あるのかどうかすら怪しいですね……

Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1.
Announcing .NET Standard 2.1 | .NET Blog

とはいえ .NET Standard はあくまでも API 標準を定めただけで実装は各プラットフォーム依存ですから、動くようになる可能性はあるかも?

とりあえず .NET Framework は 4.8 の時点では HttpClient + HttpClientHandler では動作しそうにありません。
BCL 以外でなら WinHttpHandler を使い、HttpRequestMessage のバージョンを明示的に指定することで、利用できます(Win10 1607↑ + .NET FW 4.6↑ に限る)。
参考: How to make the .net HttpClient use http 2.0?

実は Core 2.0 までも Windows 環境に限れば WinHttpHandler に丸投げしていたようで、HttpClient で HTTP/2 が動作します。
Core 2.1 以降 SocketsHttpHandler に移行し、環境依存を減らした為、HTTP/2 に一時的に非対応となっていたようです。

HttpClient の HTTP/2 対応

  • .NET Framework
    • HttpClientHandler では利用不可
    • WinHttpHandler (要NuGet & Win10 1607)を利用すれば利用可
  • .NET Core
    • ~2.0 : Win10 1607~のみ利用可?
      • WinHttpHandler を使ってる模様
    • 2.1~2.2 : 利用不可
      • SocketsHttpHandler に移行したため
      • ただし WinHttpHandler を利用するよう構成すれば Windows では利用可
    • 3.0~ : 利用可
      • SocketsHttpHandler の HTTP/2 対応?

Continue reading »

10月 182017
 

※TCP は詳しくないので間違いあるかも

発生していた問題

  • 2017/10/17のDMMメンテ後、Nekoxy を通した通信で osapi.dmm.com サーバーだけが応答しなくなった
    • 他のサーバーは問題ない
  • Nekoxy が利用している TrotiNet 単体でも発生する
  • 上流に Fiddler 等のプロキシを挟むと発生しない

影響

  • Nekoxy を利用していたアプリケーション全般で DMM のゲーム等ができなくなっていたかと
    • 提督業も忙しい!
    • 七四式電子観測儀
    • 回転母港
      など

何故発生するのか

  • osapi.dmm.com が複数の TCP パケットに分割された HTTP リクエストを正常に受け取ってくれないため
    • 上流に別のプロキシを挟むと、上流プロキシが Nekoxy に代わってサーバーと TCP おしゃべりするため、その実装がこの問題に触れていなければ通信障害は発生しない

Continue reading »

8月 062015
 

記事のメモ。

Windows の HTTP スタックには他にも HTTP.sys があるが、基本 IIS 向けのカーネルモードドライバとして動作する HTTP リスナーで、クライアントアプリには超使いにくいやつなんで今回は省略。
なお .NET Framework の System.Net.HttpListener の中身は HTTP.sys なので、アレもサーバー以外では超絶使いにくい。

5月 272015
 

さて巷では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するようにできればローカルプロセスしかアクセスできなくなるので、そう変更したいですね?
これはごく簡単で、AllowRemoteClientsfalseにしてやれば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 のデフォルト値を見てみましょう。

Continue reading »

2月 192013
 

参考リンク以上のことは特に調べていないけど、覚え書き。

モジュール有効化

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(1階層のみ検索)またはsub(下位の階層も検索)です。
filter : 検索のLDAPフィルターです。(objectClass=*)となっているのでツリー上の全てのオブジェクトを検索します。

portをActiveDirectoryのグローバルカタログ(ポート3268)にすれば、basednでOUを指定しなくてもディレクトリ全体が検索範囲になることが分かりました。(グローバルカタログはフォレスト内の全ドメインの全オブジェクトから、ひんぱんに利用する属性のみを抽出したものです。)

Active Directoryでは、標準的な構成の場合認証前に権限のあるユーザで接続をしなければいけません。 そのユーザ名とパスワードをAuthLDAPBindDN、AuthLDAPBindPasswordで指定します。

require valid-user を指定するには、authz_user_moduleのロードとAuthzLDAPAuthoritative Offが必要。
require ldap-userとかならこれらは必要ない。

1月 312013
 

こんな感じで実行できる。

[raw title=”bat”]
“C:\Program Files (x86)\WinSCP\winscp.com” /script=example.script /log=example.log
[/raw]

[raw title=”example.script”]
option batch abort
option confirm off
open ftp://username:password@hostname -explicittls -certificate=”…”
get /example/* c:\example\
exit
[/raw]

7月 302012
 
  1. Wiresharkを起動
  2. net 192.168.0.0/24などのキャプチャフィルタでキャプチャ開始
  3. bootpでフィルタ
  4. ipconfig /release -> ipconfig /renewなどでDHCP discoverを飛ばした時に、DHCP offerを返してきた奴がDHCPサーバー
7月 302012
 
参考
メモ
  • LDAPはport389、LDAPSはport636
  • AD DSには特に何もしないでも普通にLDAPアクセスできる
  • LDAPSアクセスするには証明書の用意が必要
  • DC上にAD CSをインストールすれば自動的に利用できるようになる
    • ただし、障害耐性やメンテを考慮すると、DCをCAとするのは推奨されない
  • 独自の証明書をインストールする場合は、DC上のローカルコンピュータの個人ストアにインストールすればよい
    • 2008以降はNTDSサービスアカウントの個人ストアもサポートされ、そちらが優先される
    • 該当する証明書が複数ある場合、期限が長い証明書が自動的に選択される
      • しかしながら、ややこしいので1つのみにすることが推奨されている
  • 2008以降は証明書の切り替えに再起動は不要となった
  • CA証明書は、Windowsストアへの配布はAD DSを利用して配布することが可能だが、Javaのような独自の証明書ストアを持つアプリケーションは参照してくれないという問題がある