プロトコル自体を比べるとTLS 1.2よりもTLS 1.3の方が簡潔で洗練されている。しかし、APIの視点から見ると、TLS 1.3は非同期性が高くなる。同期性的なTLS 1.2のプロトコル設計には、妥当性があると気づいたので記録を残す。 以下のような API を考える new -- コンフィグを与えるとコンテキストを返す handshake -- コンテキストを与えると、ハンドシェイクを試みてTLSコネクションを作成する sendData -- コンテキストとデータを与えると、データを送信する recvData -- コンテキストを与えると、データを受信する bye -- アラートを送って、TLSコネクションを終了する クライアントの疑似コードは、こんな感じ： ctx = new(コンフィグ); handshake(ctx); sendData(ctx, "Hello world!");

何度か講演でこの話をしたのだが、気が向いたのでエッセンスを書き下しておこうと思う。 テスト駆動という言葉が流行る前にプログラマとなった私は、当初どのようにテストを書いてよいのか分からなかった。そんなとき、(当時はオーム社で現在はラムダノートの)鹿野さんから「ビューティフルコード」を献本していただいた。分厚い本なので、興味ある章から読んでいった。その一つがアルベルト・サボイア氏が書いた7章「ビューティフル・テスト」だ。 ビューティフルコード (THEORY/IN/PRACTICE) 作者:Brian Kernighan,Jon Bentley,まつもとゆきひろオライリージャパンAmazon この章では、例として二分探索が取り上げられる。二分探索のアイディアが出されたのは1946年だが、バグのない実装ができたのは12年後だという。実際に実装してみると分かるが、ソートされた配列の中に目的の要素が

