2026-05-05

コーディングエージェントでGB Studio用のBGM制作をSkill化

お疲れ様です。

世間では相変わらず猫も杓子もAIですが、情報のキャッチアップが大変ですよね。分かります。

いろんな技術も少し枯れてきたぐらいで手を付け始める私ですが、今日はちょっとSkillに挑戦してみた話です。

そろそろAIの記事を一つぐらい書いとこうかなという。

正直ピンときてなかった

MCPやSkill、プラグインなど、さまざまな概念が出てきており、NSやテックブログを見れば「何ができるのか」は理解できるのですが、実際に「自分で何か作りたいものがあるか」というと、正直まだピンと来ていない状況でした。

MCPもわざわざインストールせずにコマンド実行してもらえばよくない？とか、Skillも都度スクリプト生成してお願いすれば良くない？とか。
トークン消費が増えてしまい非効率だけど、まぁいっかと思ってた時期がありました。

もともとデフォ厨（※1）なので、余計な設定入れたくないタイプの人間ってのもあります。

さて、今日はそんなデフォ厨な私が、Skillを作ってみたというお話です。

きっかけ：GB Studioの音源作成

作ってみたと言うより、「こういうのSkill化したほうがいいんじゃね？」と自然になった感じです。

今、GB Studioというゲームボーイのゲーム作成用フレームワークでゲームを開発しており、これはGUIでステージやキャラクター、ギミックなどを開発できるとっても便利なツールです。

このツールの中に音源（BGM・効果音）を作成できる機能があるのですが、フォーマットの知見と音楽の知識がないとちゃんとしたBGMを作成するのが難しい。
ゲームステージやシーンに合わせた作曲スキルはなんて皆無です。

最初はCoworkで都度お願いしていた

というわけで、最初はCoworkを使ってBGMの作成をAIにお願いしていました。
フォーマットに関するドキュメントを読んでもらったり、実際のツールの画面を見てもらったり、いろいろ試行錯誤して、なんとか作成してもらうことができました。

プログラムで音源を生成するぐらいならAIがなくてもできたかもしれないですが、作曲の部分はさすがに難しいので、ここはAIに任せることができてよかったです。

「毎回お願いするの面倒だな」からのSkill化

そして、毎回Coworkにお願いして作成してもらうのが手間になってきた。

1、2個作成したらもう使わないだろうと思ってたが、意外と使う。
効果音とかも増えてきて、ちょっとこだわりたくなってきて使う頻度が上がってきた。作成して音源確認して、やり直して……だんだん面倒くさくなってきた。

こういうのテンプレート化してClaude Code CLIとかでも使えればなー。……こういう時にSkillなんじゃね！？ってなりました。

Skill化作業

早速、音源作成をしていたセッションで以下ポイントに気をつけて、skill化を頼んだら速攻作ってくれました。仕事がはえー！

1. scriptsに共通スクリプトを入れる

Skill化する前は、毎回ゼロからPythonスクリプトを生成してもらっていた。UGEのバイナリ構造を組み立てるコードだけで100行以上あるので、毎回それを書かせるのは時間の無駄だった。
scripts/uge_template.py にテンプレートを入れておくと、Claudeはそれをベースに曲の中身だけ変えて生成してくれる。効果音も同様で sav_template.py に共通パターン（ジャンプ、コイン、爆発等）を定義しておけば、「ピンポーン追加して」だけで済む。
要するに「毎回同じコードを書かせない」ためのスクリプト置き場。ここが一番効いたポイントかも。

2. referencesにフォーマット仕様を入れる

Skill化する前は仕様を確認するのに毎回GitHubのソースコードを読みに行ってもらっていた。時間もかかるし、たまに読み間違えてバグるファイルができたりもした。
仕様を一度 references/uge_format.md と references/sav_format.md にまとめておけば、以降は外部を参照せずにサクッと正しいファイルを作ってくれる。「Claudeが毎回調べ直す必要がある情報」はreferencesに入れておくと良い。

出来上がったもの

gb-music/
├── SKILL.md              (メインの手順書)
├── scripts/
│   ├── uge_template.py   (UGE生成テンプレート)
│   ├── sav_template.py   (SAV生成テンプレート + 汎用SFXパターン)
│   └── audio_to_uge.py   (MP3/M4A→UGE変換ツール)
└── references/
    ├── uge_format.md     (UGE v6バイナリ仕様)
    └── sav_format.md     (FX Hammer SAV仕様)

あとは、これをプロジェクトの .claude/skills/ 以下に放り込めば、あら不思議、引き続き音源を作成してくれるじゃありませんか。

ただ、この状態だとSkillを認識してくれるケースとくれないケースがあるので、CLAUDE.mdとかAGENTS.mdに「BGM/効果音の作成はgb-musicスキルを使って」という一文だけ足してあります。

まとめ

というわけで、Skill便利でした。

Skillは「何度も同じことをAIにお願いしている」と気づいたときが作りどきだと思う。最初から設計するものじゃなくて、使ってるうちに自然と「これまとめたいな」ってなる。そのタイミングで作れば、ちゃんとプロジェクトやチームにフィットしたものになる。

Skill以外にも、コーディングエージェントをとりまく概念はいろいろあります。使いこなせなくても、単語だけでも知っておくとこういった発想につながるので、損はないと思います。

リポジトリはこちら：
https://github.com/kurum-inc/gb-music

作成中のゲームはこちら！BGMの出来栄えをご確認ください！

では👋

※1 デフォ厨：デフォルト設定のまま使いたがる人のこと

2026-01-01

L4 Echo Server作りながらRustを嗜む

はじめに

本年もよろしくお願いいたします🎍

毎年、年末には何かしら新しい学びをインプットする時間を作っているのだが、
今年は諸々の事情で年内に間に合わず、年始から勉強を始めることに！

仕事上Rustに触る機会がなく、明確に「これを作りたい」というテーマもなかったのだが、
せっかくなので「低レイヤーで何か作りたい」という気持ちを優先することにしました。

そこで以前から一度やってみたかった、TCPの3ウェイハンドシェイクをRaw Socketで実装することに挑戦してみた。

HTTPなどのアプリケーション層のプロトコルは一切使わず、
トランスポート層（L4）で直接通信し、文字列を返すだけのシンプルなサーバーを作る。
いわゆる「エコーサーバー」をL4だけで完結させるというのが今回のテーマです。

完成形はこれ：

1 2	$ echo "toppage" \| nc 172.17.0.2 8888 hello world

シンプルだけど、これを実現するまでにTCPの仕組みを体系的に理解できた。
一点注意としては、本件は実用性は全く意識しておらず、ハードコーディングのオンパレードです。

何を作ったか

L4 String Server - トランスポート層で文字列を返すだけのサーバー

Raw Socketで実装
TCP 3ウェイハンドシェイク（SYN, SYN-ACK, ACK）
データパケットの送受信

使用技術：

Rust (初めて)
Raw Socket (libcでシステムコール呼び出し)
Docker (macOSのloopback制限回避)
Claude Code（Agentic codingで学びを加速🙇）

作った経緯

OSI参照モデル見るたびに「アプリケーション層を通さずに3ウェイハンドシェイクの検証ってできないんだっけ？」とずっと思った時期があったので、実験的な意味も含めてやってみたかった。

