HTTP/Tokyo #1 に参加して - amareloのブログ（仮）

昨日、HTTP/Tokyo という初めて開催された勉強会に参加して来ました。そこで得た知見を書こうと思います。

HTTP/Tokyo について

以下のイベントページにも書いてありますが、HTTPというプロトコルについて理解し、HTTPを正しく使えるようになることを目指す勉強会です。HTTP(s)に特化した勉強会って無かったので、面白そうと思い参加しました。

http-tokyo.connpass.com

会場提供株式会社トレタ様について

corp.toreta.in

外食産業の生産性を向上させるための事業を展開している。
飲食店向け予約／顧客管理サービスを展開
超直前予約アプリToreta nowの開発元
立ち呑みトレタ 1/29 19:30から

会場はおしゃれできれいな雰囲気でした。全従業員の自宅勤務を推奨していたことからも、フレキシブルに働けそうな感じがしました。立ち呑みトレタ、興味あります！

Response Status Codes 3xx　あらや @arayaryoma さん

資料

https://slides.araya.dev/http-tokyo-1/#slide=1

概要

ステータスコード 3xx系についての話でした。302はよく聞きますが、それ以外はあまり聞かないので、3xx系のステータスコードの多さに驚きました！！3xx系のコードについてはもっと勉強する必要あるのかと思いますが、登壇と資料で学んだこととしては以下の通りです。

ステータスコード 3xx は、リクエストを果たすためには UA によるさらなるアクションが必要ということを指示する。
301と302はHTTP/1.0で定義されたもの
初期の UA では、301, 302 だったとき、リクエストターゲットへの適用に差があった。
- HTTP1.1で実際の差分に影響されない307が追加された
300 Multiple Choices
- リダイレクト先の候補がいくつかある、クライアント側は優先したいものを選ぶという仕組み。
301 Moved Permanently
- 対象のリソースに新たなURIがあてられていて、このリソースへの今後の参照は同封されたURIのいずれかを利用すべきことを指示する。
- UA は後続のリクエストのメソッドを POST から GET へ変更してもよい。
302 Found
- 対象のリソースが一時的に異なるURIのもとに配置されていることを指示する。
- UA は後続のリクエストのメソッドを POST から GET へ変更してもよい。
303 See Other
- UAに対し異なるリソースへのダイレクトすることを指示する。
- UAは受け取ったロケーションヘッダフィールドのURIをターゲットとするリクエストを発行できる。
304 Not Modified
- 条件付きGET/HEADリクエストが受け取られ、条件がfalseと評価されていなければ、200で応答するかのように返す挙動をとる。
307 Temporary Redirect
- 対象リソースが別の URI の下に一時的に存在し、UA がその URI への自動リダイレクトを実行する場合、リクエストメソッドを変更してはならない
308 Permanent Redirect
- 対象のリソースに新しい恒久的な URI が充てられていて、このリソースへの今後の参照は同封された URI のいずれかを利用するべきことを指示する。
- リクエストメソッドを POST から GET に変更できない。

Status425 @flano_yuki さん

資料

www.slideshare.net

概要

ステータスコード425とTLS１.3でも使われるEarly Dataについての説明でした。コード425なんて初めて知りました（汗）Early Dataも初めて知りましたので、興味深く聞くことができました。TLS1.3についても話が聞けるとは思ってもいなかったため、得した気分でした！

TLS1.3について
- TLSハンドシェイクにはプルハンドシェイクと0-RTTハンドシェイクの２種類ある。
  - フルハンドシェイク
  - 0-RTTハンドシェイクは、一度ハンドシェイクした相手と再度ハンドシェイクする際にアプリケーションデータ（Http Request)を送信する。それをEarly Dataという。
