Day 8: TLS/SSLとネットワークセキュリティ

今日学ぶこと

• 暗号化がなぜ重要なのか
• 共通鍵暗号と公開鍵暗号
• SSL/TLSの歴史とバージョン
• TLSハンドシェイクの流れ
• 証明書と認証局（CA）
• HTTPS = HTTP + TLS
• 一般的なネットワーク攻撃（MITM、DDoS、ARPスプーフィング等）
• ファイアウォールの種類

---

なぜ暗号化が必要なのか

インターネット上の通信は、複数のネットワーク機器を経由します。暗号化なしの通信は、途中で盗聴・改ざん・なりすましのリスクがあります。

flowchart LR
    subgraph Danger["暗号化なし"]
        A1["送信者"] -->|平文| B1["攻撃者が盗聴可能"] -->|平文| C1["受信者"]
    end
    subgraph Safe["暗号化あり"]
        A2["送信者"] -->|暗号文| B2["攻撃者には読めない"] -->|暗号文| C2["受信者"]
    end
    style Danger fill:#ef4444,color:#fff
    style Safe fill:#22c55e,color:#fff

暗号化が守る3つの要素

要素	英語	説明
機密性	Confidentiality	第三者にデータを読まれない
完全性	Integrity	データが改ざんされていない
真正性	Authenticity	通信相手が本物である

---

共通鍵暗号と公開鍵暗号

共通鍵暗号（対称暗号）

送信者と受信者が同じ鍵を使って暗号化・復号化を行います。

flowchart LR
    subgraph Symmetric["共通鍵暗号"]
        A["平文"] -->|共通鍵で暗号化| B["暗号文"]
        B -->|共通鍵で復号化| C["平文"]
    end
    style Symmetric fill:#3b82f6,color:#fff

アルゴリズム	鍵長	特徴
AES-128	128bit	高速、現在の標準
AES-256	256bit	より安全、やや低速
ChaCha20	256bit	モバイルに最適
3DES	168bit	レガシー、非推奨

メリット： 高速 デメリット： 鍵の共有が困難（鍵配送問題）

公開鍵暗号（非対称暗号）

公開鍵と秘密鍵のペアを使用します。公開鍵で暗号化したデータは、対応する秘密鍵でのみ復号化できます。

flowchart TB
    subgraph Asymmetric["公開鍵暗号"]
        direction LR
        A["送信者"] -->|受信者の公開鍵で暗号化| B["暗号文"]
        B -->|受信者の秘密鍵で復号化| C["受信者"]
    end
    subgraph Keys["鍵ペア"]
        PUB["公開鍵<br/>誰でも入手可能"]
        PRI["秘密鍵<br/>所有者のみ保持"]
    end
    style Asymmetric fill:#8b5cf6,color:#fff
    style Keys fill:#f59e0b,color:#fff

アルゴリズム	鍵長	用途
RSA	2048-4096bit	鍵交換、デジタル署名
ECDSA	256-384bit	デジタル署名（楕円曲線）
Ed25519	256bit	高速な署名
DH / ECDH	可変	鍵交換

メリット： 鍵配送問題を解決 デメリット： 共通鍵暗号より低速

ハイブリッド暗号

TLSでは、両方の長所を組み合わせたハイブリッド暗号を使用します。

1. 公開鍵暗号で共通鍵を安全に共有
2. 以降の通信は共通鍵暗号で高速に暗号化

---

SSL/TLSの歴史

バージョン	年	状態	備考
SSL 2.0	1995	廃止	重大な脆弱性
SSL 3.0	1996	廃止	POODLE攻撃で危殆化
TLS 1.0	1999	廃止	SSL 3.0の後継
TLS 1.1	2006	廃止	CBC改善
TLS 1.2	2008	現行	広く使用されている
TLS 1.3	2018	最新	高速化・安全性向上

SSL（Secure Sockets Layer）とTLS（Transport Layer Security）は同じ目的のプロトコルです。SSLは廃止されましたが、「SSL証明書」「SSL/TLS」という呼び方は慣習的に残っています。

---

TLSハンドシェイク

TLS 1.2のハンドシェイク

sequenceDiagram
    participant Client as クライアント
    participant Server as サーバー

    Note over Client, Server: TLS 1.2 ハンドシェイク（2-RTT）
    Client->>Server: ClientHello（対応暗号スイート、ランダム値）
    Server->>Client: ServerHello（選択した暗号スイート、ランダム値）
    Server->>Client: Certificate（サーバー証明書）
    Server->>Client: ServerKeyExchange
    Server->>Client: ServerHelloDone
    Client->>Server: ClientKeyExchange（プレマスターシークレット）
    Client->>Server: ChangeCipherSpec
    Client->>Server: Finished（暗号化確認）
    Server->>Client: ChangeCipherSpec
    Server->>Client: Finished（暗号化確認）
    Note over Client, Server: 暗号化通信開始

