帰ったら eBPF プログラムのパケットアクション確定部分をイテレータと PacketAction の定義を交えつつ書く。次にブラウザを用いた評価の準備をやる。最後に rustls の改造部分についても書いて、評価をしてまとめる。https://www.reversinglabs.com/blog/gitgot-cybercriminals-using-github-to-store-stolen-data
yas がたまに突拍子もなさそうなことを語りつつも学生に意見を尋ねているのは、もしかして学生側からすれば主体性を持たないと何かおかしなことが起こりうるのではないかと危機感を抱かせることに繋がり、結果として研究に向かう姿勢が出来上がることを期待しているからなのではないか？遅延解析のところでアプリケーションによる通信を阻害したくないという旨を論文に書いていたら、別にそれはされてもいいのではないかという話が yas からも書かれていた。これは口頭で雑談しているときにも takonomura から指摘された話で、もしかしたら自分はマルウェアが自身の通信を監視されていることを検知されたときに動作を変えてしまうところに不要な不安を抱えてしまっているせいなのかもしれない。wring
次にやること（論文レビュー対応）- ✅ 「通信内容検査処理」の名称を変更し、図中に現れる名前も変更する
- ✅ 「アクセス制御プログラム」の名称をよりよいものに変更する
- アクセス制御プログラム is-a アクセス制御をするプログラムなので不適である
- 庄司さんの論文では OvS を使っていたので仮想スイッチに対するコントローラという名称でうまく命名できていたが、どうするか……
- 役割を列挙してみる
- パケットフィルタで利用するルールを管理する
- 庄司さんの論文でいうところのコントローラの役割に対応していそう
- TUI ダイアログをユーザに表示する
- TLS の共通鍵を取得する
- 遅延解析対象のパケットを解析器に渡す
- パケットフィルタリング制御プログラムでいいんでは
- 通信内容解析器が TLS の鍵を受け取る役目を果たすような図になっているので
- ✅ 「軽量なルール表」も変更する
- 「パケット用ルール表」を考えたが、一般ルールもまたパケットを処理するために利用されることから適切な差別化がなされない
- このような組み合せはどうか？
- 設計：実装
- 「アクセス制御用ルール」：「一般ルール」
- 「パケットフィルタ向けルール」：「5tuple ルール」
- ✅「遅延解析」の遅延の必要性を説明する
- 本来は遅延せずに解析したいが、問題があってできていないことを書く
- 実装に踏み込むことになりそう。
- eBPF プログラムでは sleep できないためパケットを通過させる必要がある
- TLS 実装を提供するライブラリであって TCP セグメント単位でメッセージの復号ができるものを見つけられていないこと
- TLS 1.2 でパケットを通過させないと原理的に処理できないような点はないか？
- なさそうだけど、SSLKEYLOGFILE から鍵を読み込むのまでにある程度待機しなければ復号できない（eBPF program はスリープできない話）
- ✅ 「遅延解析」でアプリケーションの実行を阻害したくないような雰囲気で書いているところを削除する（プライバシーを重視したいという視点なので、そのトレードオフには同意しているものとみてよいはず・そもそも気にしなくてよい）
- ✅ 「遅延解析」で「タイムラグ」と「可能性」と書いているところは不明瞭・ふさわしくなさそうなので書き換える
- ✅ 4.4 節（\section{パケットフィルタとアクセス制御プログラムの動作}）の箇所で暗号通信の話を書く
- （「アプリケーションレベル・ファイアウォール」を「アプリケーション・ファイアウォール」に置換する？）
- しなくてよさそうな気がする。タイトルだけアプリケーション・ファイアウォールで、それ以外はアプリケーションレベル・ファイアウォールが他の文章でもうまく通っているように感じる。先行研究である庄司さんの研究がこの呼称を使っていた
- ✅ （5 章の図中でフローチャートの分岐時の矢印が変になっているのを修正する）