SSL／TLS（Part.1）
まず、目立つのは下半分に横たわるReocord Protocolである。Record Protocolより上位にある各プロトコルは、Record Protocolを介して対向する通信相手とデータをやり取りする。Record Protocolは前述のように圧縮／暗号化を行っているので、これら上位プロトコルでの通信内容は原則として暗号化されることになる。 その際、Record Protocolでは、図中の「利用中の暗号化パラメータ」と書かれている情報に基づいて暗号化の処理を行っている。この「利用中の暗号化パラメータ」には、具体的に言えば、使用する圧縮アルゴリズムや暗号アルゴリズム、また暗号化／復号で使うキーなどが含まれる。いわば「圧縮／暗号化のルール」とでも考えれば分かりやすいだろう。 では、この「利用中の暗号化パラメータ」は、どうやって取り決めるのだろうか。「圧縮／暗号化のルール」である以上
解説！SPDYから進化を遂げたHTTP/2の概要と特徴
最近、GoogleのHTTP/2に対する関心が高くなっているように感じます。 以前「Chromium Blog」でHTTP/2への移行に関する公式アナウンスもありましたが、GoogleChromeが着々とHTTP/2への対応を進めています。公式アナウンス当初、Chrome から参照されているリソースの 25% 以上が HTTP/2 で提供されている、とされていましたので、現在ではさらに多くの割合を占めているものと考えられます。 今回は、このような流れを踏まえ、HTTP/2の概要についてご紹介します。 （参考）Transitioning from SPDY to HTTP/2（HTTP/2への移行に関する公式アナウンス） 【無料】ねぎお社長のSEOメールマガジン※30秒で登録完了 購読者数は既18000人を突破！ SEO業界20年のねぎお社長が最新情報、ノウハウ、考え方などこのメルマガでしが
SNIの急増とその背景
注：以下では、ワールドワイドにCDNを展開するアカマイネットワークでのSNI利用急増の背景が説明されています。 アカマイ・テクノロジー社では、TLSの拡張仕様であるSNI（Server Name Indication）のクライアントサポートが急増しています（2017年3月時点で、アカマイ社のクライアントによるHTTPS要求は、SNIの使用率が99％超）。 従来、すべてのWebトラフィックをHTTPSに移行するには、2つの大きな問題がありました。 第1に、サーバー証明書の可用性（アベイラビリティ）の問題です。 Let’s Encryptなどのプロバイダーにより提供される自動ドメイン認証（DV）証明書が、この問題の解決に貢献しています。 第2に、TLS仮想化ホスティングに関する技術的な問題です。 SNIは、これに対して最も拡張性（スケーラビリティ）の高い解決策です。 その背景には、TLSプロト
Detecting Encrypted Malware Traffic (Without Decryption)
Introduction Over the past 2 years, we have been systematically collecting and analyzing malware-generated packet captures. During this time, we have observed a steady increase in the percentage of malware samples using TLS-based encryption to evade detection. In August 2015, 2.21% of the malware samples used TLS, increasing to 21.44% in May 2017. During that same time frame, 0.12% of the malware
SSL/TLS（SSL3.0～TLS1.2）のハンドシェイクを復習する
以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli
InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
HTTPSのパケットをwiresharkで見てみる - Qiita
その後、ブラウザなどでhttps化したサイトにアクセスします。 フォアグラウンドで実行しているtcpdumpコマンドをCTRL+Cで停止させ、その後scpコマンドでローカルPCに/tmp/dump_https.pcapファイルを持ってきます。 あとはローカルPCのwiresharkでこのパケットキャプチャを見ていきます。 キャプチャした内容を見てみる 順番に見ていきます。 SSLでは実際に暗号化通信を行う前にSSLハンドシェイクを行う必要があります。 ざっくりだと以下をやるようです。 Step1 使用するアルゴリズムの合意 Step2 サーバーの認証 Step3 データ転送で使用する鍵の確立 Step4 ハンドシェイクが正しく行われたことの確認 Wiresharkで細かく通信の流れを見ると以下のようになっていました。 (Client HelloなどはTLSプロトコルのハンドシェイクタイプの
curl - SSL CA Certificates
SSL Certificate Verification SSL is TLS SSL is the old name. It is called TLS these days. Native SSL If libcurl was built with Schannel or Secure Transport support (the native SSL libraries included in Windows and Mac OS X), then this does not apply to you. Scroll down for details on how the OS-native engines handle SSL certificates. If you are not sure, then run "curl -V" and read the results. If
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
User agent information from HTTPS flow
Qualys SSL Labs - Projects / HTTP Client Fingerprinting Using SSL Handshake Analysis
https://dl.acm.org/citation.cfm?id=2996768
TLS Fingerprinting - Stealthier Attacking & Smarter Defending - Derby…
セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
HTTPS and the TLS handshake protocol.