タグ

TSLに関するteddy-gのブックマーク (8)

  • SSL/TLS(Part.1)

    まず、目立つのは下半分に横たわるReocord Protocolである。Record Protocolより上位にある各プロトコルは、Record Protocolを介して対向する通信相手とデータをやり取りする。Record Protocolは前述のように圧縮/暗号化を行っているので、これら上位プロトコルでの通信内容は原則として暗号化されることになる。 その際、Record Protocolでは、図中の「利用中の暗号化パラメータ」と書かれている情報に基づいて暗号化の処理を行っている。この「利用中の暗号化パラメータ」には、具体的に言えば、使用する圧縮アルゴリズムや暗号アルゴリズム、また暗号化/復号で使うキーなどが含まれる。いわば「圧縮/暗号化のルール」とでも考えれば分かりやすいだろう。 では、この「利用中の暗号化パラメータ」は、どうやって取り決めるのだろうか。「圧縮/暗号化のルール」である以上

    SSL/TLS(Part.1)
    teddy-g
    teddy-g 2018/03/29
    SSL/TSLのプロトコルの中身がよくわかる。
  • 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プロト

    SNIの急増とその背景
    teddy-g
    teddy-g 2018/02/04
    CientHelloにSNIが入ってるとホスト名=サービス名がわかるのでサーバ側が助かる。
  • https://dl.acm.org/citation.cfm?id=2996768

    teddy-g
    teddy-g 2017/08/22
    この記事読みたい。
  • セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ

    GMOサイバーセキュリティ byイエラエ株式会社は国内トップクラスのホワイトハッカーが多数在籍するサイバーセキュリティの会社です。攻撃手法に関する豊富な知識と最先端の技術を持つホワイトハッカーが仮想敵となり、お客様の抱えるセキュリティ上の問題の可視化と課題解決をサポートします。 「誰もが犠牲にならない社会を創る」をミッションとして掲げ、デジタルネイティブの時代を生きるすべての人が安全に暮らせるインターネット社会創りに貢献します。

    セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
    teddy-g
    teddy-g 2017/03/31
    TLS Extensionsの中のSNIがTLS1.3から暗号化される話。
  • SSL/TLS(SSL3.0~TLS1.2)のハンドシェイクを復習する

    以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその1です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って?と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli

    SSL/TLS(SSL3.0~TLS1.2)のハンドシェイクを復習する
    teddy-g
    teddy-g 2017/03/26
    TLSハンドシェイクの日本語説明。これも簡潔。
  • 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。 これは

    InfoQ: HTTPSコネクションの最初の数ミリ秒
    teddy-g
    teddy-g 2017/03/26
    HTTPSの最初の方、ハンドシェイクの 辺りを丁寧に説明している記事の日本語版。為になる。
  • WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる

    OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO

    WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
    teddy-g
    teddy-g 2017/03/26
    HTTPS通信をWiresharkを使って覗いてみる話。ちょっとやってみる必要あるな。
  • 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プロトコルのハンドシェイクタイプの

    HTTPSのパケットをwiresharkで見てみる - Qiita
    teddy-g
    teddy-g 2017/03/26
    HTTPSの最初の方、ハンドシェイクの簡単な説明。
  • 1