よく見るこの図の赤枠部分だけでデータやり取りするという試み。
この辺は先人の方々がすでにやられているがあくまでRustの理解を深めるというモチベーションで頑張る。

いざ開発

1. IPヘッダーの解析

IPヘッダーの仕様理解（RFC 791）と受信したパケットからIPヘッダーをパースする。

IPヘッダーの構成

このアスキーアートはAIで出力。
難しい。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         | ← 0-3バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    | ← 4-7バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       | ← 8-11バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          | ← 12-15バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        | ← 16-19バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| バイト位置 | フィールド         | 説明                      |
|------------|--------------------|---------------------------|
| 0          | Version (4bit)     | IPバージョン (4 = IPv4)   |
|            | IHL (4bit)         | ヘッダー長 (5 = 20バイト) |
| 1          | Type of Service    | サービスタイプ            |
| 2-3        | Total Length       | パケット全体の長さ        |
| 4-5        | Identification     | パケット識別子            |
| 6-7        | Flags + Fragment   | フラグメント情報          |
| 8          | Time to Live (TTL) | 生存時間                  |
| 9          | Protocol           | プロトコル (6=TCP)        |
| 10-11      | Header Checksum    | チェックサム              |
| 12-15      | Source IP          | 送信元IPアドレス |
| 16-19      | Destination IP     | 宛先IPアドレス   |

受信したパケットからIPヘッダーをパース

重量なのは送信元IPアドレス、宛先IPアドレス

struct IpHeader {
    version: u8,
    ihl: u8,
    src_ip: [u8; 4],
    dst_ip: [u8; 4],
}

impl IpHeader {
    fn parse(data: &[u8]) -> Option<Self> {
        if data.len() < 20 {
            return None;
        }

        let version_ihl = data[0];
        let version = version_ihl >> 4;  // 上位4ビット
        let ihl = version_ihl & 0x0F;    // 下位4ビット

        Some(IpHeader {
            version,
            ihl,
            src_ip: [data[12], data[13], data[14], data[15]],
            dst_ip: [data[16], data[17], data[18], data[19]],
        })
    }
}

ビット演算でバージョンとヘッダー長を取り出す。

2. TCPヘッダー解析

TCPヘッダーの理解（RFC 793）とパース。

TCP ヘッダーの構成

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        | ← 0-3バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        | ← 4-7バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      | ← 8-11バイト
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             | ← 12-15バイト
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| バイト位置 | フィールド            | 説明                     |
|------------|-----------------------|--------------------------|
| 0-1        | Source Port           | 送信元ポート番号         |
| 2-3        | Destination Port      | 宛先ポート番号           |
| 4-7        | Sequence Number       | シーケンス番号           |
| 8-11       | Acknowledgment Number | ACK番号                  |
| 12         | Data Offset           | ヘッダー長               |
| 13         | Flags                 | SYN, ACK, FIN等 ← 重要！ |
| 14-15      | Window                | ウィンドウサイズ         |
| 16-17      | Checksum              | チェックサム             |
| 18-19      | Urgent Pointer        | 緊急ポインタ             |

TCP ヘッダーのパース

struct TcpHeader {
    src_port: u16,
    dst_port: u16,
    seq_num: u32,
    ack_num: u32,
    flags: u8,
}

フラグ判定が重要

const TCP_FIN: u8 = 0x01;　// もう送るデータはありません
const TCP_SYN: u8 = 0x02;　// 接続開始要求
const TCP_PSH: u8 = 0x08;　// バッファに溜めず、すぐアプリに渡してほしい
const TCP_ACK: u8 = 0x10;　// 受信確認

fn is_syn(&self) -> bool {
    self.flags & TCP_SYN != 0
}

3. SYN-ACKパケット作成

ここが一番ハマった。

問題1: カーネルがRSTを送ってくる

SYNを受信してSYN-ACKを返そうとすると、カーネルが勝手にRSTパケットを送信してしまう。カーネルから見ると「知らないポートへのSYN」なので、RSTで拒否するのは正しい動作。

解決: iptablesでRSTをブロック

これでカーネルのRSTを破棄できた。
実用性皆無。

1	iptables -A OUTPUT -p tcp --tcp-flags RST RST --sport 8888 -j DROP

問題2: SYN-ACKがeth0に出る

SYNはloインターフェースから来るのに、SYN-ACKがeth0から出て行ってしまう。

解決: 送信用ソケットをloにバインド

受信用と送信用でソケットを分けることで解決。
これまた実用性皆無。

unsafe fn create_send_socket() -> Result<c_int, String> {
    let sock = libc::socket(AF_INET, SOCK_RAW, IPPROTO_TCP);

    // loインターフェースにバインド
    let interface_name = b"lo\0";
    libc::setsockopt(
        sock,
        libc::SOL_SOCKET,
        libc::SO_BINDTODEVICE,
        interface_name.as_ptr() as *const c_void,
        interface_name.len() as u32,
    );

    Ok(sock)
}

4. チェックサム計算

IPとTCPのチェックサムを計算する必要がある。

fn calculate_checksum(data: &[u8]) -> u16 {
    let mut sum: u32 = 0;
    let mut i = 0;

    // 2バイトずつ足していく
    while i < data.len() - 1 {
        let word = u16::from_be_bytes([data[i], data[i + 1]]);
        sum += word as u32;
        i += 2;
    }

    // 桁上がりを折り返す
    while sum >> 16 != 0 {
        sum = (sum & 0xFFFF) + (sum >> 16);
    }

    // 1の補数
    !sum as u16
}

TCPは疑似ヘッダーを含めてチェックサムを計算する：

fn calculate_tcp_checksum(src_ip: &[u8; 4], dst_ip: &[u8; 4], tcp_segment: &[u8]) -> u16 {
    let tcp_len = tcp_segment.len() as u16;

    let mut pseudo = Vec::new();
    pseudo.extend_from_slice(src_ip);
    pseudo.extend_from_slice(dst_ip);
    pseudo.push(0);
    pseudo.push(6);  // Protocol = TCP
    pseudo.extend_from_slice(&tcp_len.to_be_bytes());
    pseudo.extend_from_slice(tcp_segment);

    calculate_checksum(&pseudo)
}

5. データパケット送受信

コマンドを受け取って、レスポンスを返す部分。

// コマンド受信
let data = &buffer[data_offset..recv_len as usize];
let command = String::from_utf8_lossy(data).trim().to_string();

// レスポンス生成
let response = match command.as_str() {
    "toppage" => "hello world\n",
    "about" => "This is TCP server\n",
    "help" => "Available commands: toppage, about, help\n",
    _ => "Unknown command\n",
};

// データパケット送信
let data_packet = build_data_packet(
    my_server_ip,
    conn.client_ip,
    8888,
    conn.client_port,
    conn.server_seq,
    conn.client_seq,
    response.as_bytes(),
);

6. FIN処理 (最後の仕上げ)

最初はncが終了しなかった。

問題: ncが終了を待っている

データを受信しても、ncは接続を閉じずに待機していた。

1. nc → サーバー: "toppage" (PSH+ACK)
2. サーバー → nc: "hello world" (PSH+ACK)
3. nc → サーバー: ACK
4. 【ここで待機】← ncがサーバーの切断を待っている