- Early Data はリプレイ攻撃に悪用される危険性がある。リクエストの中身は分からないが複製できる。
- サーバはHTTPリクエストを見て、冪等でないリクエストを拒否できる。
TLS1.3を踏まえた上で、425 Too Early とは？
- RFC8470 Using Early Data in HTTP で定義されるステータスコード
- 安全にEarly Dataを送信できるようにするための仕様
ProxyやCDNを経由させている場合の問題点
- Proxyを経由する環境の場合、ProxyはEarlyData のリクエストが冪等か判断できないため、そのままOriginサーバに経由してしまう。
- OriginサーバもProxyから送られてきたリクエストが、もともとEarlyDataで送られてきたものかわからない。
問題解決のために
- ProxyがEarlyDataを経由する際に「Early-Data リクエストヘッダ」を追加する。
- Originサーバはリクエストが冪等でない場合、425 Too Early を返してリクエストを拒否できるようにする。

おまけ 418 vs 425

Too Early のステータスコードを決める際に418にするか425にするか議論したが、418はIANAの管理上使われていなかった。
しかし、エイプリルフールに発行されたジョークRFC（RFC2324 Hyper Text Coffee Pot Control Protocol）で定義された、418 I'm a tea pot があり、あちこちに実装されていた。そのため425になった。
RFC7230 - 7237 から仕様を再改定することとなり、418はUnusedとなった。

@flano_yuki さんのブログ

asnokaze.hatenablog.com

Cookieについて Jxck さん

概要

Cookieについての説明をホワイトボードに書きながら登壇されていました。あまり見たことない登壇スタイルだったので驚きました。聞き漏らさないよう真剣に聞きました。途中から理解が追い付かなったところがあり、Cookieについて再勉強しなければと思いました。

資料はありませんでしたが、RFC6265とHTTP State Tokenをもとにした話でした。

tools.ietf.org

※自分の理解が追い付かなかったため、わかった（と思う）ところのみ書きます。誤認識の恐れもあります。申し訳ありません。

Cookieはリクエスト送信者を識別するために作られた。そのため、格納情報のほとんどはクレデンシャル情報である。
サーバは最初のレスポンスでSet-Cookieを送り、クライアントにCookieを保管させる。次回以降はそのCookieを送信させることでアクセス元を判断している。
しかし、CookieがSame Originの原則に乗っ取っていないため、悪意ある人が成りすまして正規のCookieを含んだリクエストを送っても、サーバはリクエストを受け付けてしまう。その性質を悪用したのがCSRFである。
CSRF トークンでリクエストの正否を判断する必要がある。
Cookieの方が歴史が古く、SameOriginの概念の方が新た強い。だから、ドメインの扱いが歪になっている。
一般的にCookieを悪用されないための対策は以下の通り。
- secure属性をつける。
- HttpOnly属性をつける。
- Path属性をつける。
- ドメイン属性は基本指定してはいけない。サブドメインにもCookieを送ってしまうので、意図せずCookieが漏洩する恐れがある。
Set-Cookieを送信する際に「SameSite」というプロパティを付けることができるようになった。
- クロスサイトオリジンなサイトの場合は、SameSIteを明示的に"none"にする必要がある。
- SameSiteをlaxに設定すると、サイトの挙動を壊す恐れがある。
サードパーティCookieによるトラッキングを防ぐため、ブラウザ側で対策が施されている。
- Safari ではITP（Intelligent Tracking Prevention）でトラッキングしそうなCookieのみをブロックしている。
Cookieをなくすことはできないが、ChromeはCookieに頼らない情報収集（APIの利用等）を考えている。
Prefix __secureを付けることでHTTPSの時のみ送信を許可。Set-Cookieの上書きを防ぐことができる。
画面を遷移してきたときにどこから来たのかを識別するために、できれば、ReadとWriteのCookieを判別できるようにするのがよい。そうすれば、SameSiteの属性を使い分けられる。
Cookieではなく、「クライアント側でトークンを生成してサーバに送る」http state tokenの提案がされている。

最後に

HTTP(s)は、Webサービスがある以上、なくなることも廃れることもないプロトコルであり、アップデートされていくものだと再認識しました。奥が深いです！途中ついていけなかったくらいでした（汗）勉強し直します！もちろん、httpに限らず、Webサーバ、Webプログラミングなど、Web周辺のことはもっと知りたいと思います！

次回が開催されたら、また参加したいと思えた勉強会でした。