Wiki_SSL_TLS - inoueshinichi/Wiki_Web GitHub Wiki

SSLとTLSの基礎

参考

SSL証明書の変遷

  • 2020年 : AppleのSafariが'20/9以降に発行される399日以上の有効期間を持つSSL証明書は信頼しないと発表.
  • 2022年頃 : SSL証明書の有効期間は, 397日. リードタイムは30日となった. 更新作業が30日で間に合わない場合は新規で取得することになった.

Mixed Content警告の強化

HTML本体は, httpsで読み込まれてセキュアでも付随するJavascriptファイルなどがhttpのままで
改竄などの危険があると結果的にページ全体のセキュリティが担保できない. (httpはプログラムの文脈でバグと同じ扱い)

ブラウザ側の対応

  • 鍵マークを表示しない
  • 勝手にhttpsに書き換える
  • ファイルをダウンロードしない

'20からChromeではhttpsページからhttpに置かれた*.exe, .msiなどの実行するファイルや.pdf,*.mp3などの
メディアファイルのダウンロードを段階的にブロックしている.

SSL証明書の課題

過去の発行や認証などの処理の問題が後になって顕在化して
既存のSSL証明書の再発行やWebサーバ側で利用する暗号方式の変更が必要になる場合が多い.
そのため, 有効期間が1年となったことでインシデントは減少傾向となっている.

  • ルート証明書の変更等により現在のSSL証明書が利用できなくなるケースが多い.
  • 認証局(CA)側の仕様変更によってWebサイトを閲覧できる端末が変更されることがある.

SSL証明書の基本

そもそもの目的

  • 盗聴の防止・・・共通鍵暗号方式(AES128~256)
  • 改竄の防止
  • なりすまし防止

改竄防止となりすまし防止の基本構想

  • ドメイン認証 「このサーバ証明書は, ドメインの所有者によって発行されていて, そのサーバから送信されている」ことの証明.
  • 認証局(CA)[第三者機関]によるお墨付きが必要不可欠.

ドメイン認証を実現する方法

  1. 公開鍵暗号方式(南京錠)
  2. PKI(公開鍵暗号基盤)による信頼の連鎖

ドメイン認証に必要な3つの証明書

  • ルート証明書
  • 中間CA証明書
  • サーバ証明書