解決: サーバーからFIN-ACKを送る

データレスポンス送信直後に、サーバーからFIN-ACKを送ることで解決。

// データ送信
send_packet(send_sock, &data_packet, conn.client_ip)?;

// 即座にFIN-ACK送信
let fin_ack = build_fin_ack_packet(
    my_server_ip,
    conn.client_ip,
    8888,
    conn.client_port,
    conn.server_seq,
    conn.client_seq,
);

send_packet(send_sock, &fin_ack, conn.client_ip)?;

これでncが自動終了するようになった！

1 2	$ echo "toppage" \| nc 172.17.0.2 8888 hello world

入力のパケットをWiresharkで確認

出力のパケットをWiresharkで確認

最終的なパケットフロー

%%{init: {'theme':'forest'}}%%
sequenceDiagram
    participant Client as クライアント(nc)
    participant Kernel as Linuxカーネル(TCPスタック)
    participant Program as プログラム(Raw Socket)

    Note over Client,Program: ① 3ウェイハンドシェイク

    Client->>Kernel: SYN (lo)
    Kernel->>Program: SYN
    Note right of Program: 受信

    Kernel--xClient: RST (blocked!)
    Note left of Kernel: iptablesで破棄

    Note right of Program: SYN-ACK作成
    Program->>Client: SYN-ACK (lo)
    Note right of Program: 送信

    Client->>Kernel: ACK (lo)
    Kernel->>Program: ACK
    Note right of Program: 受信
Established

    Note over Client,Program: ② データ交換

    Client->>Kernel: PSH+ACK ("toppage") (lo)
    Kernel->>Program: PSH+ACK ("toppage")
    Note right of Program: 受信
コマンド解析

    Program->>Client: PSH+ACK ("hello world") (lo)
    Note right of Program: 送信

    Client->>Kernel: ACK (lo)
    Kernel->>Program: ACK
    Note right of Program: 受信

    Note over Client,Program: ③ 接続クローズ

    Program->>Client: FIN+ACK (lo)
    Note right of Program: 送信
接続リセット

    Client->>Kernel: FIN+ACK (lo)
    Kernel->>Program: FIN+ACK
    Note right of Program: (無視)

    Note left of Client: 終了
    Note over Kernel: 無視
    Note right of Program: 次の接続待機

学んだこと

Rustの基本的な構文（構造体、パターンマッチ、Option<T>、テスト）は触ってて楽しかった。

TCPの3ウェイハンドシェイクは理論では知ってたけど、実装してみるとシーケンス番号とACK番号の管理が思ったより重要だった。チェックサム計算も疑似ヘッダー含めて計算する必要があって、細かい仕様が多い。

ハマったポイントは：

macOSのloopback制限でDocker使った
カーネルが勝手にRST送ってくるのをiptablesでブロック（実用性皆無）
送信パケットがeth0に出ちゃうのを送信用ソケット分離で解決（これも実用性皆無）
ncが終了しない問題はサーバーからFIN送って解決

おわりに

最初は「SYNパケット受信してSYN-ACK返すだけでしょ？」って思ってたけど、予想外に面倒だった。でもWiresharkでパケット見ながら「ちゃんと動いてる！」ってなるのは楽しい。

ということでRustを学んでいきました〜
仕事でも活用していきたい〜

今回使ったコードは以下
https://github.com/kurum-inc/rust-l4-echo-server

2024-10-28

GitHub Actions で OIDC を使用して AWS 認証ってどういう仕組みなん？

いやー久しぶりってレベルじゃないぐらいのレベルでブログ書いてます。

みなさんはGithub Actionsを使って、AWSにデプロイしたり、ファイルをアップロードしたりってしますかね？

その際にこんなこと思ったことありませんか？

これどういう仕組みでAWSとやりとりしてんだろ？

GitHub Actionsではロール名だけ教えればAWSと連携できちゃうなんて、そんなに簡単に認証できていいわけ！？

このように思ったのは私だけ？

というわけで、GitHub Actions で OIDC を使用したAWS認証の仕組みの謎を追っていきたいと思います🧭

ちょっとその前に

そもそもOIDCってなんだっけ？

OIDC（OpenID Connect）は OAuth 2.0 を拡張した仕様

OAuth 2.0は認可の仕組みで、認証に使われちゃったりする問題（認可情報を認証としてつかってしまう問題）がでてきたので、ちゃんと認証の仕組みいれようということで出てきた仕組み。（雑な説明ですいません）

OAuth 2.0がアクセストークンで認可をするのに対して、OIDCではIDトークンで認証を行う。

参考：
https://www.sakimura.org/2012/02/1487/

AWS AssumeRole（アシュームロール）ってよく聞くどあんま理解できてない

AssumeRole（アシュームロール）は簡単にいうと「一時的に他の役割を借りる」ことです。
特定の権限を持つIAMロールを引き受けることができます。

例えば、GitHub ActionsがAWSのS3とかLambdaとかにアクセスする権利が一時的に与えられます。

STSもよくきけどなんなん？

STSもよく聞くけど、これは「AWS Security Token Service」の略で、AWSのサービスの一つです。
STSは一時的なセキュリティ認証情報（トークン）を生成するために使用されます。これにより、ユーザーやアプリケーションは一時的なアクセス権を持つことができ、長期的なアクセスキーを使用する必要がなくなります。

OIDCトークンというものがある

OIDCトークンはJSON Web Token (JWT) 形式で発行されている。

今回の場合はGithub Actionsから払い出されるトークンで、ジョブ実行時の情報やレポジトリの情報も含まれる。

GithubActionsのOIDCトークンの仕様は以下
https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token

事前設定

1. AWS: Github Actionsのフィンガープリントを設定

フィンガープリント（TLS証明書の一意なハッシュ値）を事前に設定することで、AWSはGitHub以外の第三者が偽の公開鍵を提供しても、それが正当な公開鍵でないことを判別できます。これにより、公開鍵のなりすましを防ぎます。

~~公開鍵は後のOIDCトークンの署名（Github Actionsが署名したOIDCトークンかをチェック）に利用。~~

フィンガープリントの設定不要になってました。
https://github.com/aws-actions/configure-aws-credentials/issues/357#issuecomment-1626357333

信頼性の高いCAライブラリで通信を保護してるから改善されないってことでしょうかね。

2. AWS: クライアント IDの設定

AWS側で「クライアントID」を設定することで、GitHub ActionsからAWSに送られてくるトークンが、AWSで利用されることを確認します。
具体的には、GitHub Actionsが発行するOIDCトークンの「aud」（オーディエンス）クレームに「sts.amazonaws.com」というクライアントIDが含まれているかをAWSでチェックします。

3. AWS: Githubのレポジトリーを設定

GitHub ActionsがAWSリソースへアクセスできるようにするには、AWS側でどのGitHubリポジトリを信頼するか設定します。これにより、特定のリポジトリだけがAWSのリソースにアクセスできるように制限できます。

OIDCトークンに含まれるレポジトリ名が一致するか検証するのに利用

"Condition": {
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref/heads/main"
  }
}

4. Github Actions用のロール作成

GitHub ActionsがAWSリソースにアクセスするためのIAMロールを作成します。このロールには、GitHub Actionsが利用する特定のリソースや操作に対するアクセス権限を設定します。