TLS 1.3のハンドシェイク

TLS 1.3では、ハンドシェイクが大幅に簡素化され、1-RTT（1往復）で完了します。

sequenceDiagram
    participant Client as クライアント
    participant Server as サーバー

    Note over Client, Server: TLS 1.3 ハンドシェイク（1-RTT）
    Client->>Server: ClientHello + KeyShare
    Server->>Client: ServerHello + KeyShare + Certificate + Finished
    Client->>Server: Finished
    Note over Client, Server: 暗号化通信開始

TLS 1.2 vs TLS 1.3

比較項目	TLS 1.2	TLS 1.3
ハンドシェイク	2-RTT	1-RTT（0-RTT再接続可）
鍵交換	RSA, DH, ECDH	ECDHE, X25519のみ
暗号スイート	多数（一部脆弱）	厳選された安全なもののみ
前方秘匿性	オプション	必須
廃止された機能	-	RSA鍵交換、CBC、RC4、SHA-1等

前方秘匿性（Forward Secrecy） とは、仮に秘密鍵が漏洩しても、過去の通信が復号化されない性質です。TLS 1.3ではこれが必須になりました。

---

証明書と認証局（CA）

デジタル証明書

デジタル証明書は、サーバーの身元を証明する電子的な身分証明書です。

flowchart TB
    subgraph CertChain["証明書チェーン"]
        Root["ルートCA証明書<br/>ブラウザに組み込み"]
        Inter["中間CA証明書"]
        Server["サーバー証明書<br/>example.com"]
    end
    Root -->|署名| Inter -->|署名| Server
    style Root fill:#ef4444,color:#fff
    style Inter fill:#f59e0b,color:#fff
    style Server fill:#22c55e,color:#fff

証明書に含まれる情報

フィールド	説明
Subject	証明書の所有者（ドメイン名等）
Issuer	発行した認証局
Serial Number	一意の識別番号
Validity	有効期間（開始〜終了）
Public Key	所有者の公開鍵
Signature	認証局による署名
SAN	Subject Alternative Names（複数ドメイン）

証明書の種類

種類	検証レベル	表示	用途
DV（Domain Validation）	ドメイン所有のみ	鍵マーク	個人サイト、ブログ
OV（Organization Validation）	組織の実在確認	鍵マーク	企業サイト
EV（Extended Validation）	厳格な組織確認	組織名表示	金融機関、EC

Let's Encrypt

Let's Encryptは、無料のDV証明書を自動発行する認証局です。ACMEプロトコルにより、証明書の取得・更新を自動化できます。

# Issue a certificate with certbot
sudo certbot --nginx -d example.com -d www.example.com

# Check certificate expiry
sudo certbot certificates

# Renew all certificates
sudo certbot renew

---

HTTPS = HTTP + TLS

flowchart TB
    subgraph HTTPS["HTTPS通信"]
        HTTP["HTTPプロトコル<br/>（アプリケーション層）"]
        TLS["TLS<br/>（暗号化層）"]
        TCP["TCP<br/>（トランスポート層）"]
        IP["IP<br/>（ネットワーク層）"]
    end
    HTTP --> TLS --> TCP --> IP
    style HTTP fill:#3b82f6,color:#fff
    style TLS fill:#8b5cf6,color:#fff
    style TCP fill:#22c55e,color:#fff
    style IP fill:#f59e0b,color:#fff

項目	HTTP	HTTPS
ポート	80	443
暗号化	なし	TLSで暗号化
URL	http://	https://
SEO	不利	有利（Google推奨）
証明書	不要	必要

---

一般的なネットワーク攻撃

MITM（Man-In-The-Middle）攻撃

攻撃者が通信の間に入り、データを傍受・改ざんする攻撃です。

sequenceDiagram
    participant Alice as Alice
    participant Attacker as 攻撃者
    participant Bob as Bob

    Alice->>Attacker: こんにちは、Bob
    Note over Attacker: 内容を盗聴・改ざん
    Attacker->>Bob: こんにちは、Bob
    Bob->>Attacker: 秘密の情報です
    Note over Attacker: 内容を盗聴・改ざん
    Attacker->>Alice: 改ざんされた情報

対策： HTTPS（TLS）の使用、証明書の検証

DDoS（Distributed Denial of Service）攻撃

大量のトラフィックでサーバーを過負荷にし、サービスを停止させる攻撃です。

