「QUIC-based UDP Transport for SSH」という提案が提出されています。
トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。
- ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない
- IPアドレスが変わっても接続を維持できる(コネクションマイグレーション)
- 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要)
個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。
それでは、この仕様についてざっと見ていくことにしましょう。
ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。
QUIC-based UDP Transport for SSH の概要
QUICは内部的にTLSハンドシェイクを行ってコネクションの確立を行うため、SSHの鍵交換の仕組みをそのまま入れ込むことが出来ません。ですので、「QUIC-based UDP Transport for SSH」では、鍵交換だけSSH流のやりかたをし、その鍵を用いてQUICのハンドシェイクが完了した状態からQUICを始めるという少々トリッキーな仕組みになっています。
（なので、SSH over QUICというより、仕様のタイトル通りQUIC for SSHという感じですね）
この仕様では、コネクションを確立するために必要な情報を交換する「SSH_QUIC_INIT」「SSH_QUIC_REPLY 」というメッセージと、通信のキャンセルをする「SSH_QUIC_CANCEL」というメッセージを新しく定義しています。
「SSH_QUIC_INIT」および「SSH_QUIC_REPLY 」は、SSH関連の情報とQUIC関連の情報が含まれます。
SSH関連の情報として、署名アルゴリズム、信用する鍵のフィンガープリント、ECDH用のパラメータ(SSH_MSG_KEX_ECDH_INIT)などが含まれます。
QUIC関連の情報としては、QUICのハンドシェイクが完了した状態とするために、QUICバージョンや暗号スイートが含まれます。
QUICコネクションが確立されると、ストリームID 0上でデータがやりとりされます。
SSH_QUIC_INIT
SSH_QUIC_INITが持つ情報について詳しく見ていきます
- client-connection-id: QUICのコネクションIDとして使用される
- client-quic-versions: サポートするQUICバージョンの列挙
- client-sig-algs: クライアントの署名アルゴリズム
- trusted-fingerprint: クライアントが信頼する鍵のフィンガープリント
- client-kex-alg-name: クライアントが対応する鍵交換アルゴリズム
- client-kex-alg-data: 鍵交換のパラメータ
- quic-tls-cipher-suite: QUICの暗号スイート対応リスト
- ext-pair: 拡張領域
- padding: アンプ攻撃対策のパディング
SSH_QUIC_REPLY
SSH_QUIC_REPLYが持つ情報について詳しく見ていきます
- server-connection-id: QUICのコネクションIDとして使用される
- server-quic-versions: 選択したQUICバージョン
- server-sig-algs: サーバの署名アルゴリズム
- server-kex-algs: 選択した鍵交換アルゴリズム
- quic-tls-cipher-suite: 選択したQUICの暗号スイート
- ext-pair: 拡張領域
- server-kex-alg-data: 鍵交換のパラメータ
各種、使用するアルゴリズムは既存のSSHで定義されたもの、暗号スイートはTLSで定義されたものをそのまま使う。
なお、受け取ったSSH_QUIC_INITでは処理ができない場合は、エラーを返すことになる。具体的にはserver-connection-id, server-kex-alg-dataに空を設定し、拡張領域にerr-descというフィールドを設定いしエラー理由を通知する。
