対象のビデオ
前提
なんでこの動画を見るのか
ネットワークって面白そうだけど情報多すぎて整理できないから
私のネットワークレベル
実務ではほぼ担当しない。
ネットワークスペシャリスト受けたら午後2で落ちた。
Section 2: SSL/TLS概要
5. セキュリティリスクの種類
脅威を以下の4つにカテゴライズ。結構この辺を初手で整理しきれてないからいつもこんがらがる。
でもこれサニタイズじゃね？って思うところもあるので続きの動画に期待。
| 脅威 | 内容 | 具体例 |
|---|---|---|
| 盗聴 | 不正な操作で見る権限がない情報を抜き取る | HTTPパラメータに意図的にアプリを破壊するようなデータを送る（SQLインジェクション）など |
| 改ざん | データや通信内容を不正に書き換えられること | クライアントに送られるWebサイトに悪意のあるスクリプトを差し込む（クロスサイトスプリクティング)など |
| なりすまし | 他人や別のシステムになりすましてアクセスすること | 偽ログインサイトへの誘導（フィッシング）など |
| 否認 | 「送っていない」「受け取っていない」と後から主張すること | ECサイトなどで正常に売買が完了したが、購入歴などを書き換え取引自体を無効にするようなこと |
6. SSLの機能（暗号化/MAC/電子署名）
電子署名って鍵が本人のものってのを証明しなければいけないと思いますが、この後にCAとか出てくるんですかね？
| 分類 | 目的 | 方式 | 仕組み・特徴 |
|---|---|---|---|
| 暗号化 | 盗聴対策 | 共通鍵暗号 | 暗号化・復号に同じ共通鍵を使用。通信相手ごとに鍵が必要になりやすく、鍵配送の問題がある。一方で処理は高速 |
| 暗号化 | 盗聴対策 | 公開鍵暗号 | 受信者の公開鍵で暗号化 → 受信者の秘密鍵で復号。各ユーザーが公開鍵・秘密鍵のペアを持つ。共通鍵暗号より低速 |
| 暗号化 | 盗聴対策 | ハイブリッド暗号 | 公開鍵暗号方式で共通鍵を安全に共有し、その後の通信は高速な共通鍵暗号で行う |
| 改ざん対策 | 改ざん検知 | MAC | メッセージ＋MAC鍵 → MAC値を生成。受信側も共有しているMAC鍵でMAC値を再計算し、送られたMAC値と比較する |
| 電子署名 | なりすまし・否認対策 | 電子署名 | メッセージをハッシュ値に秘密鍵で暗号化し、受信者が公開鍵で署名を複合化する。複合化を持って秘密鍵を持っているユーザからメッセージが送られていることを証明する。 |
7. SSL通信の流れ
動画内では多分わざと省いているのだと思うが、いわゆるclient hello、server helloの話。セッション鍵を作って、当該の通信間でのみ使えるようにする流れの話。証明書や認証局の話が動画内に出てこないでちょっと混乱をする。
| 手順 | 内容 |
|---|---|
| 1. 使用するアルゴリズムの合意 | クライアントが対応しているTLSバージョンや暗号スイート（サーバ認証方式・鍵交換方式・共通鍵暗号・MACアルゴリズムなど）、および鍵作成用の乱数 Client Random をサーバへ送る。 (ClientHello) 。サーバはその中から使用する暗号スイートを選択する。 |
| 2. サーバ側の認証 | サーバは選択した暗号スイート、Server Random、サーバ証明書を送る (ServerHello)。クライアントは証明書を公開鍵で検証し、公開鍵が本当に接続先サーバのものであることを確認する。 |
| 3. データ転送で使用する鍵の確立 | クライアントは鍵生成用のランダム文字列 (Pre-Master Secretというらしい) を生成し、サーバの公開鍵で暗号化して送信する。サーバは秘密鍵で復号し、両者は Client Random・Server Random・Pre-Master Secret をもとに Master Secret を生成し、そこから 共通鍵(セッション鍵) や MAC鍵 を生成する。 |
| 4. ハンドシェイクが正常に行われたことの確認 | クライアントとサーバは、新しく生成したセッション鍵を使って、ハンドシェイク全体から計算した検証データを暗号化し交換する(Finished メッセージ)。双方で検証に成功すれば、同じ鍵を共有できており、ハンドシェイク中に改ざんも行われていないことが確認できる。 |
8. SSLの歴史
SSLから始まり今はTLSになっている話。
NetscapeがSSLを作っていたわけだが、インターネットの暗号化技術のHTTPSを一企業が持っているのはよくないのでIETFがSSL3.0を元にTLS1.0を作成。
ちなみに2026年現在で以下のプロトコルは廃止されている。
・SSL全般
・TLS1.0、TLS1.1
Secure Sockets LayerがTransport Layer Securityになったわけですけど
セキュアレイヤーがレイヤーセキュリティになって単語が前後してるからたまに混乱する。
9. SSL通信の種類
HTTPSとかFTPSとかSMTPSとかSSL-VPNの話。
SSLは廃止されているがいまだに名称としては出てくるから混乱するところある。
10. 電子証明書作成の流れ
電子証明書はTLSのハンドシェイク時にサーバからクライアントに引き渡す。
この時にサーバは自分の証明書からルートACまで遡ることができる中間ACの証明書も一緒に送る。（証明書チェーン）
自己証明書はこの証明書チェーンが送れないので自己証明書とバレる。
証明書チェーンはルートACの証明書のみ送る必要がない。これはルートACはブラウザやOSの信頼ストアに最初から登録済みであるからである。
| 認証の厳密さ | 種類 | 発行前に確認する内容 |
|---|---|---|
| 低 | DV（Domain Validation） | そのドメインを管理していることを確認 |
| 中 | OV（Organization Validation） | ドメイン管理に加えて、組織が実在することなどを確認 |
| 高 | EV（Extended Validation） | ドメイン・組織の実在性に加えて、所在地・申請者の権限などをより厳格に確認 |
| 種類 | 署名 | 信頼性 |
|---|---|---|
| 自己署名証明書（Self-Signed Certificate） | 自分自身の秘密鍵 | CAによる第三者保証がないため、そのままではブラウザ等から信頼されない |
| CA署名証明書（CA-Signed Certificate） | 認証局（CA）の秘密鍵 | 信頼されたCAまで証明書チェーンをたどれれば、ブラウザ等から信頼される |
| CA | 役割 | 署名担当 |
|---|---|---|
| ルート認証局（Root CA） | 信頼の起点。中間CAなどの証明書に署名する | 自分自身で署名（自己署名） |
| 中間認証局（Intermediate CA） | 実際のサーバ証明書などの発行を担当する | ルートCAまたは上位の中間CA |
Section 3: AWSアカウント作成
11. AWSアカウントの作成
既にアカウント持っているので省略
Section 4: Webサイト構築
12. AWSの基本用語
知っているので省略