SSL証明書の発行手順

  1. Webサイトを配信してするWebサーバ内で秘密鍵(KEY)と公開鍵(CSR)を作成する. (CSRはKEYから発行できる)
  2. CSRを中間CAに送信して電子証明を発行(CAのKEYでCSRのハッシュ値を暗号化したものをCSRに付随させる. 電子署名=CSR+CA_KEY(Hash(CSR))
  3. 中間CAに電子署名してもらったものがサーバ証明書となる.
  • ハッシュ関数・・・SHA(Simple Hash Algorithm)
  • CA_KEYによる暗号化・・・RSAがスタンダード(もしくは EDRSA)
  • PKIの公開鍵暗号方式は, RSAもしくはEDRSAの2択.

RSA暗号化アルゴリズムの特殊性

  • 秘密鍵(KEY)でデータの暗号化に使える(=電子証明の発行に使える)
  • 公開鍵(CSR)でデータの復号化に使える.
  • RSAのKEYで電子署名したデータをRSAのCSRで「確かに秘密鍵(KEY)で暗号化した」という事実を証明できる. (PKI技術の核心)

共通鍵暗号方式

共通暗号方式

  • AES(128~256)がスタンダード.
  • ChaCha20

共通暗号方式の素となる種を交換するアルゴリズム

  • DHE
  • ECDHE

HTTPS通信

SSL/TLS証明書によるHTTPS通信に必要なもの

トラストチェーン

  1. ルート証明書(自己証明書)を準備(GoogleやAppleなど大手ベンダーがブラウザに標準で内臓している)・・・トラストアンカー
  2. 中間CA証明書
  3. サーバ証明書

HTTPS通信確立の手順

  1. クライアント(ブラウザ)からサーバにSSL/TLS通信をリクエスト
  2. サーバはクライアントに対して, (サーバ証明書, 中間CA証明書, 暗号スイート, etc)を送信
  3. PKIを用いてクライアント内でサーバのドメイン認証を行う
  4. 鍵交換用の暗号アルゴリズム(DHE,ECDHE)で共通鍵の素を交換
  5. 共通鍵暗号方式(AES,ChaCha20)で暗号通信を開始.
  6. 暗号通信確立後は,共通暗号通信でやり取りする.

PKIを用いたクライアント内でのドメイン認証の詳細

前提: Google, Apple, Amazonなどの大手ベンダーから提供されているクライアントアプリにルート証明書が同梱されている

  1. サーバから受信したサーバ証明書を中間CAに依頼して検証(ルート証明書の直前までに存在する複数の中間CAを繰り返したどる).
  2. 依頼した中間CAを内蔵積みのルート証明書で検証.
  3. サーバ証明書が直接参照(署名してもらった)中間CAと通信して, サーバ証明書の有効性を調査. 有効性が認められればOK
  • クライアントからサーバ証明書が直接参照している中間CAへの問い合わせはクライアントの実装依存となっている.

詳細

  1. RSA/ECDRAアルゴリズムを用いてサーバ証明書([CSR+CA_KEY(SHA(CSR)])を中間CAの公開鍵(CSR)により検証.(ルート証明の直前まで繰り返す)
  2. ルート証明書直前の中間CA証明書がクライアント(PCやスマホ)内のルート証明書により署名されていることを検証する.
  3. CAへサーバ証明書の有効性を確認(念押し的行為)
  4. サーバ証明書記載のドメインと通信先ドメインが一致し、ドメインの有効性が確認される.

ドメイン認証の種類

  • 単一ドメイン証明 (ドメイン:証明=1:1)
  • ダブルドメイン証明 (ドメイン2つ)
  • マルチドメイン証明 (100個以上)
  • ワイルドカードドメイン証明 (e.g. *.co.jp)

ワイルドカードドメイン証明の注意点

  • ワイルドカードに上位階層自身は含まれない
  • ワイルドカードドメイン証明は, 下層のサブドメインは1階層下までしか管理できない
  • 従って, 実質マルチドメイン認証.

例

  • *.tiny-tank.jp
  • tiny-tank.jp
  • test.home.tiny-tank.jpを*.tiny-tank.jpでカバーできない

ワイルドカードドメインに対するSSL/TSL証明

  • tiny-tank.jp, *.tiny-tank.jp, *.home.tiny-tank.jpの3つのドメインに対して, それぞれSSL/TSL証明書を発行しなければならない.
  • 複数のドメインを一つの証明書で管理する技術=SANS

サーバ証明書のランク

  • 高セキュリティ & 高価
  • 拡張組織認証(EV)
  • 組織認証(OV)
  • ドメイン認証(DV)
  • セキュリティ(低) & 安価

ドメイン認証(DV)の実現方法

  • ファイル証明(指定された場所にトークンファイルを置く)
  • メール認証(メール内のリンクをタップする)
  • DNS認証(CNAMEやTXTレコードにトークン文字列を格納する)
  • 認証局や販売サイトによって利用できる手法に制限があったりと様々.

組織証明(OV)の実現方法

  • 国によって申請方法が異なる
  • 日本では法人登記や帝国データバンクのデータベースに登録する
  • 発行されたSSL/TLS証明書にはOrganization項目に企業名・団体名が記載される
  • Google Chromeの場合, 設定項目を開いて4クリック操作をしてやっと閲覧できるほど深い階層に存在する.

拡張組織証明(EV)の実現方法

  • OV + 代表電話番号や銀行口座
  • Google Chromeでは1クリックで閲覧できる(フィッシング詐欺対策)

SSL/TLS証明書発行時のドメイン所有権の確認

  • CAA(Certificate Authority Authorization)・・・DNSリソースレコードの一つ.
  • CAAを設定することで, そのドメインへのSSL/TLS証明書を発行して良い認証局(CA)を指定(制限)できる
  • CAAは予期せぬトラブルに繋がりやすい.
  • 認証局のドメインはサポートページに記載がある.
  • SSL/TLS証明書発行時にもCAによるCAAの検証が必ず入るので注意.
  • サブドメイン(home.tiny-tank.jp)に設定していなくても, ルートドメイン(tiny-tank.jp)に設定されているとサブドメインもCAAが有効になる.

CAAの確認方法

  • $ dig {domain} CAA コマンドを実行する

暗号スイート

  1. SSL/TLS (ドメイン認証形式) (version含む)
  2. 共通鍵の素の交換方式 (DHE, ECDHE)
  3. ドメイン認証方式 (RSA, ECDSA)
  4. 共通鍵暗号方式 (AES, ChaCha20)
  5. 暗号化モード (GCM etc..)
  6. ハッシュ関数 (SHA, MD5,...) の組み合わせ
e.g.
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

SSL/TLSハンドシェイク

前提 : インターネットの通信(TCP/IP)は平文

  • TLSv1.3で通信速度面が改善した
ク 平文リクエスト サ
ラ ----------> |
イ 暗号スイート   バ
ア <---------- |
ン サーバ証明書
ト <----------
   認証
   ---------->
   共通鍵
   <----------
   HTTPS暗号通信
   ---------->
   <----------
   ---------->
   <----------
  • HTTPS通信の最中にJS等でHTTPSドメインとの通信がある場合, すべてのHTTPS通信でSSL/TLSハンドシェイクが発生する
  • HTTPS通信の計算コストは案外高い.
  • 不要なドメインとの通信を減らすことでUXが向上するが... 世の中のトレンドとは真逆..

SSL/TLS証明書の有効期間途中の失効に関する問題

  • ドメインの信頼性が担保できなくなった SSL/TLS証明書はサーバやクライアント(ルート証明書)のハードウェアにインストールされているので
    ブラウザい側の実装で, SSL/TLS証明書の執行チェックが必要.
  • 対策: CRL, OCSP

ドメイン認証を守るPKI運用の絶対条件

  1. すべての秘密鍵(KEY)が秘匿されていること
  2. 端末にルート証明書がインストールされていること
  • 端末にルート証明書がないと, すべての中間CA証明書の効力を失う(中間CAによるお墨付きが無効になる)

SSL/TLS証明書の確認方法

  1. ブラウザ(キャッシュに注意)
  2. SSLチェッカー(SSL Lab チェッカー) https://www.ssllabs.com/ssltest/
  3. OpenSSLクライアントによるコマンドを叩く. ブラウザと異なりキャッシュがないので確実.
⚠️ **GitHub.com Fallback** ⚠️