例）S3バケットへの読み書き権限をあたえるなど

Github Actionsのジョブ実行

それでは、おおまかな流れを見ていきましょう！

%%{init: {'theme':'forest', 'primaryColor': '#ff0000'}}%%
sequenceDiagram
    participant GitHub_Actions as GitHub Actions
    participant AWS as AWS
    participant AWS_Secrets as AWS STS

    GitHub_Actions->>GitHub_Actions: 1. OIDCトークンの署名\n(ヘッダー, ペイロード, 署名)
    GitHub_Actions->>AWS: 2. OIDCトークンの送信\n(ヘッダー, ペイロード, 署名)

    AWS->>GitHub_Actions: 3. 信頼性の高いCAライブラリで安全に公開鍵を取得

    AWS->>AWS: 4. OIDCトークンの署名の検証\n(Base64URLデコードして確認)
    AWS->>AWS: 5. トークンの検証\n(発行者, 受信者, 有効期限)

    AWS->>AWS_Secrets: 6. 一時的な認証情報の発行\n(IAMロールを引き受け)
    AWS_Secrets-->>GitHub_Actions: アクセスキー, シークレットアクセスキー, セッショントークン

    GitHub_Actions->>AWS: 7. 一時的な認証情報の使用\n(AWSリソースにアクセス)

1. GitHub Actions: OIDCトークンの署名

GitHub Actionsは、ジョブの実行中にOIDCトークンを取得します。このトークンはJWT形式で、ヘッダー、ペイロード、署名の3つの部分から構成されています。
GitHubは、トークンのヘッダーとペイロードを自身の秘密鍵で署名（ハッシュ化）して、署名部分を作成します。

2. GitHub Actions: OIDCトークンの送信

GitHub Actionsは、作成したOIDCトークン（ヘッダー、ペイロード、署名）をAWSに送信します。

3. AWS: 公開鍵の取得

AWSは、事前に設定されたTLS証明書のフィンガープリントを使用して、GitHubの公開鍵を取得します。この公開鍵は、GitHubのOIDCエンドポイントから取得したTLS証明書に含まれています。

信頼性の高いCAライブラリでtokens.actions.githubusercontent.comから安全に公開鍵を取得。

4. AWS: 署名の検証

AWSは、受信したOIDCトークンのヘッダーとペイロードをBase64URLデコードします。
AWSは、GitHubの公開鍵を使用して、トークンの署名を検証します。具体的には、トークンのヘッダーとペイロードを再度ハッシュ化し、その結果がトークンの署名部分と一致するかどうかを確認します。

[個人的重要ポイント]

公開鍵で検証できるのは、**GitHubしか秘密鍵を持っていないからこそ可能**な仕組みです。

5. AWS: トークンの検証

署名が一致する場合、AWSはトークンが改ざんされていないことを確認します。
AWSは、トークンのペイロードに含まれるクレーム（例：発行者、受信者、有効期限など）を検証します。

AWSは、トークンのaudクレームが「sts.amazonaws.com」であることを確認し、それがAWS用のトークンであることを認識します。また、token.actions.githubusercontent.com:subが事前に設定したリポジトリーと一致するかを確認し、許可されたリポジトリーからのトークンであることをチェックします。

6. AWS: 一時的な認証情報の発行

トークンが有効であることが確認された場合、AWS STSは指定されたIAMロールを引き受けるための一時的な認証情報（アクセスキー、シークレットアクセスキー、セッショントークン）を発行します。

7. GitHub Actions: 一時的な認証情報の使用

GitHub Actionsは、取得した一時的な認証情報を使用して、指定されたAWSリソースにアクセスします。

という感じでOIDCの仕組みを使ってうまいことやりとりをしていましたというお話でした。

では👋

参考サイト

2020-05-15

メモ

NATを越えろ

自宅のデスク周りを充実させまくったら、部屋から完全に出不精になってしまいました。

ビデオ会議をする機会が大分増えてきて、今後もビデオチャットで仕事をすることや、プライベートでも活用の幅がふえてくるのでは？ということでせっかくなのでWebRTC※1でビデオチャットを実装した際にNATについて色々学びがあったのでここでアウトプット。

※1. Web Real-Time Communicationの略でブラウザで気軽にP2P通信ができるようにしたもの（オープン標準技術）

以下WebRTCのプロトコルスタック
主に赤枠の部分についての話

図：オライリー

そもそもNATってなんやねん

NAT（Network Address Translation）とは、コンピュータネットワークにおいて、主にグローバルIPアドレスをプライベートIPアドレスに、またはその逆の変換を行う技術のことである。

by wikipedia

つまりプライベートアドレスをグローバルアドレスに変換してインターネット上のアドレスとやりとり出来るようになる

ローカルネットワークとグローバルネットワークを行き来するための仕組み

静的・動的?

静的NAT

グローバルアドレスとプライベートアドレスを1対1の固定ペアとして変換を行う

動的NAT

外部への通信が発生したときに、プール内のグローバルアドレスを使用して変換を行う

NAPT（動的）

NAPT（Network Address Port Translation）とは、アドレスに加えてポート番号も変換する技術。
グローバルアドレスがひとつしかない場合でも、変換時に動的に割り当てた送り元Portを元にどの端末の通信かの関連付けを行うことができる。

家や会社で複数の端末が一つのグローバルIPで同時にインターネットができるのはこの仕組みのおかげ

送り元IP:送り元ポート、送り先IP:送り先ポートの組で接続ごとに管理している

NATタイプ

一口にNATと言っても挙動には個性があって、大きく分けると2系統ある。

Cone系: 接続先が変わっても同じ変換（同じ外向きIP:ポート）を使い回すタイプ
Symmetric: 接続先ごとに別の変換を割り当てるタイプ

さらにCone系は「外から来たパケットをどこまで通すか」の厳しさで3段階に分かれるので、合計4タイプ。緩い順に見ていく。

Full cone NAT（フルコーンNAT）

一度どこかへ送信して変換エントリさえ作られれば、送信したことがない相手からでも受信可能
※UPnPのポートマッピングはほぼこれに該当する

Address-Restricted cone NAT（制限付きコーンNAT）

一度送信した相手のアドレスから（NATデバイス上に送信先アドレスのエントリが存在する場合）であれば、ポートを問わず受信可能

Port-Restricted cone NAT（ポート制限付きコーンNAT）

一度送信した相手のアドレスとPortの両方が一致する場合（NATデバイス上に送信先アドレスとPortのエントリが存在する）のみ受信可能

Symmetric NAT（対称型NAT）

対称型NATは最も制限の厳しいもので、宛先アドレスとポートを用いて接続先を区別し、接続先ごとに別のアドレス変換（ポート）を割り当てる。
そのため後述のSTUNで調べたアドレスが他の相手との通信には使い回せない

Nat traversal（NAT越えの手法）

なんでこんなにタイプ分けの話をしたかというと、P2Pは「相手のNATの外から中へパケットを届ける」ことをやらないといけなくて、さっきの「外から来たパケットをどこまで通すか」という性格の違いが、そのままNATの越えやすさになるから。緩いFull coneなら穴を開けやすく、一番厳しいSymmetricになると後述のSTUNで調べたアドレスすら使い回せない。

