Wiresharkを使って、自分のHTTPSトラフィックを復号化
Trickster Devより。 HTTPメッセージは、スノーデン後の世界では通常、平文で送信されることはありません。その代わり、HTTPプロトコルに基づく通信の改ざんや監視に対する通信セキュリティを提供するため、TLSプロトコルが使われています。TLS自体は、いくつかのサブプロトコルからなるかなり複雑なプロトコルですが、ここでは、TCP接続上に、公開鍵暗号方式によるサーバ(およびオプションでクライアント)の検証も行う、暗号化と認証レイヤを載せたものと考えてみましょう。 このブログでは以前、モバイルアプリとそのバックエンドシステム間のHTTPS通信を傍受するためのmitmproxyの設定について説明しました。しかし、デスクトップアプリがどのような通信を行っているのかを確認したい場合もあります。さらに、WebアプリのプライベートAPIのリバースエンジニアリングして、Chrome DevToo
セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
『OffSec Training』の対象コースが世界最安となる早割+10%OFFキャンペーン中です。 脆弱性診断やペネトレーションテストのエキスパートを目指す方へ絶好のチャンスです！ 詳細はこちら
TLS 1.3の標準化と実装 | IIJ Engineers Blog
IIJ-II 技術研究所 技術開発室の山本です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも
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で開催された第５回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を除く)をざっと
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
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
皆さまはじめまして、インフラの後藤です。 今回は、そろそろRFCが出る と言われているTLS1.3について簡単に見ていこうと思います。 TLS1.3はその名の通りTLSの次期バージョンです。数字上はマイナーバージョンアップですが、TLS2と呼ぶかといった議論が出るほどに大きな変更が入っています。 このTLS1.3では、多岐にわたるセキュリティの改善はもちろんのことパフォーマンスに関する改善も盛り込まれています。 例えば通信を開始する際のフルハンドシェイクは、TLS1.2と比べると実際のデータを送るまでのメッセージの往復回数が一回少なくなっています (HelloRetryRequestを送るケースもある...) さらに、一度接続したことがあり鍵を共有している相手とは初回からデータを送信する 0-RTTハンドシェイクというハンドシェイクもあります。もちろんこのデータも暗号化されています(ただし
ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ
錆びついたTLSを滑らかに、GoogleによるGREASE試験 - ぼちぼち日記
0. 短いまとめ 長い間、TLSのクライアント・サーバ間で使用するTLSバージョンを合意する際に、 不完全なサーバ実装によって version intolerance が発生することが問題になっていました。 TLS1.3ではこの version intolerance の影響を最小化するため、新しい version negotiation の仕組みを取り入れました。 Googleは、GREASE(Generate Random Extensions And Sustain Extensibility)という仕様をChromeに実装し、TLSサーバのバグで通らない拡張やフィールド値で問題が発生しないか試験を始めました。 パケットキャプチャが好きな人は、Chromeが 0x[0-f]a0x[0-f]a の見慣れない値をCipherSuiteやTLS拡張に使っているのを見つけても驚かないよう気を
本当は怖いAES-GCMの話 - ぼちぼち日記
Disclaimer 本エントリーは、この夏 blackhat usa 2016で行われる予定の講演「NONCE-DISRESPECTING ADVERSARIES: PRACTICAL FORGERY ATTACKS ON GCM IN TLS」 のネタバレを含んでいます。現地で直接聞く方は読まないよう気をつけて下さい。 0. 短いまとめ 今回は短めにと思ったのですが、やっぱりそれなりの分量でした。なので短いまとめを書いておきます。 4千万以上のサイト対してAES-GCM使ったTLS通信の初期ベクトル(IV)データのサーベイが行われ、7万程のサイトでIVの値が再利用される可能性があることがわかりました。IVが再利用された場合、AES-GCMの安全性は致命的な影響を受けます。IVの再利用が判明した幾つか実装から既に脆弱性のアナウンスが出ています。 IVが再利用された場合、現実的にHTTPS
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。 本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。 今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半
すべてのWebサイトの暗号化を目指すLet’s Encryptを試す | さくらのナレッジ
インターネットの爆発的な広がりに合わせてセキュリティ上の問題に注目が集まるようになっています。2010年頃にはFiresheepが広まり、公衆無線LANなどにつないだPCの通信を簡単にモニタリングできてしまう行為が問題になりました。また、昨今のプライバシーに対する懸念から、多くのサイトではHTTPSをデフォルトにするようになっています。 そんな流れもあって現在開発が進められているのがLet's Encryptです。誰でも無料で使えるSSL/TLS証明書発行サービスとなっています。先日、ついにパブリックβになり、誰でもすぐに使えるようになりました。そこで今回はLet's Encryptを使ったサイトのSSL/TLS化手順について紹介します。 なお、執筆時点ではApacheについてはプラグインが提供されていますが、nginx向けは開発中とのことです。ただし手作業で行う分にはnginxでも利用で
Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
パンドラの箱？TLS鍵交換の落とし穴、KCI攻撃とは何か - ぼちぼち日記
1. 初参加のセキュリティキャンプ 先週ですが、講師としてセキュリティキャンプに初めて参加しました。 担当したのは高レイヤーのセッションで、TLSとHTTP/2の講義を合計6時間、まぁ大変でした。講義の時間配分、分量などの検討が十分でなかったため、本番では事前に準備していた講義内容の一部しかできず、ホント反省しきりです。せめての救いは、今回作った講義資料にたくさんのfavを頂いたことです。ありがとうございました。 講義では、学生の方々が短い時間ながら難しい演習に真面目に取り組んでくれました。質疑なども皆受け答えがしっかりしていて、技術的にもレベルが高い回答も多く、非常に驚きました。これだけ優秀な10代、20代の若者が、全国各地から毎年50人も集まるのを実際に見ると、彼らの将来が楽しみです。これまで10年以上継続してこのような活動を続けきた成果でしょう。私自身、とても良い経験をさせていただき
不正なSSL証明書を見破るPublic Key Pinningを試す - ぼちぼち日記
先日のエントリー 「TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説)」で予告した通り、今回不正なSSL証明書を見破る Public Key Pinningの機能について解説します。 Public Key Pinning は2種類の方法があります。あらかじめブラウザーのソースコードに公開鍵情報を埋め込む Pre-loaded public key pinning と、サーバからHTTPヘッダでブラウザに公開鍵情報を通知するHTTP-based public key pinning (HPKP)の２つです。 Chromeは既に両者の機能を実装済ですが、ちょうど近日リリースされる Firefox 32 の Stable バージョンから Pre-loaded public key pinning が実装されました。Firefox32リリース記念と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - facebookincubator/fizz: C++14 implementation of the TLS-1.3 standard