QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通
「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性（相互接続性）のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
OpenSSL での TLSv1.3 の使用について。 – o6asan's soliloquy-part2
実際には，全く取り掛かれていない TLSv1.3 (2018.8 RFC8446 になりました) なんだけれども，読み始めたら面白くてためになりそうだったので，調子に乗って訳してみた。くりくりさんが仰っていたように，相当変わるんだな。 元の文章は， Matt Caswell 氏の Using TLS1.3 With OpenSSL である。タイムスタンプは MAY 4TH, 2017 11:00 AM になっている。ブログの HTML ソースから見るに， UTC みたい。変なところは，ご容赦。明らかな誤訳は，指摘いただければありがたいです m(_”_)m。以下、訳文です。 ————————————————– 今度の OpenSSL 1.1.1 のリリースには TLSv1.3 のサポートが含まれます。新リリースはバイナリと API において OpenSSL 1.1.0 と互換です。お使いのア
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
TLS証明書の発行・デプロイについて - クックパッド開発者ブログ
こんにちは、インフラストラクチャー部セキュリティグループの三戸 (@mittyorz) です。 クックパッドでは全てのサービスをHTTPSにて提供しています。 今回はHTTPSの使用にあたって必要となるTLS証明書について、申請や発行、管理やサーバへのデプロイなどの運用について書きたいと思います。 TLS終端 クックパッドでは、サービスとユーザーとの通信経路は全てTLSにより暗号化されていますが、通信内容を暗号化するためのTLS終端処理はELBあるいはCloudFrontで行っています。 ELB、CloudFrontともにAWS Certificate Manager(ACM)を用いて証明書を管理*1することが出来ますが、社内向けで外部に公開していないサービスやステージング環境についてはELB背後のリバースプロキシで終端処理をしているものも多く、これらについては証明書ファイルを直接EC2イ
[レポート] TLS 1.3 の標準化動向 #tls13_study ※補足説明付き | DevelopersIO
現在仕様策定中の TLS1.3 ですが、その標準化動向と、最新のドラフトを元にハンズオンを行う勉強会 TLS1.3 Study が先日（2/14）開催されました。 そこで行われた IIJ 山本和彦氏のプレゼンテーションについてレポートします。実際に TLS1.3 の実装を手がけられ draft 策定作業にも参加されている氏の解説は非常に実践的なものでしたが、正直なところわたし自身理解が追いついていないので、以下ではところどころ説明を補っています。わたしが補った部分は 斜体 になっているので、その旨ご了承下さい。 なお、今回の会場は東京日本橋のサイボウズ社さまのオフィスでした。 ※以下敬称略 レポート : TLS 1.3 の標準化動向 ドラフト 18 から最新のドラフトまでの変更を振り返ります 登壇者 : 山本和彦 IIJ Innovation Institute 資料 http://www
![[レポート] TLS 1.3 の標準化動向 #tls13_study ※補足説明付き | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/336dd3ddb65513f9dd7129eb0399b29b3ae30b99/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F02%2Feyecatch-tls13study.png)
RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
macOS High SierraおよびiOS 11では実験的にTLS 1.3 (draft)の利用が可能に。
macOS High SierraおよびiOS 11 betaでは実験的にTLS 1.3(draft)の利用が可能になっています。詳細は以下から。 Appleが公開したWWDC 2017のセッション701″Your Apps and Evolving Network Security Standards”によると、AppleはmacOS 10.13 High SierraおよびiOS 11で新しいプロトコル「TLS 1.3 (draft)」の利用を実験的に開始すると発表しています。 TLS 1.3 would effectively shave 1/3 of that time off, which is a huge win in mobile world. Now, TLS 1.3 is still very much a work in progress.[…]However, if
TLS 1.3 Overview - Qiita
この記事はACCESS Advent Calendar 2016の14日目の記事です。 昨年に引き続きID技術・暗号技術を中心にいろいろやっていたので今年のネタも似たような感じで、現在最終承認に向けて調整が進みつつあるTLS 1.3の話をします。 SSL/TLSとは 認証 暗号化 改ざん防止 の3点を提供するセキュア通信のためのプロトコルです。現在一般的に使われているのは Transport Layer Security(TLS) ですが、過去に使われていた Secure Socket Layer(SSL) という名称が広く浸透しているのでほぼ同じ意味で使われます。 HTTPS というのはHTTP over SSLもしくはHTTP Secureの略で、TLSを使ってセキュアにHTTP通信を行えるプロトコルです。 SSL/TLSが現代のインターネットビジネスにおいて不可欠とされるのには、商取
SSL/TLS（SSL3.0～TLS1.2）のハンドシェイクを復習する
以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。 本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。 今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半
GoogleがTLSでの採用を提唱している共通鍵暗号方式「ChaCha」についてまとめた - sonickun.log
ChaCha（チャチャ）という一見ふざけた名前の暗号が最近（自分の中で）話題ということで，勉強がてらに記事にしてみました． 背景 ChaChaの構造 Salsa20 Chacha 初期状態 ラウンド操作 ChaChaの安全性 実装してみた 参考 背景 2016年4月現在，TLSの新しいバージョンとしてTLS 1.3が提案されており，ドラフトが公開されている． draft-ietf-tls-tls13-11 - The Transport Layer Security (TLS) Protocol Version 1.3 TLS 1.2からの大きな変更点として，以下の2つがある． ハンドシェイクの省略によるRTT（Round Trip Time）の削減 危殆化した暗号の廃止 「危殆化した暗号」とは，Forward SecrecyでないCipher Suite（RSAのみを用いたもの）や，認証
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