とはいえ人様のPCに外部から接続なんて、冷静に考えたら厳しいのは当たり前ではあるのですが(; ･`д･´)

NATを越えるための手法はいくつかあって、ルーターで対応してるもの（UPnP）や、connection reversalなどがありますが、
WebRTCではSTUNという仕様で自分の変換後のアドレスを調べ、それを使って行うUDP hole punchingについてちょっと触れてみた。

UDP hole punching

上記Cone型による接続を行う際にファイヤーウォールとかどうやって突破すんねんって疑問が沸くかと思いますが、
それをうまいことするのがこのUDP hole punching。

上記の仕組みを使うことで、NAT外サーバーを経由してアドレス交換（STUN SERVERで自分の変換後のアドレスを確認し、SIGNALING SERVER経由で相手と交換）を行い、NAT内ホスト同士でも直接通信を開始できるようにしている。

で、うちはどのConeやねん

図だけだとほんまかいなという感じなので、うちのNATを実際に調べてみた。

まず、別々のSTUNサーバー2つ（GoogleとCloudflare）に同じソケットからBinding Request（「私のIPとポートをおしえて」）を投げてみると、どちらからも同じ203.0.113.1:23081が返ってきた。接続先が変わっても同じ変換を使い回している＝うちはCone系。

※203.0.113.1は文書の例示用に予約されているダミーのIPアドレス（RFC 5737）です。実際のグローバルIPをこれに置き換えていて、以降のログやスクショも同様です

で、同じCone系でも「外からのパケットをどこまで通すか」の厳しさは概念として3段階に分かれるのだった。

Full cone: 一度穴が開けば誰からでも届く
Address-Restricted: 送ったことのあるIPからなら届く
Port-Restricted: 送ったことのあるIP:ポートの組からしか届かない

どれなのかをちゃんと判定する仕組み（STUNのCHANGE-REQUEST属性で「返事を別のIP・ポートから送って」とお願いして届くか見る）もあるにはあるが、対応している公開サーバーが少ないのもあって今回は割愛。

というのも、3つをよく見ると「自分が送った相手のIP:ポートからの返事は通す」だけはどれも共通している。つまり両側がお互いに向かって一発ずつ撃ち合えば、どのCone同士でも両側の条件が満たされて穴が開くはず。相手がSymmetric（そもそもSTUNで調べたアドレスが使い回せない）でない限り、判定するまでもなく通せてしまうのがUDP hole punchingの賢いところ。

ほんまに通るんかい

というわけで仕上げに、hole punching本番。相手はモバイル回線にテザリングで繋いだWindows（＝別のNATの向こう側）を用意した。

手順は雑で、両方でSTUNに自分の外向きアドレスを聞く→チャットで教え合う（シグナリングサーバーの役を人力でやる）→お互い相手のIP:ポートへUDPを撃ち合うだけ。スクリプトはこちら。

$ node nat-punch.js
[LOCAL] ポート58396のUDPソケットで開始
相手のアドレスを入力（例 203.0.113.1:23081）> [STUN] あなたの外向きアドレス: 203.0.113.1:39464
       ↑これを相手に伝えてください（相手のアドレスも聞いておく）
198.51.100.7:44308
[PUNCH] 198.51.100.7:44308 へ0.5秒間隔で撃ち込みます...
[RECV] 198.51.100.7:44308 からACKが届いた = こちら→相手も通ってる
*** 双方向で貫通。hole punching成功です ***

通りました！（相手側のIPも例示用のダミーに置き換えてます）

これもtcpdumpでキャプチャした。最初のPUNCHを送った0.12秒後に、相手からのパケット（ACK）が届いているのが写っている。穴が開いた瞬間。

一度も直接会話したことがなかった2台が、お互いに一発撃った瞬間に繋がった。フィルタの条件「送った相手のIP:ポートからなら通す」を、両側が同時に満たしに行くのがhole punchingということ。

ちなみに今回チャットで人力コピペしたアドレス交換は、実際のサービスではシグナリングサーバーが全自動でやっている。お互いアプリを開いた時点で自分からサーバーに繋いでおき（自分から外へ繋ぐ分にはNATに邪魔されない）、サーバーはその接続越しに連絡先を取り次ぐだけの電話交換手。交換が済めば、映像や音声は今回と同じくサーバーを経由せずP2Pで直接流れる。

おまけ：Cone系かどうかって誰が決めてるの？

ところで、NATタイプの話で「接続先が変わっても同じ変換を使い回す優しいCone系」と「接続先ごとに変換を変える厳しいSymmetric」という性格の違いが出てきた。あれって誰が決めているのか？

決めているのはルーター。ルーターはネットの出入り口に立っている門番さんで、外から来たパケットをどこまで通すかはこの門番さんの方針次第。法律（規格）で決まっているわけではない。

家のルーターは「ゲームやビデオ通話が繋がらなくなると困るから、あまり厳しくしないでね」という業界のお約束（RFC 4787）もあって、優しめのCone系が多数派。逆に会社の門番（ファイアウォールやキャリアグレードNAT）は、セキュリティや経費の都合で「さっき話した相手以外は全員お断り！」なSymmetricだったりする。

同じPCなのに、家ではP2Pが繋がって会社では繋がらないことがあるのは、PCのせいではなく門番さんの性格の違いというわけ。

用語集（ざっくり）

NAT / NAPT: プライベートアドレスとグローバルアドレスを変換する仕組み。NAPTはポート番号まで変換して1つのグローバルIPをみんなで共有するやつで、家のルーターはだいたいこれ
グローバルIP / プライベートIP: インターネットで通用する住所 / LANの中でだけ通用する住所
変換エントリ: 「中の192.168.x.x:ポート ⇔ 外の203.0.113.1:ポート」という対応表の1行。門番さんの通行記録
Cone系NAT: 接続先が変わっても同じ変換を使い回すタイプ。外からのパケットをどこまで通すかで、Full cone / Address-Restricted / Port-Restrictedの3段階に分かれる
Symmetric NAT: 接続先ごとに別の変換を割り当てる一番厳しいタイプ。STUNで調べたアドレスが他の相手に使い回せない
STUN: 「あなたは外からこう見えてますよ」と教えてくれる鏡のようなサーバー。教えてくれるだけで、データの中継はしない
Binding Request: STUNサーバーへの質問パケット。「私のIPとポート番号をおしえてください」
シグナリング: お互いのアドレスなどの接続情報を交換すること。専用サーバーを立てるのが普通だが、今回はチャットのコピペで人力代行した
UDP hole punching: 両側から同時に撃ち合うことで、お互いの門番に「この相手は許可済み」と認識させて穴を開ける技。この記事の主役
TURN: hole punchingが通用しない相手（Symmetric同士など）のときに、全データを代わりに運んでくれる中継サーバー。帯域を食うので最終手段の保険。今回は出番なし
ICE: 直接接続・STUN経由・TURN中継の候補を全部並行で試して、繋がったものを使うWebRTCの総当たり係。この記事で人力でやったことを全自動でやってくれる
RFC 4787: 「変換は宛先非依存にすべし（=Cone系にしてね）」という業界のお約束。家庭用ルーターにCone系が多い理由

NATってなんやねん、から始まって、STUNに自分の姿を聞いて、両側から撃ち合って、無事にNATを越えられました。ビデオ会議の裏でも毎回この穴あけが行われていると思うと、なんだか愛着が湧いてきます。それでは安心して引きこもります(*´з`)

