はじめに tcpdump や Proxy を使わずに Wireshark だけで TLS 通信の復号に成功しました。たくさんの人が同じようなことをやっていますが、自分用メモとして残しておきます。OS は Windows10 、ブラウザは Chrome です。 設定手順 TLS で暗号化する際に生成した鍵情報をファイルに出力する Windowsキー + R で「ファイル名を指定して実行」画面を出し、「control」と入力して「OK」を押します。 「システムとセキュリティ」をクリックします。 「システム」をクリックします。 「システムの詳細設定」をクリックします。 「詳細設定」タブ → 「環境変数」をクリックします。 「システム環境変数」の「新規」をクリックします。 以下のように入力します。 変数名 SSLKEYLOGFILE 変数値 C:\temp\tls.keys 変数値は存在するパスな
はじめに HTTPS通信はTLSで暗号化されるので，パケットキャプチャしても暗号化前の通信は解読できません。ただ，HTTPS通信の中身をやっぱり見てみたくなることがあります。このような場合，共通鍵（セッション鍵）をcurlの機能で記録し，Wiresharkに共通鍵を認識させることで，TLS通信の内容を解読できます。 テスト環境 キャプチャ取得環境 ubuntu22.04 curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
SRE 兼よろず屋の id:sora_h です。最近は本社移転プロジェクトをやっています。趣味は Web *1 です。 さて、クックパッドでは 2020 年 12 月に TLS 1.0 および TLS 1.1 (以後 "Legacy TLS") を廃止しました。 Legacy TLS は RFC 7457 でまとめられているような既知の脆弱性の存在などから、Chrome, Firefox といった主要ブラウザを含め各所でのサポートが打ち切られつつあります。また、現在では IETF においても Legacy TLS は deprecated と RFC 8996 にて宣言されました。 クックパッドでもセキュリティ対策およびレガシーな技術と向き合う一環で廃止を進めました。我々は歴史の長いサービスも提供しているため、古い Android や Internet Explorer などからのアクセス
This post is also available in: English (英語) 概要 本シリーズは、疑わしいネットワークアクティビティの調査やネットワークトラフィックのパケットキャプチャ（pcap）の確認を業務で行っておられるセキュリティ専門家を読者として想定しています。このため本稿での手順説明は読者の皆さんがWiresharkの使いかたをご存知であることを前提としています。また、本稿にて利用するWiresharkのバージョンは主に3.xとなります。 昨今、対象となる疑わしいネットワークアクティビティのトラフィックが暗号化されていることは珍しくありません。今はほとんどのWebサイトが Hypertext Transfer Protocol Secure（HTTPS）プロトコルを使用しており、そうした通常の Webサイトと同様にさまざまなマルウェアもまた HTTPS を利用していま
どうもこんにちは。racchaiです。 今日は openssl で独自CAを立てるという、あまり需要のない話をします。 環境は ubuntu 14.04 です。 openssl のインストール CAを作る サーバー証明書を作る CSR の作成 CSR に署名し、証明書ファイルを作成する まとめ openssl のインストール なにはともあれ openssl をインストールしないと始まりません。 $ sudo apt-get install openssl 無事インストールできていることを確認します。 $ openssl version OpenSSL 1.0.1f 6 Jan 2014 CAを作る 基本的には openssl に付属する CA.pl を実行するのみで、あとは聞かれたことに答えていくだけの簡単なお仕事です。 $ /usr/lib/ssl/misc/CA.pl -newca C
CVE-2018-0691.md CVE-2018-0691 プラスメッセージにおける証明書検証不備について https://jvn.jp/jp/JVN37288228/ 平日の業務時間内に見つけた問題である関係で(自分ルールで)所属を入れていますが、他社サービスに対する調査や報告は業務とは一切関係のない個人の活動として行っています。 文責はmala個人にあります。お問い合わせなどありましたら個人宛にどうぞ。TwitterのDMや任意の文字列 @ma.la 概要 2018-06-21 に脆弱性の報告を行い 2018-06-27 に修正版が公開されたプラスメッセージについて、2018-09-27 に情報開示が行われているので、経緯について書きます。 タイムライン 2018-06-21 11:44 プラスメッセージのiOS版が公開されたと聞いてインストールする 2018-06-21 12:54
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には、誰でも
A cipher suite is a set of cryptographic algorithms. The schannel SSP implementation of the TLS/SSL protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for each of the following tasks: Key exchange Bulk encryption Message authentication Key exchange algorithms protect information required to create shared keys. These algorithm
The ordering of cipher suites in the Old configuration is very important, as it determines the priority with which algorithms are selected. OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the Old configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphe
◆ SSL/TLSセッションのハンドシェイク SSLクライアントとSSLサーバとでやりとりされるメッセージのなかで、以下のメッセージについては やりとりを省略した通信が行われる場合もあります。 ・ Server Certificate ・ Server Key Exchange ・ Certificate Request ・ Client Certificate ・ Certificate Verify 例えば、クライアント証明書を使用しないSSL通信であれば「Client CertificateとCertificate Verify」が省略。 ◆ SSL/TLSのメッセージ ・ Client Hello SSLの通信開始をクライアントからサーバに通知するメッセージ。メッセージに含まれている内容は以下です。 ⇒ SSL/TLSのバージョン、乱数、セッションID、クライアントが利用できる暗号
以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli
Internet Engineering Task Force (IETF) E. Rescorla Request for Comments: 8446 Mozilla Obsoletes: 5077, 5246, 6961 August 2018 Updates: 5705, 6066 Category: Standards Track ISSN: 2070-1721 The Transport Layer Security (TLS) Protocol Version 1.3 Abstract This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the I
Feb 8, 2018 Note: This is an outdated version of this blog post. This information is now maintained in a wiki page. See here for the latest version. The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop in the n
Internet Engineering Task Force (IETF) K. Moore Request for Comments: 8314 Windrock, Inc. Updates: 1939, 2595, 3501, 5068, 6186, 6409 C. Newman Category: Standards Track Oracle ISSN: 2070-1721 January 2018 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access Abstract This specification outlines current recommendations for the use of Transport Layer S
SMTPS (Simple Mail Transfer Protocol Secure) is a method for securing the SMTP using transport layer security. It is intended to provide authentication of the communication partners, as well as data integrity and confidentiality. SMTPS is neither a proprietary protocol nor an extension of SMTP. It is a way to secure SMTP at the transport layer, by wrapping SMTP inside Transport Layer Security (TLS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