これまでTLS 1.3とセッションID方式は実装したことがあったが、この経験だけではTLS 1.2に対するTLS 1.3の利点に気づいていなかった。この二ヶ月の間に、セッションチケット方式を実装し、また引き継いだTLS 1.2のコードを大幅にリファクタリングした過程で、セッションの再開は、TLS 1.2よりもTLS 1.3の方が安全であると気づくことができた。備忘録として安全である理由を書いておく。 以下は、セッションID方式にもセッションチケット方式にも、共通している性質である。説明の都合で、セッションチケット方式を取り上げる。 TLS 1.2 TLS 1.2用のセッションチケット方式は、RFC 5077で定義されている。以下にRFC 5077からTLS 1.2のフルハンドシェイクの図を抜粋する。 Client Server ClientHello (empty SessionTicke

これはHaskell Advent Calendar 2023の19番目の記事です。 フォーマッター 以前、フォーマッターをいくつか試しましたが、どれもイマイチでした。しかし、fourmoluはいけてます。fourmoluは、Ormoluのフォークで、Ormoluが偉大なのでしょう。両方試しましたが、僕はformoluに決めました。 Hackageに上がっているので好きな方法でインストールしてください。 % cabal install fourmolu formoluにHaskellのプログラムを渡すと、整形したプログラムを出力してくれます。ファイルの内容を直接書き換えたいときは、-iオプションを渡します。エディタやIDEと連動できますが、お試しでプロジェクト全体を整形するには、以下のようにするといいでしょう。 % find . -name "*.hs" | xargs fourmolu

これは、Haskell Advent Calendar 2021 の8日目の記事です。 Haskellのコンパイラとして事実上一択となったGHCには、「軽量スレッド」が実装されています。軽量スレッドは、ネイティブスレッドよりも軽量なスレッドで、他の言語では「グリーンスレッド」とも呼ばれています。Haskellerが並行プログラミングをするときは、軽量スレッドを息を吸うかのように使います。 複数の軽量スレッドの入出力を束ねるのが、IOマネージャです。IOマネージャも単なる軽量スレッドであり、OSから入出力のイベントを受け取り、それぞれの軽量スレッドにイベントを通知します。 軽量スレッド(っぽい)機能を提供する他の言語では、GHCのIOマネージャを参考にしているようです。僕はIOマネージャの開発に深く関わっています。この記事ではIOマネージャの歴史をまとめるとともに、主にmacOSでの実装に関

都会のマンション暮らしだと、どうしても手狭になります。 多くの人がそう感じていると思いますが、リモートワークするには一部屋足りません。 (二部屋かも。)— 山本和彦 (@kazu_yamamoto) 2020年4月12日 ウチは6人家族なので、コロナ禍での在宅勤務は本当に手狭です。最終的には、あまり人の来ない寝室の敷布団の上に座って壁に寄りかかり、MacBook Proを膝に置いてプログラミングをしていました。 会社では標準的なオフィスチェアに座り、iMacの広い画面を見ながら、Happy Hacking Keyboard(HHKB)を2枚使って腕を肩幅に開いて快適に作業していました。布団に座っているのだと腰は痛くなるし、キーボード1枚では肩はこるし、仕様書を見ながらプログラミングするにはMacBook Proの画面は小さくて苦しいしで、「なんとかならないかなぁ」という状況でした。 最近、

QUICは、一年半実装を続けている僕でも全容を把握できているとは言い難いほど大きなプロトコルですが、ある側面をさっと理解するには、n月刊ラムダノート Vol.2, No.1(2020)に西田さんが書かれた「パケットの設計から見るQUIC」がオススメです。ただ、QUICの専門家から見ると、若干不正確な部分がありますので、訂正すべき箇所をまとめておきます。(遅くなって、すみません。) 記事を公開することは西田さんにお知らせしていますが、ここに書いてある内容はあくまで僕の意見です。 最初のページ 「QUIC(Quick UDP Internet Connections)は、インターネットのアーキテクチャ 上で利用可能な、高い信頼性を提供する仕組みとして設計されたトランスポートプロ トコルです。」 IETF で標準化している QUIC は、「Quick UDP Internet Connectio

Closing connections gracefully is an old and new problem in network programming. In the HTTP/1.1 days, this did not get attention since HTTP/1.1 is a synchronous protocol. However, as Niklas Hambüchen concretely and completely explained, HTTP/2 servers should close connections gracefully. This is because HTTP/2 is an asynchronous protocol. Unfortunately, most HTTP/2 server implementations do not c

適宜更新します。 実用的でない例題 「他の言語だと雑多になるけど、Haskellではこんなに優雅なコードになる」という例は大抵実用的ではありません。本書では、以下の例題がそれに当てはまります。 1.5.2節のクイックソート (qsort) 6.4節のフィボナッチ数列 (fib) 15.6節のエラトステネスのふるい (primes) 実用的なコードを知りたいなら「Haskellの神話」を読んでください。 紹介されてないデータ型 実用的なプログラムを書く際には String ではなく Text を使います。textパッケージの Data.Text モジュールで定義されています。Text はリストではありませんので、リストプログラミングでは扱えません。専用の API を使って操作します。 非負の整数を表すデータ型は Word です。Data.Wordモジュールで定義されています。8.3節の例は、

Monadとは、Applicativeであるデータ構造で、(>>=)演算子を提供し、それがMonad法則を満たすものである。 正確に表現するとこうなんですが、「はぁ？」っ感じですよね。「満たすべき法則」とか言われると、まったく理解できません。でも、オススメの形に持っていくための変換規則と捉えると分かりやすいのではないかというのが、この記事の主旨です。 関手 関手法則は以下の2つです： 単位元： id <$> x = x 合成　： f <$> (g <$> x) = (f . g) <$> x 左辺が冗長な形、右辺がオススメの形です。これはいいですよね？ Applicative Applicative法則は以下の4つです（<*>は左結合）。 単位元： pure id <*> x = x 準同型： pure g <*> pure x = pure (g x) 交換　： x <*> pure y

Haskellがとっつきにくい原因の一つに遅延評価がある。入門書では、無限リストと遅延評価がことさら強調される。しかし、Haskellを業務で使ってみると、遅延評価が煩わしくなってくる。遅延評価なしでもほとんどのことは実現できるし、メモリーの使用量は推測できないし、あまりいいことはない。 Haskellの評価戦略が、他の言語と同じように正格評価だったらよかったのに。 今まで、このようなセリフを何度聞いたか分からない。 そもそも遅延評価が役立つことはあるのだろうか？ ある。お世辞抜きに、少なくとも以下の3つでは本当に役立つ。 リスト(あるいは類似のデータ構造)処理 純粋性に対する暗黙のテスト 効率的なCAS 1.はよいだろう。2.は純粋さを守るために必要だが、コンパイラを開発する人にとって重要なのであり、ユーザには関係ない。3.は、並行プログラミングの奥義である。atomicModifyIO

QUICや ああQUICや QUICや 詠み人知らず。QUICの実装の難しさに絶望した心境が詠まれたと伝う。 序章 2017年の7月ごろ、QUICの実装を始めました。Haskellの有名なシリアライザ/デシリアライザである binary や cereal では、バッファ操作ができないので、パケットヘッダを複雑に処理する必要がある QUIC には不向きです。そこで、Haskell HTTP/2 ライブラリから、バッファ操作の部分を切り出して、network-byte-orderというライブラリを作るところから始めました。 その矢先、上司とのミーティングでのこと： 上司「来年度開発室を立ち上げる前に、下期の半年間、現場に行って開発の現場を見てこい」 kazu「いいですけど、他のQUIC実装に遅れをとることになりますが、いいんですか？」 上司「いい。」 という訳で、QUICの開発は中断されました

はてなダイアリーからはてなブログに移行しました。今後も、細々とブログを書いていきます。 2018年8月、TLS 1.3がRFC8446になりました！(TLSのRFCは、伝統的にXX46という番号になります。) RFC8446の貢献者リストに僕の名前が載っていることを聞きつけたIIJ広報から依頼されたので、TLS 1.3の標準化と実装というブログ記事を書きました。執筆中にはリリースされていませんでしたが、現在ではTLS 1.3 対応済みの Firefox 63 と Chrome 70 が、めでたくリリースされています。 RFC8446の策定後、Haskell の tls ライブラリも、他の実装と相互接続性を確認しました。また、私の実装がtls ライブラリの本家にマージされました。Haskell tls ライブラリをリリースするには、 鍵のアップデート ダウングレード対策 クライアント認証 を

自分で定義するデータの中には、足し算したくなるようなデータがある。たとえば、送信と受信のカウンターを定義したとしよう。 data Metrics = Metrics { rx :: Int , ts :: Int } deriving (Eq, Show) これは以下のように足し算できると嬉しいだろう。 > Metrics 1 2 + Metrics 3 4 Metrics {rx = 4, ts = 6} しかしこれは Num のインスタンスにすべきではない。このデータ型に掛け算は定義できないからだ。かといって、addMetrics みたいな関数を定義するのはかっこ悪い。 > Metrics 1 2 `addMetrics` Metrics 3 4 Metrics {rx = 4, ts = 6} このように演算子が一個だけ欲しいと思ったら、それは多分 Monoid だ。 import

これは「Haskell (その2) Advent Calendar 2017」の1日目の記事です。遅くなってすいません。 読者として末尾再帰ぐらいは理解しているHaskellerを想定しています。 トップレベルとローカル関数 再帰を用いて関数を書いているとき、トップレベルで再帰するか、ローカル関数で再帰するか、ときどき迷う。この記事では、僕なりの判断基準を示したい。 Data.Listで定義されている再帰が必要な関数は、ほとんどがトップレベルで再帰している。代表例のmapの例を見てみよう。 map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x : map f xs mapをローカル関数を使う実装にしてみよう。この記事では、ローカル関数名としてgoを用いる。(loopを使う流儀もある。) map' :: (a -> b)

P256とかX25519とかPSSとか聞いても、よくわからない人のための用語解説。 長い間TLSの世界では、鍵交換にも認証にもRSAが使われてきた。必要となる安全性が大きくなると、RSAの公開鍵は急激に大きくなり、したがって鍵交換や認証のコストが大きくなるという問題がある。 楕円曲線暗号(ECC: Elliptic Curve Cryptography)は、RSAやDiffie Hellmanに比べると、小さな公開鍵で同程度の安全性を実現するという特長を持つ。特許問題が不透明なせいで楕円曲線暗号は長年敬遠されてきたが、この数年で(少なくとも鍵交換に対しては)一気に普及してきた感じだ。 おおざっぱに言うと、楕円曲線暗号で実現できるのは、DH(Diffie Hellman)とDSA(Digital Signature Algorithm)であり、RSAは実現できない。 鍵交換のDHに関しては、

TLS 1.3 ID21までの仕様は、 ServerHelloの書式がTLS 1.2と異なる ChangeCipherSpecがない という特徴があった。 ServerHelloが異なるということは、TLS 1.3に非対応であったWiresharkで表示できなくて辛いとか、パーサーの中で分岐しなければならないので関数プログラミングの考えでコードが書きにくいなどの問題があった。 その後、はやり世の中にはTLS 1.3を遮断するミドルボックスが少数ながらも存在することが分かり、これらのミドルボックスを騙すための方法が考案された。現在 PR1091 で議論中だが、開発者の間ではこのPRをマージした版がID22とすることで合意が取れている。その方法とはこうだ： ServerHelloの書式をTLS 1.2と同じにする バージョンはTLS 1.2を指定する 圧縮方式が復活。常に0 セッションIDが復

何度読んでもよく分からないDNS関連のRFCを自分なりに読みやすいようにまとめる私的メモ。 ちなみに、僕は Haskell DNS ライブラリの作者で今も精力的に開発中。 RFC 1035 RFC 1035で定められている構造をトップダウン的に列挙する： メッセージ全体 +---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | RRs answering the question +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ |

経緯 Chrome は version 56 から TLS 1.3 ID 18 をサポート(0-RTT 以外)。 Chrome 56 の前にBlueCoatがある状態で Google サービスにアクセスしようとすると、アクセスできないことが判明。 ChromeはTLS.13をdisabledに戻した。 原因 TLS 1.3は、TLS 1.2と区別のつかないClient Helloを送る。拡張でバージョンが1.3だと教える。 TLSの実装は、知らない拡張は単に無視してエラーにしてはいけないという鉄則により、TLSのバージョンアップは順調にいくはずだと信じられていた。 BlueCoatは、サーバからのCertificateの中身を見て、中継するか否かを決めるらしい。 TLS 1.3を知らないBlueCoatには、Client HelloがTLS 1.2に見える。 しかし、サーバから戻って来たハ

これは、http2 Advent Calendar 2016の25日目の記事です。 この記事では、HaskellでTLS 1.3を開発した際に難しかった点をまとめます。自分のための覚書です。TLS 1.3のみをフルスクラッチで書くと、そこまで難しくないのかもしれませんが、TLS 1.2以前と共存させるのは大変です。 足らない部品 TLS 1.2のコードが存在しても、TLS 1.3では TLS 1.2で利用されてない部品が必要です： RSA PSS PSS は PKCS#1 は異なるパディング方式の署名。RSAの公開鍵/秘密鍵自体は流用できる HKDF X25519 と X448 これらは、Haskell の cryptonite にすべて揃っていたので、少し(かなり？)手を入れるだけで利用できるようになりました。 拡張の再利用 TLS 1.3では、TLS 1.2 の2つの拡張を再利用してい