2019-10-22

tips

DNSのデバックのおともにdigコマンド

DNSサーバーの動作確認をする際のコマンドとして、nslookupとか使って対話的に確認したりすると思うけど、
どうやらUNIX, Linux的に非推奨だということが（今更）分かり、digコマンドをようやく使ってみたメモです。

また、nslooupより高機能らしいので高機能好きの僕には今が覚える好機。（いみふ）

ちなみにwindowsには標準ではいってないので使う方は頑張ってインストールしてください。

まずはシンプルに実行

実行コマンド

1	$ dig google.com

実行結果

[admin@localhost ~]$ dig google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-73.el7_6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17627
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             299     IN      A       216.58.197.142

;; Query time: 54 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: 火 10月 22 17:45:30 JST 2019
;; MSG SIZE  rcvd: 55

確かにnslookupより情報量が多い( ﾟДﾟ)

status	応答コード
NOERROR	正常
REFUSED	拒否

flags	応答コード
qr	サーバーからの回答が正常に行われた
rd	再帰的問い合わせを要求
ra	サーバが再帰的問い合わせをサポート

※ここでいう再起はプログラミング的な再起処理ではなくて、「再び帰ってくる」という意味でちゃんとした結果を返してくることをサポートしますよ！ということ。

1
2
3

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17627
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Question

オプションに何も指定せずに実行するとクエリタイプが「a」になるっぽい

1 2	;; QUESTION SECTION: ;google.com. IN A

Answer

Aレコードの内容がきちんと見れました

1 2	;; ANSWER SECTION: google.com. 299 IN A 216.58.197.142

リソースを指定したい場合

■ ns（ネームサーバー）

実行コマンド

1	$ dig ns google.com

実行結果

Answerセクション部分のみ抜粋

;; ANSWER SECTION:
google.com.             19288   IN      NS      ns3.google.com.
google.com.             19288   IN      NS      ns1.google.com.
google.com.             19288   IN      NS      ns4.google.com.
google.com.             19288   IN      NS      ns2.google.com.

■ mx（メール交換情報）

実行コマンド

1	$ dig ms google.com

実行結果

Answerセクション部分のみ抜粋

1 2	;; ANSWER SECTION: google.com. 234 IN A 172.217.161.46

■ any

実行コマンド

1	$ dig any google.com

実行結果

全部入り的なやつ

Answerセクション部分のみ抜粋

;; ANSWER SECTION:
google.com.             299     IN      A       216.58.197.142
google.com.             299     IN      AAAA    2404:6800:4004:800::200e
google.com.             21599   IN      NS      ns1.google.com.
google.com.             599     IN      MX      30 alt2.aspmx.l.google.com.
google.com.             599     IN      MX      10 aspmx.l.google.com.
google.com.             599     IN      MX      20 alt1.aspmx.l.google.com.
google.com.             299     IN      TXT     "docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"
google.com.             21599   IN      NS      ns2.google.com.
google.com.             599     IN      MX      50 alt4.aspmx.l.google.com.
google.com.             21599   IN      NS      ns3.google.com.
google.com.             599     IN      MX      40 alt3.aspmx.l.google.com.
google.com.             3599    IN      TXT     "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
google.com.             59      IN      SOA     ns1.google.com. dns-admin.google.com. 275806207 900 900 1800 60
google.com.             3599    IN      TXT     "v=spf1 include:_spf.google.com ~all"
google.com.             21599   IN      NS      ns4.google.com.
google.com.             3599    IN      TXT     "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com.             21599   IN      CAA     0 issue "pki.goog"
google.com.             299     IN      TXT     "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"

ネームサーバーを指定する場合

ネームサーバー切り替え前にデバックするときに重宝する

実行コマンド

1	$ dig a google.com 8.8.8.8

必要最低限の情報だけほしい場合

実行コマンド

+shortをつけるだけ！

1	$ dig ns google.com +short

実行結果

大分、目に優しい感じで表示されます

ns3.google.com.
ns2.google.com.
ns4.google.com.
ns1.google.com.

2017-10-17

メモ

メールが送信されるまでをパケットを見ながら解剖！

以前、コマンドだけでメールを送信する記事を書きましたが、
メール送信の一連の流れをパケットで追いかけていきたいと思います！

人物相関図

下記のソースを使えば、上記の図の構成でDocker環境を構築することができ、実際に動作を検証することができます。
https://github.com/kuniiskywalker/mail-tester

登場人物

送信君（送り手のメールサーバー）

IP：10.5.0.6
ドメイン：fuga.local

受信君（受け手のメールサーバー）

役割：メールサーバー
IP：10.5.0.5
ドメイン：hoge.local

案内マン（ネームサーバー）

IP：10.5.0.4

あらすじ（送信完了までの送信サーバーのパケットの流れ）

この図を元に解説していきます。

① 送信先メールアドレスのMXレコード確認

※MXレコード：メールの送信先IPアドレスが設定されたDNSレコード。

送信君：

root@hoge.localに送信したいので、hoge.localのMXレコード教えてください

案内マン： MXレコードは`mail.hoge.local`です。

送信君：

ではmail.hoge.localのIPアドレスを教えてください。

案内マン：

10.5.0.5です。

② TCPハンドシェイク

送信君：

はじめまして受信君！
案内マンからIPアドレスきいてご連絡しました！
今からメールを送るためのやり取りしたいのですがいいですか？

受信君：

はい大丈夫です！

送信君：

ありがとうございます！

③ EHLO

※EHLOとはSMTP拡張機能を使うために送信者と受信者でお互いにサポートしてる機能をあわせて使用しましょうというやり取り。

受信君：

メール受信を行う上での開始準備できてます！

送信君：

それではまず、受信君はどういった機能をサポートしてるか知りたいので、教えてもらっていいですか？

受信君：

↓こういうやつに対応してます！

SIZE：受信可能サイズ 10240KB

PIPELINE:SMTPで送信を行うための準備に使うコマンドを一括実行できる

他は割愛。。。

送信君：

ありがとうございます！

PIPELINE対応してるんですねー、ではまとめて送信メールアドレスとか、送り元メールアドレスを送りますので、送信可能かどうか確認お願いします！

※MAIL FROM, RCTP TO, DATAコマンドを使って上記の確認を行う。

※1個ずつ実行していく場合は通信の利用効率が悪くなるため、こういった方式が導入されている。

⑤ 送信可否結果

受信君：結果をまとめてお返しします！

受信君：ありがとうございます！全部OKそうですね！

⑥ メール送信

送信君：結果うけとりました！メールを送信を許可いただきありがとうございます！

それではroot@hoge.local宛てに、差出人root@fuga.localとして、件名：test、本文:This is test mail.でお送りします！

まとめ

登場人物も含めてやり取りをまとめてみました！

ちょっと駆け足で書いたので、ちょっとずつ修正します。。。

ローカル環境でメールの送受信の確認ができる環境をDockerでつくったのでご活用ください！
https://github.com/kuniiskywalker/mail-tester

2017-09-06

メモ

SNIのメモ

SNIのパケット覗き見

SNI（Server Name Indication）とは？

