TLS

TLS Encrypted ClientHello(ECH) を BoringSSLで試してみる

SNIが暗号出来る、TLS Encrypted ClientHello(ECH) を BoringSSLで試してみる

HTTP/3からのダウングレード攻撃を防ぐIncompatibleProtocol拡張の仕様

HTTP/3のように、バージョンによって下位層に使うプロトコルが異なる場合でも、ダウングレード攻撃を防ぐIncompatibleProtocol拡張について

サーバ証明書の不正発行に対するSCT Auditing

サーバ証明書の誤発行を検知するためのCertificate Transparencyにおいて、ChromeにSCT Auditingの導入が進められている。

クライアント証明書を中継するClient-Certヘッダの提案仕様

TLSの終端装置が、クライアント証明書の情報をバックエンドに伝えために定義されたClient-Certヘッダの提案仕様。

RFC 8996でTLS1.0とTLS1.1が廃止に

IETFで、TLS1.0とTLS1.1を正式に非推奨にする「RFC 8996 Deprecating TLS 1.0 and TLS 1.1」が公開されました。新しいプロトコルへの移行期間は十分であるとし、TLS1.0, TLS1.1, DTLS1.0は廃止となり、TLS 1.2, TLS1.3, DTLS 1.2のみが使用できます。表現と…

QUIC用APIを実装したOpenSSL forkの登場

AkamaiとMicrosoftらによって、QUIC用APIを実装したOpenSSLのForkが公開されています。流れを観点に説明する。

TCPとTLSを連携させるTCPLS

ルーヴァン・カトリック大学のFlorentin Rochet氏らによって「TCPLS: Closely Integrating TCP and TLS」という論文が出されています。面白そうなのでかんたんにメモしておく。詳しくは論文や文末記載の資料を御覧ください。 TCPLS この論文では、TCPとTLSを…

RFC8879 TLS Certificate Compression について

「RFC8879 TLS Certificate Compression」が昨日公開されました。これは、TLSハンドシェイク中に送信されるサーバ証明書を圧縮する仕組みを定義しています。

ホスト名の異なるTLS session resumptionについて

TLS1.3でホスト名が異なるTLS session resumptionを支援する拡張仕様が出ているので紹介する。

「RFC7525: TLSを安全に使うための推奨事項」の改定

様々な組織や団体がTLSを安全に利用するためのドキュメントを出してたりする。IETFでも2015年にRFC7525 「Recommendations for Secure Use of TLS and DTLS」として、使用する上での推奨事項をまとめている。それについての詳細は、urushima先生の記事を見て…

認証付き暗号の鍵利用上限について

認証付き暗号 "Authenticated Encryption with Associated Data (AEAD)" の利用上の制限について、「Usage Limits on AEAD Algorithms」というドキュメントが公開されている。

TLSハンドシェイク中にアプリケーション設定を送信可能にする提案仕様 (TLS ALPS)

「TLS Application-Layer Protocol Settings Extension」という提案仕様について。これは、TLSハンドシェイク中にアプリケーションプロトコルで必要なパラメータを送信するTLS拡張を定義します。

Compact TLS 1.3の提案仕様

Compact TLS (cTLS)は、よりコンパクトなTLSを定義しデータの通信量を削減しています。

TLS Encrypted Client Hello の暗号化(ECH)に関するメモ

TLS SNIの暗号化のために、ClientHelloの暗号化する方法が提案されている。その構成や仕組みについて簡単に説明する。

RFC8701 TLS GREASEで予約される値

TLSの拡張性を維持するために、未知の拡張仕様を実装が正しく無視するように「Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility」という仕様が長らく議論されてきました。2020年1月に無事RFC8701になったので…

複数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と…

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

RFC8740として標準化された。HTTP/2でTLS1.2を使用している場合はrenegotiatoinが禁止されており、同様の課題をもつTLS1.3のpost-handshake authenticationも明示的に禁止する。

中間証明書を要求しない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 …