走り出した TLS 1.3（２）：0-RTTでいきなり暗号化メッセージ - wolfSSL
連載第二回、TLS1.3の性能面での改善項目、0-RTT (Early Data) を紹介しようと思う。(0-RTT: Zero Round Trip Time) これまでのTLS/SSLの性能上の大きな悩みは、冒頭のハンドシェイクによる遅延だ。これまではハンドシェイクは、安全な暗号通信をするためのやむをえないオーバヘッドと思われていた。それが、使用条件はあるものの、通信の冒頭で暗号化されたメッセージを送れる方法が正式に認められたのだから、かなり画期的なことだと思う。特に、少しでも早くデータをサーバに届けたいIoTデバイスにとっては朗報のはずだ。 しかし実は、これを1.3の冒頭に紹介するかどうかについては少々悩ましい。というのは、Early Dataによる暗号化メッセージはセキュリティ的には安全性がやや落ちるからだ。もう少し厳密な言い方をするなら、Early Data では完全前方秘匿性(
pkiday_tls13.key
ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data ClientHello ServerHello EncryptedExtension ServerConfiguration Certificate CertificateVerify Finished ApplicationData Finished Application Data Application Data ClientHello Finished ApplicationData end_of_early_data ServerHello EncryptedExtensi
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