apacheのTLS通信用バーチャルホストをネームベース（ホスト名）で設定できる技術。
通常TLS通信の場合は、ホスト名も含めて暗号化されるからapacheは対応するバーチャルホストを見つけることができず、IPで見分けるしかなかった。

つまりIPひとつに対して443ポートが一つしか関連付けできないため、
事実上、IPに対してひとつしかTLSのバーチャルホストを設定できなかった。

そこで、ホスト名を暗号せずにブラウザから送信して、ネームベースでバーチャルホストの設定をできるようにする技術をSNI（Server Name Indication）と呼ぶらしい。

TLS拡張（RFC4366）
http://www.ipa.go.jp/security/rfc/RFC4366JA.html

検証したこと

俺俺TLS証明書
httpd-ssl.confに以下バーチャルホストを設定
chromeで https://test1.localhost にアクセス
実際パケット上でサーバー名がどうやって送信されるかwiresharkで確認

httpd-ssl.confの設定例

<VirtualHost *:443>
    ServerName test1.localhost
    DocumentRoot "/usr/local/apache2/htdocs"
    SSLEngine on
    SSLCertificateFile "/usr/local/apache2/conf/server.crt"
    SSLCertificateKeyFile "/usr/local/apache2/conf/server.key"
</VirtualHost>

パケット

TLSハンドシェイクのClient Hello時（Client Helloについてはこちら）にTLS拡張で暗号化せずにserver_nameを送信してる。
おそらくapacheはこの情報をみてバーチャルホストを判定してる。

まとめ

パケットを見て分かるように、クライアントからservernameを暗号せずに送信してるため、当然のごとくクライアント側の実装依存になってしまい、旧ブラウザとか使えない（今はどうか知らない。。。）

apacheの設定をすることもめっきり減りましたが、ちょっとレンタルサーバーいじってて気になったのでメモしてみました(´・ω・｀)

2017-09-06

メモ

tlsハンドシェイクのメモ

tlsハンドシェイクとかわけわかめだったのでメモ。

やったこと

1. TLSの俺俺証明書作成

1
2
3

$ openssl genrsa 2048 > server.key
$ openssl req -new -key server.key > server.csr
$ openssl x509 -days 3650 -req -signkey server.key < server.csr > server.crt

2. dokcerでapacheたてて、tcpdumpでパケットキャプチャー

apache用dockerコンテナー

https://github.com/kuniiskywalker/docker-test-capture-https

apache設定内容

DH鍵交換（DHE）無効

クライアントとサーバーで一時的な秘密鍵を生成して共通鍵を交換する安全な方法ですが、wiresharkで復号できないためRSAを使った鍵交換のみに設定。
但しクライアント側でもDHEを無効にしないと意味ない。

1 2	# SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES SSLCipherSuite kRSA

SSLのキャッシュ無効

キャッシュを利用されると二回目以降とかの通信でhttpsの通信の一部を省略されてしまうため無効

#SSLSessionCache         "dbm:/usr/local/apache2/logs/ssl_scache"
#SSLSessionCache        "shmcb:/usr/local/apache2/logs/ssl_scache(512000)"
SSLSessionCache        none
SSLSessionCacheTimeout  300

3. クライアントからcurlでアクセス

ブラウザの設定でDHEを無効にするのが面倒だったので、curlで検証しました。。。

1 2	# dokcerが動いてるvmによって以下アクセス先は要変更 curl --cacert server.crt https://localhost

４. キャプチャしたパケットをwiresharkで眺める

Wiresharkを開き、キャプチャしたファイルを開く。

通信が開始されるまでの大まかな流れ

Hello交換

事前にこういう方式で暗号化のやりとりしますよという取り決め

鍵交換

暗号化に使う鍵の交換
（実際はパラメーターを送信しあってお互いに共通の鍵を作る）

データ通信

利用開始！
実際は暗号化されていて中身は暗号化されていて、よくわからない文字列で埋め尽くされている

1．Hello交換

ざっくり言うと私（クライアント）が暗号化方式とか諸々提示しますので、あなた（サーバー）がどうやって暗号化するか決めてください。

というやりとりっぽい。

◯client hello

プロトコルバージョン

TLS1.0, 1.1, 1.2などの接続に用いるプロトコルを提示

（クライアント：TLS1.2で接続でお願いします！）

疑似乱数

クライアント側で生成した乱数をサーバーに送信

（クライアント：後で鍵交換に使う文字列なので控えといてください！）

暗号化方式

候補値（複数可）を提示

（クライアント：暗号化方式をこの中からお選びください！）

圧縮方式

候補値（複数可）を提示

（クライアント：圧縮方式は無圧縮でお願いします！）

※過去に色々問題があったため無圧縮一択らしい

拡張

候補値（複数可）を提示

（クライアント：その他もろもろの拡張に使用するものはこの中からお選びください）

※拡張に関しては割愛します

◯server hello

プロトコルバージョン

クライアントから提示された接続に用いるプロトコルに合意

（サーバー：TLS1.2で接続了解しました！）

疑似乱数

サーバー側で生成した乱数をクライアントに送信

（サーバー：後で鍵交換に使う文字列なので控えといて！）

暗号方式（暗号スイート CipherSuite）

提示された暗号化方式を選択

（サーバー：TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)でOKです）

TLS_RSA：サーバーのRSA鍵を使った鍵交換アルゴリズム
今回は強制的にRSAを使う設定にしたのでこれが選択された模様
AES_256_GCM：共通鍵暗号のアルゴリズム
TODO:後で調べる
SHA384：MAC（メッセージ認証）のアルゴリズム
TODO:後で調べる

圧縮方式

提示された圧縮方式を選択

（サーバー：無圧縮でOKです）

◯Certificate

サーバーの証明書情報をクライアントへ。

◯Server Hello Done

Server Hello 終了

2．鍵交換

暗号化する際に使用する鍵を生成する。

◯Client Key Exchange

クライアントで生成したキーをサーバーに送信する。

鍵交換アルゴリズム

1. RSA

クライアント側で生成した共通鍵生成に必要な情報を、サーバー側の公開鍵を使って暗号化して、
サーバーに送信する。
悪い人に暗号化したデータをずっと保存されて、ある日サーバーの秘密鍵が漏洩してすべて解読されてしまうというリスクがある。

ClientKeyExchangeのみ行われる。

上記Certificateでサーバーから取得した認証情報から公開鍵を取り出し、「ランダムな文字列」を暗号化してサーバーに送信する。

以下の部分が暗号化された文字列

このPreMaster Secretの値を使って後述するクライアントとサーバーで使用する共通鍵を作成するっぽい。

2. DHE

サーバーの公開鍵ではなく、お互いに一時的に生成した秘密鍵/公開鍵のペアで公開鍵を送り合って、
共通鍵生成に必要な情報を暗号化して送り合う。
ServerKeyExchangeとClientKeyExchangeの２回の通信で鍵交換を行います

一時的に作成される鍵なのでサーバーの秘密鍵が漏洩しても安心！

数学苦手だけど、以下みたいな感じです。

これでお互いに安全に秘密値（PreMaster Secret）を送り合えます。

DHEだと一時的に作成した鍵を使用するので復号が面倒くさい。
今回は簡単に復号できるRSAを使用します。

