TLS

複数TLSコネクションの署名処理をまとめて行うBatch Signing

複数のTLSコネクションの署名処理ををまとめて1回で行ってしまう、「Batch Signing for TLS」という提案仕様がGoogleのDavid Benjaminさんより提案されています。

提案仕様「HTTP Transport Authentication」について

HTTPレイヤにおいて、使用しているトランスポートレイヤの認証を行う「[HTTP Transport Authentication」という仕様がGoogleのDavid Schinazi氏から提案されています。

QUICの暗号化と鍵の導出について

QUIC, HTTP/3 関連記事 QUICのAckとロスリカバリについて - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと…

HTTP/2においてTLS1.3のpost-handshake authenticationの禁止

GoogleのDavid Benjamin氏より「Using TLS 1.3 with HTTP/2」という提案仕様が出されています。この仕様自体は、単純にHTTP/2においてTLS1.3のpost-handshake authenticationを禁止するものです。HTTP/2でTLS1.2を使用している場合はrenegotiatoinが禁止され…

中間証明書を要求しないTLSフラグ拡張

TLSハンドシェイクでは、サーバはエンドエンティティ証明書と任意でルート証明書までたどるための中間証明書を送信します。不要であればこの中間証明書を送信しないようにする「Suppressing Intermediate Certificates in TLS」という提案がMartin Thomson氏…

QUICにおいてNAT検出を行う拡張フレームの提案仕様

QUICを使用している際に、その通信がNATによってアドレス変換を行われているかを検出する「QUIC Address Extension」という提案仕様がAppleの人らによって出されています。具体的には、送信元IPアドレスがなんであるかを通信相手に確認します。そうすること…

Secondary Certificate Authentication in HTTP/2 という仕様について

目次 Secondary Certificate Authentication in HTTP/2 用途 サーバ側から証明書を要求するパターン クライアント側から証明書を要求するパターン 通信フロー サーバ側から証明書を要求する場合 クライアント側から証明書を要求する場合 Secondary Certifica…

Fake SNIという提案仕様について

SNIを用いた通信のブロッキング及び、「Encrypted SNI拡張」のブロッキングについてはIETFのTLS WGでも話題となりました((TLS) SK filtering on SNI, blocking ESNI)。Encrypted SNIはSNIを暗号化する一方で、ClientHelloにencrypted_server_name拡張をつ…

Delegated Credentials for TLS について

BoringSSLが「Delegated Credentials for TLS 」に対応したので、簡単に仕様を眺める。 「Delegated Credentials for TLS 」の仕様は、もともとはTLS1.3の仕様の著者でもあるEric Rescorlaによって書かれていたようだが、すでに WG DraftとなっておりMozilla…

NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す

追記20180922 OpenSSLも対応しました 「support for TLSv1.3 early data with OpenSSL.」 http://hg.nginx.org/nginx/rev/548a63b354a2 昨日、NginxがTLS1.3の0-RTTハンドシェイクをサポートしたので試した。無事動作することが確認できた。該当コミットはこ…

TLS1.0, TLS1.1 の廃止する提案仕様

TLS1.3にRFC8446が採番され、RFCとして出るのを待つばかりになっている。一方で、「Deprecating TLSv1.0 and TLSv1.1」というTLS1.0とTLS1.1の廃止についての提案仕様がIETFで出ている。 TLS1.0, TLS1.1 廃止事情 カード情報セキュリティの国際統一基準 PCI …

Chromeが6週間毎にTLSバージョン番号を変更していくかもしれない

[修正] ossificationを骨化と訳してましたが、硬直化に変更しました TLS1.3の標準化が終わり、もうRFCとして出されるのを待つばかりになっている。そんなTLSワーキンググループのメーリングリストに、ChromiumやBoringSSLの開発に携わるDavid Benjamin氏よ…

TLSにおけるTicketRequest拡張の提案仕様

Appleの人らによって「TLS Ticket Requests」という、TLSでのセッション再開に利用するチケットに関する拡張仕様が提案されています。TLSはあまり詳しくないのですが簡単に読む TLS session ticket まず、TLS session ticketとセッション再開について確認する…

Application-Layer TLS の標準化動向

IETFでApplication-Layer TLSの議論が行われ始めているので、雑に書き留めておく Application Transport LAyer Security (Atlas) 前回、アプリケーションレイヤでTLSを喋る「HTTP over TLS」について、記事を書いた。 asnokaze.hatenablog.com その後、IETF…

RFC 8307 WebSocketにおけるWell-Known URIの標準化

「RFC 8307 Well-Known URIs for the WebSocket Protocol」でWebSocketにおいても Well-Known URIが使用できるようになりました。この界隈では珍しく、個人ドラフトの-00から一気にRFCになっています https://datatracker.ietf.org/doc/rfc8307/ Well-Known …

DTLSにコネクションIDを導入する提案仕様

追記 20180702 「The DTLS Protocol Version 1.3」で、DTLS1.3の仕様でconnection_id拡張について言及されています DTLSにコネクションIDを導入する「The Datagram Transport Layer Security (DTLS) Connection Identifier」という提案が出ています。DTLS1.3…

将来のQUICをデプロイしやすくするための取り組みと議論 (QUIC GREASE)

MozillaのM. Thomson氏より「More Apparent Randomization for QUIC」というinternet draftが出ています。 ## QUICのここまで QUICはIETFで標準化が進められています。当初は2018年3月が一つのマイルストーンになっていましたが、スコープとマイルストーンの…

TLS over HTTPの提案仕様

追記 関連してATLSの記事を書きましApplication-Layer TLS の標準化動向 http://asnokaze.hatenablog.com/entry/2018/02/01/084251 TLS over HTTPである。HTTP over TLSではない。「Application-Layer TLS」という提案仕様がCiscoの方より提出されている。(…

TLS1.3とDC内での復号に関する熱い議論

各ブラウザや、OpenSSL・BoringSSLといった暗号ライブラリ、ミドルウェアのTLS1.3対応が進んでおり、実際に通信できるところまで来ている。標準化としても大詰めを迎えている。前回のIETFより話題に上がっている、TLS1.3に関するDC内での復号を目的とした議…

TLS record_size_limit 拡張の提案

IoTデバイスなどリソースが制限されている端末でTLS通信を行うのには課題がある。特に送られてきたレコードを復号するのにはそれを計算する十分なメモリが必要になる。リソースが制限されている端末でも問題なく復号処理が出来るように、相手に受信したいレ…

TLS1.3の0-RTT通信と、HTTP 425 ステータスコードの提案仕様(RFC8470)

20190502 追記 動いた NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す - ASnoKaze blog 20180922 追記 RFC8470として標準化されました20170906 追記 無事Too Earlyのステータスコードが 425になりそうです。 https://github.com/httpwg/http-ex…

TLSにおける証明書チェーンを圧縮する拡張仕様

GoogleとCloudflareの方による「Transport Layer Security (TLS) Certificate Compression」という、証明書チェーンの圧縮を行う拡張仕様の提案が出ています。 TLSハンドシェイクの大部分は証明書が占めているらしく、サーバ側から送る証明書チェーンをgzip…

WiresharkのTLS1.3対応 動いた

TLS

TLS1.3動いたシリーズの第3回目(?) WiresharkはTLSの実装一覧ページ(URL)では、以前よりTLS1.3対応をうたっていたがあまり出来は芳しくなかった。しかし、先日 TLS1.3絡みのコミットが幾つか入ったので、実際に改善されていることを確認した コミットログ(UR…

NginxでTLS1.3 動いた(OpenSSL)

昨日書いた「OpenSSLのTLS1.3対応」の続き 特に何かしたわけではないが、OpenSSLのTLS1.3対応が進んでいたのでインストールしてNginxで動かす。 ビルド openssl 今回はインストールしてしまう。 $ git clone https://github.com/openssl/openssl.git $ cd ./…

OpenSSLのTLS1.3対応 喋れる

追記 20170120 NginxでTLS1.3 動いた(OpenSSL) 後日Nginxでも動いたので、上記記事に記載 セキュリティとパフォーマンスが向上したTLS1.3の登場が待ち望まれております。 標準化としては、現在IETFのTLSワーキンググループではWGラストコールという段階に入…

CT対応を示すExpect-CTヘッダとは

正式に、Expect-CTのDraftが出ました (10/31 追記)https://tools.ietf.org/html/draft-stark-expect-ct-00expect-ctがreport-toヘッダを使わない理由は https://groups.google.com/a/chromium.org/forum/#!msg/Blink-dev/7_EgKuWAXjE/TS15lnpgBQAJ Certifica…

Firefox Nightly がTLS1.3対応したので試す

TLS

Chrome canaryも、chrome://flagsよりTLS1.3を有効にできるようになりました(2016/08/08) FirefoxがNgithlyでTLS1.3に対応したので試す TLS1.3 TLS1.3は、TLS1.2より様々な改善が行なわれています。 個人的には、大きな所で ハンドシェイクのRTT削減 セキュ…

TLS1.3のgo実装 Mintを触ってみる

TLS

関連記事 20160607 FirefoxのTLS1.3対応が来たので通信させてみました 「Firefox Nightly がTLS1.3対応したので試す」 TLS1.3 TLS1.3は、TLS1.2より様々な改善が行なわれています。 個人的には、大きな所で ハンドシェイクのRTT削減 セキュリティーの改善。…

Limited Use of Remote Keys(Lurk)についてのメモ

kazuhoさんのIETF95参加報告資料が参考になるかと思います(20160608追記) http://www.slideshare.net/kazuho/tls-lurk-ietf-95 2016年1月に、IETFで"Limited Use of Remote Keys(Lurk)"と言う議論が始まりました。 Lurkに関する議論はIETF95のBoFで議論され…

HTTP/2における証明書に基づいたリアクティブなクライアント認証 その1

20190311追記 最新仕様である Secondary Certificate Authentication in HTTP/2の解説記事を書きました asnokaze.hatenablog.com draft 01で大きくな変更が加えられました。証明書を要求するフローは以下より大きく変わりました。ご注意ください (2016/01/27…