ISP Column - October 2022
There is a common view out there that the QUIC transport protocol (RFC 9000) is just another refinement to the original TCP transport protocol [1] [2]. I find it hard to agree with this sentiment, and for me QUIC represents a significant shift in the set of transport capabilities available to applications in terms of communication privacy, session control integrity and flexibility. QUIC embodies a
QUIC用APIを実装したOpenSSL forkの登場 (quictls/openssl) - ASnoKaze blog
AkamaiとMicrosoftらによって、QUIC用APIを実装したOpenSSLのforkが公開されています。 github.com これらは、公式がQUIC用APIをサポートするまでの一次的なソリューションとのことですが、流れを簡単に整理しておく。 目次 背景: QUICとTLS OpenSSL 3.0とQUICサポートの見解 forkされたOpenSSL その他の動き 背景: QUICとTLS QUICと呼ばれる新しいトランスポートプロトコルは、IETFで標準化が進められていましたが、RFCがもうすぐ出るところまできています。 このQUICでは通信を暗号化しますが、コネクションを確立する際に、TLS1.3相当のメッセージをやりとりしサーバ認証および鍵の共有を行います。 （詳細については 「QUIC-TLS」の仕様を御覧ください） そこで、QUICを実装するに当たり暗号ライブラリとし
2019年 asnokaze 振り返り - ASnoKaze blog
今年も大晦日になりました。例年通り振り返ります。 今年も全52記事と、たくさん書いた。一方でイベント類やアウトプットは少なかった気がする。来年頑張りたい。 また今年特に印象深いのが、「ブログ、読んでますよー」とお声がけいただく機会が何度かあった。本当に励みになるので感謝しかない。 イベント類 登壇や関わったイベントは多くありませんでした。 次世代 Web カンファレンス - connpass (HTTP/3) HTTP3Study (new) - connpass HTTP/3やQUIC、WebTransportなどでお話できることもあるとおもいますので、話者をお探しでしたらお声がけいただければお手伝いできればなーと思う所存です。（自分より適任者は多そうですが...） 一方で、少人数のクローズドなディスカッションを定期的に開催したりと、ちょっとは活動した。 アウトプット t2q2t (記事
QUICむけにAES-GCM実装を最適化した話 (2/2)
前半で述べたように、OpenSSLのAEAD暗号器は、長いAEADブロックの処理を前提に作られています。平文の暗号化処理においては理論上の上限にあたる速度を叩き出す一方、事前処理と事後処理、および呼出オーバーヘッドについては、あまり最適化が図られているとは言えません。これは、AEAD暗号の主な使用用途が、これまでTLSという長いAEADブロックを使う（ことが一般的な）プロトコルであったことを反映していると言えるでしょう。 一方、QUICにおいては、UDPパケット毎に独立した、短いAEADブロックを暗号化する必要があり、したがって、次のような速度向上の機会があることが分かります。 AEAD処理をひとつの関数にまとめ、事前処理と事後処理を、パイプライン化されスティッチングされた暗号処理と並行に走らせることができれば、AEADブロックが短くても、理論値に近いスループットを発揮するような、AES-
QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記
OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って
Builderscon 2018 Tokyo 次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス by @kazuho - inductor's blog
この記事について Builderscon 2018 Tokyoに参加してきた(記事書いてる時点ではまだしてる)のでそのアウトプットです。 とにかく速度最優先で書いたので間違ってるところがあればご指摘お待ちしております！ 資料 ↓kazuhoさんのスライド なお、QUICやHTTP、TLSに関して全くわからないという方は下記スライドをざっくり見てみるといいかもしれません（宣伝） 主な内容 パフォーマンスの話は時間の都合上用意できなかったということで、主にTLS1.3やQUICの仕様の概要や、仕様策定の裏側に関する話だった。 1. 暗号化技術が今なぜ変わろうとしているのか エドワード・スノーデンが暴露した話を皮切りにして、クライアント(または、ユーザー)とサーバーの間であるネットワーク経路上において、大規模な監視が行われている実態についていろいろな事実、憶測が飛び交うこととなった。 e.g.)
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通
日本最大級のHTTP/2移行、TLS 1.3、そしてQUICについてヤフーに聞いてみた！
日本最大級のHTTP/2移行、TLS 1.3、そしてQUICについてヤフーに聞いてみた！ 白石 俊平（HTML5 Experts.jp編集長） こんにちは、編集長の白石です。 この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、様々な技術的なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。 今回お話を伺ったのは、ヤフー株式会社にお勤めの大津繁樹さんと新部長則さんです。 ▲左から、ヤフー株式会社 大津繁樹さん、新部長則さん お二人のセッションは「大規模運用で見えるWebプロトコルの理想と現実、そして今後」（ルームB 13:20-14:00）です。 （現在HTML5 Conferenceは定員オーバーの状態で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
QUIC標準化動向 〜2017/7