（上記server helloの暗号化方式でTLS_RSAに合意をしている）

共有秘密鍵の算出

これまでのやりとには、鍵を生成するための前準備でした。
これでクライアントとサーバー側で通信を暗号化するために使う鍵を生成するための情報が出揃いました。

ECDHEというアルゴリズムで算出してるみたいですが、割愛します！
ざっくりいうと以下の情報でいい感じに鍵を作るってこと見たいです。

・Hello Clientでクライアントが生成した乱数
・Server Helloでサーバーが生成した乱数
・PreMaster Secret

◯Change Cipher Spec

新しい暗号化仕様の利用開始を通知

これでTLSハンドシェイクは終了

2．データ通信

これで晴れて暗号化通信が出来るわけです。

暗号化されたデータ通信

リクエストデータ

レスポンスデータ

通信内容の復号化

上記のままだと暗号化されててわけわかめだから、以下の設定で事前に作成した証明書をインポートすることでTLS通信内容が復号化でき中身が確認できる。

Preference->Protocols->SSL->RSA Key List->Editを選択し、以下を設定。

IP Address-> 172.17.0.2
Port->443
Protocol->http
Key File->俺俺証明書key（server.key）

リクエストデータ

レスポンスデータ

雑感

ちょーざっくりメモでした

2017-08-29

chrome extention

場所が分かりにくいAmazonプライムビデオの視聴履歴リンクをメニューに表示させるchrome拡張機能

夏も早いものでもう終わろうとしている今日この頃、皆さんはどのような動画をみてお過ごしでしょうか？
僕はAmazonプライムビデオのラインナップの豊富さをいいことに動画三昧の日々を送っています。
そんなAmazonプライムビデオのありそうでなかったchrome拡張機能を作ってみました。

場所が分かりにくい視聴履歴へのリンク

Amazonプライムビデオを使っていて以下のように思ったことはありませんでしょうか？

ちょっと前に見てた動画のタイトルを思い出せない！
スマホで途中まで見てたやつをPCでみたい！
過去に視聴した動画を見たい、

そんなとき視聴履歴を見たいという思いはは至極当たり前の心理だと思いますが、なぜか視聴履歴までたどり着くには以下のステップを踏まなければなりません。

ヘッダーの「マイストアへ」をクリック
「おすすめ商品を正確にする」をクリック
画面左部の「視聴済みのビデオ」をクリック

そんな頻繁に見ることがないとはいえ、いざ見たいと思ったときにこのステップを思い出すのは至難の業です。。。

視聴履歴をみるための方法をgoogleで検索なんてしてたら時間が勿体無いですね。

たった一つの解決方法。。。

この視聴履歴の分かりずらさはサイトの回遊率を上げるためのものなのか、プライバシー的なものなのかはさておき、視聴履歴を見る方法だけで検索するとそれだけで記事になってしまいそうなニーズ感がある以上、この問題を解決するためのソリューションを提供することが僕の使命であることは自明である。

この問題をシンプルに解く方法、それは。。。。

そう、ヘッダーに「視聴履歴」のリンクを追加することです！

使い方

chromeをお使いの方限定なのですが、以下URLから拡張機能の追加を行ってください。

https://chrome.google.com/webstore/detail/amazon-prime-video-fast-h/cfifaldajbjpfiafieifemojpfdiccbm

インストール後、再度Amazonプライムビデオのサイトに訪れるとヘッダーのメニューに「視聴履歴」へのリンクが追加されているはずです！

それではよいAmazonプライムビデオ生活を！！

機能に関するお問い合わせは以下からお願いします。
https://github.com/kuniiskywalker/AmazonPrimeVideoFastHistory/issues

2017-08-29

メモ

MySQLのwait_timeout実験

秘伝のバッチが突如悲鳴を上げるということは少なくないと思いますが、自分の知識不足から復旧に時間を要してしまった。

自戒もかねてメモを残す。

やばいクエリによるtimeoutでgone away

“MySQL server has gone away” が発生する原因としては以下の要因が考えられる。

クエリのサイズがでかすぎ
接続のアイドルタイムアウト

前者はmax_packet_sizeの値を調整して解決できる。
が、今回の原因は後者のタイムアウトの秒数だった。

接続が開始されてから、最後にデータベースに問い合わせをした時間から、指定した秒数たってしまうと、データベースはクライアントとの接続を勝手に切ってしまう。
接続が切れた状態でクエリを送信すると、「おまえの接続はもう切れてるぜ！」となりgone awayとなる。

この指定した秒数の謎についておいかけていきたいと思います(^O^)／

なぜ原因判明まで時間がかかってしまったのか

そもそも時間がかかりすぎるクエリがよくないのだが、明らかに設定された時間内より早いタイミングで切断されていた。

デフォルトだとおそらく2880秒で設定されている

% mysql -u root

mysql> SHOW VARIABLES LIKE 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

2880秒もたってないのになぜgone awayになるんだよ。。。

マニュアルに書いてあった。。。

以下公式からの引用

Interactive（対話型）で接続したやつはinteractive_timeoutの秒数をwait_timeoutとして設定しちゃうぜ！
ってことみたいです。

interactive_timeoutの秒数

% mysql -u root

mysql> SHOW VARIABLES LIKE 'interactive_timeout';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| interactive_timeout | 28800 |
+---------------------+-------+
1 row in set (0.00 sec)

じゃあ対話型じゃない場合はどうなるかっていうと

% mysql -u root -e "show variables like 'wait_timeout'"

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 60    |
+---------------+-------+

my.iniで設定されている数字がやっとでてきた。

アプリケーションから接続する際は非対話モード（Interactiveじゃない）になるので、
60秒が設定されていたため、早いタイミングで落ちていたみたいです。

28800秒で設定されるから他に原因があるのかと思い余計な時間をとられてしまった。。。

実験

前提

mysql 5.6
php7.1
pdo

実験1. wait_timeoutを5秒に設定して、DBに接続してからsleepを6秒いれた後、クエリを実行するとgone awayになるか確認。

<?php
define('WAIT_TIME', 6);

try {
  $pdo = new PDO('mysql:host=db;dbname=test;charset=utf8','root','pass',
array(PDO::ATTR_EMULATE_PREPARES => false));

  sleep(WAIT_TIME);

  $sql = "SELECT version();";
  $pdo->query($sql);
  
} catch (PDOException $e) {
  exit($e->getMessage());
}

見事gone away!

1	Warning: PDO::query(): MySQL server has gone away in /src/connect.php on line 11

実験2. interactive_timeoutを5秒に設定して、対話接続でクエリ実行後に5秒まち、再度クエリを実行するとgone awayになるか確認。

% mysql -u root

mysql> SHOW VARIABLES LIKE 'interactive_timeout';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| interactive_timeout |   5   |
+---------------------+-------+
1 row in set (0.00 sec)

5秒待って再度クエリ実行

見事gone away!

1 2	mysql> SHOW VARIABLES LIKE 'interactive_timeout'; ERROR 2013 (HY000): Lost connection to MySQL server during query

テストに使ったコードはこちら

https://github.com/kuniiskywalker/test-mysql-goneaway

まとめ

対話型の場合だけ秒数が別指定が多めにとられてるのは、一旦接続していろいろいじることが前提なので当たり前といえば当たり前。。。