種類	説明	対策
ボリューム型	帯域を飽和させる	CDN、ISPフィルタリング
プロトコル型	SYN Flood等	SYN Cookie、レート制限
アプリケーション型	HTTP Flood	WAF、レート制限

その他の攻撃

攻撃	説明	対策
ARPスプーフィング	偽のARP応答でトラフィックを傍受	Dynamic ARP Inspection
DNSスプーフィング	偽のDNS応答で偽サイトに誘導	DNSSEC
フィッシング	偽サイトで認証情報を窃取	ユーザー教育、2FA
ポートスキャン	開いているポートを探索	ファイアウォール

---

ファイアウォール

ファイアウォールは、ネットワークトラフィックを監視・制御するセキュリティ装置です。

flowchart LR
    subgraph External["外部ネットワーク"]
        A["インターネット"]
    end
    subgraph FW["ファイアウォール"]
        B["ルール評価<br/>許可/拒否"]
    end
    subgraph Internal["内部ネットワーク"]
        C["サーバー・PC"]
    end
    A -->|トラフィック| B
    B -->|許可| C
    B -->|拒否| A
    style FW fill:#ef4444,color:#fff
    style Internal fill:#22c55e,color:#fff

ファイアウォールの種類

種類	動作レイヤー	特徴
パケットフィルタリング	L3-L4	IP/ポートベースのルール
ステートフル	L3-L4	接続状態を追跡
アプリケーション（WAF）	L7	HTTP内容を検査
次世代ファイアウォール（NGFW）	L3-L7	IPS、アプリ識別、DPI

opensslで証明書を確認

# Connect to a server and show certificate details
openssl s_client -connect example.com:443 -showcerts

# Show certificate information
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -text

# Check certificate expiry
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Verify certificate chain
openssl verify -CAfile ca-bundle.crt certificate.pem

---

まとめ

今日学んだことの整理

トピック	キーポイント
暗号化の必要性	機密性・完全性・真正性を保護
共通鍵暗号	高速だが鍵配送が課題（AES）
公開鍵暗号	鍵配送を解決だが低速（RSA、ECDSA）
SSL/TLSの歴史	TLS 1.2が現行、TLS 1.3が最新
TLSハンドシェイク	TLS 1.3で1-RTTに高速化
証明書とCA	信頼の連鎖でサーバー認証
HTTPS	HTTP + TLS、ポート443
ネットワーク攻撃	MITM、DDoS、ARP/DNSスプーフィング
ファイアウォール	パケットフィルタリング～WAF

重要ポイント

1. ハイブリッド暗号が実用的：公開鍵で鍵交換、共通鍵でデータ暗号化
2. TLS 1.3が推奨：高速かつ安全、前方秘匿性が必須
3. 証明書チェーンを理解する：ルートCA → 中間CA → サーバー証明書
4. 多層防御が重要：暗号化 + ファイアウォール + 適切な設定

---

練習問題

基礎レベル

1. 共通鍵暗号と公開鍵暗号の違いを、メリット・デメリットを含めて説明してください。
2. TLS 1.2とTLS 1.3の主な違いを3つ挙げてください。
3. DV、OV、EV証明書の違いを説明し、それぞれの適切な用途を述べてください。

中級レベル

1. TLS 1.3のハンドシェイクを1-RTTで完了できる仕組みを、TLS 1.2と比較して説明してください。
2. MITM攻撃がHTTPS通信に対して成功するためには何が必要か、またそれが通常困難な理由を説明してください。
3. 以下のコマンドを実行し、出力結果から証明書の発行者、有効期限、使用している暗号スイートを特定してください。

   openssl s_client -connect google.com:443
   

上級レベル

1. 前方秘匿性（Forward Secrecy）の仕組みを、ECDHE鍵交換を例に説明してください。RSA鍵交換ではなぜ前方秘匿性が実現できないのかも述べてください。
2. 大規模WebサービスにおけるDDoS攻撃への多層的な防御戦略を設計してください（CDN、WAF、レート制限などを組み合わせて）。
3. Let's Encryptの自動証明書発行の仕組み（ACMEプロトコル）について、HTTP-01チャレンジとDNS-01チャレンジの違いを説明してください。

---

参考リンク

• TLS 1.3 RFC 8446
• Let's Encrypt - How It Works
• Mozilla SSL Configuration Generator
• Cloudflare - What is TLS?

---

次回予告

Day 9: ワイヤレスネットワークとVPN では、Wi-Fiの仕組みとセキュリティ、VPNの種類と用途を学びます。リモートワーク時代に必須の知識を身につけましょう。