タグ

TLSに関するtakashabeのブックマーク (7)

  • QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog

    [追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP

    QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog
  • TLS の SNI 暗号化に関する Internet Draft を共同提出しました

    Eric Rescorla (RTFM), Nick Sullivan (Cloudflare), Christopher Wood (Apple) の各氏とともに、SNI を暗号化する TLS 拡張を提案する Internet Draft を提出しました。 Encrypted Server Name Indication for TLS 1.3 アナウンスのメールにあるとおり、すでに NSS / Firefox と picotls / H2O で実装作業が開始されており、今月開催される IETF 102 で相互運用試験を行うとともに、標準化にむけた議論を深める予定です。 スノーデン事件以降、広範囲におよぶトラフィックモニタリングによるプライバシー侵害の懸念が明らかになるとともに、できるだけ多くのインターネット上の通信プロトコルを暗号化することが求められるようになってきました (参考: R

  • QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉

    先週スウェーデンのKistaで開催された第5回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化(つまり正当なパケットと攻撃との区別がつかない)、黄は未認証の暗号化(通

    QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
  • QUICの現状確認をしたい 2018/5 (Stream 0の再設計案などなど) - ASnoKaze blog

    IETFでは引き続き、QUICの標準化が進められています。 次回 asnokaze.hatenablog.com 前回分 asnokaze.hatenablog.com 現状確認したい ちょうど先週に、コアドキュメントのdraft-12も出ています QUIC: A UDP-Based Multiplexed and Secure Transport Using Transport Layer Security (TLS) to Secure QUIC QUIC Loss Detection and Congestion Control Hypertext Transfer Protocol (HTTP) over QUIC 例えば大きなところで、draft-11で「Coalescing Packets」が入り複数のQUICパケットを一つのUDPデータグラムに格納できるようになった。draf

    QUICの現状確認をしたい 2018/5 (Stream 0の再設計案などなど) - ASnoKaze blog
  • TLS1.3だとハンドシェイクがどれくらい早くなるか測定した | GREE Engineers' Blog

    こんにちはインフラの後藤です。 今回はTLS1.3を実環境で試してみました。 TLS1.3はTLSのメジャーバージョンアップとも言われるように、様々な改善が含まれています。 例えば、以前「TLS1.3のハンドシェイクがもう来てる」で書いたように、TLS1.3ではハンドシェイク時のパケットの往復回数が減っており、より早くコネクションを確立できます。 すでに、ブラウザや暗号ライブラリはTLS1.3に対応してきておりますので、実環境で具体的にどれくらいコネクションの確立が早くなるのか確認してみました。 TLS1.3 バージョンネゴシエーションとネゴシエーション 測定の前に今回利用したTLS1.3 draftバージョンについて補足します。 TLS1.3は draft-28 版が最新のバージョンです。こちらが文章上の修正を経て将来的にRFCとなります。 TLS1.3はファイアウォール等の中間装置の不

    TLS1.3だとハンドシェイクがどれくらい早くなるか測定した | GREE Engineers' Blog
  • IETF報告会で「TLS 1.3とその周辺の標準化動向」について発表してきた

    先週金曜日に開催されたIETF報告会にて、「TLS 1.3とその周辺の標準化動向」について発表する機会をいただきました。その際のスライドが下のものになります。 TLS 1.3や関連する提案の技術的特徴とともに、スノーデン事件以来のテーマである通信内容のプライバシー保護とオシフィケーション(硬化)対策がどのように進んでいるか、ご理解いただける一助になれば幸いです。 なお、スライドは会社のテンプレートを使用していますが、会社としての見解を表明するものではありません。 Most schools also offer drama studies, music and physical education but these are usually not examined or marked. Home economics is sometimes taught to female studen

  • Go言語と暗号技術(AESからTLS)

    最近マスタリングTCP/IP SSL/TLS編や暗号技術入門を読んでいた.理解を深めるためにGo言語で標準のcryptoパッケージを触り/実装を読みながら読んだ. cryptoパッケージは他の標準パッケージと同様に素晴らしい.Go言語にはどのような暗号化手法が実装されているのか実例を含めてざっとまとめる.なお文に書ききれなかったものを含め全ての実装例はtcnksm/go-cryptoにある. 共通鍵暗号 まずは共通鍵暗号をみる.共通鍵暗号は暗号化と復号化に同じ鍵を用いる暗号化方式である.共通鍵暗号はブロック暗号とストリーム暗号の2種類に分けることができる.ブロック暗号は特定の長さ単位で暗号化を行う方式であり,ストリーム暗号はデータの流れを順次処理していく方式である. Go言語にはブロック暗号としてDES(Data Encryption Standard),DESを繰り返すtriple-D

  • 1