はじめに
この記事の目的
本記事は、SSLとTLSの各バージョンについて歴史、特徴、脆弱性、運用上の注意点を分かりやすくまとめます。特にTLS 1.3の優位性や現在推奨される設定について丁寧に解説します。
なぜ重要か
インターネット上のデータは第三者に盗まれたり改ざんされたりします。例えば、買い物やログイン情報を安全に送るために暗号化が必要です。SSL/TLSはそのための仕組みで、安全性はバージョン選びに左右されます。
想定読者と読み方
システム管理者や開発者はもちろん、初めて学ぶ方にも配慮して書いています。第2章以降で歴史→各バージョン→脆弱性→運用と順に説明しますので、興味のある章からお読みください。
SSL/TLSとは何か？その歴史と概要
概要
SSL（Secure Sockets Layer）は1990年代に登場した、インターネット上の通信を暗号化する仕組みです。後継のTLS（Transport Layer Security）は、同じ目的でより安全に改良された規格です。ウェブサイトのURLが「https」で始まるときやブラウザの鍵マークは、この暗号化が働いていることを示します。
歴史
最初に作られたのはNetscape社によるSSLで、改良を重ねる中で脆弱性が見つかりました。その後、インターネット標準を扱う組織が改良版としてTLSを策定しました。TLSは段階的に改良され、より強い暗号方式や運用ルールが導入されてきました。
なぜTLSが必要か
通信を暗号化しないと、第三者に内容を見られたり改ざんされたりします。特に公開Wi‑Fiや送信する個人情報がある場合は危険です。TLSは通信の秘匿性と改ざん防止、相手の確認（認証）を提供します。
現在の呼び方と注意点
日常では「SSL」と呼ばれることが多いですが、実際の技術はTLSが使われます。証明書は「SSL証明書」と呼ばれることがありますが、中身はTLSで使われる証明書です。運用や設定では、最新のTLSを使うことを意識してください。
主なSSL/TLSバージョンの一覧と特徴
概要
ここでは歴史順に代表的なバージョンを挙げ、それぞれの特徴をやさしく説明します。専門用語は少なく、具体例で補足します。
SSL 1.0（非公開・廃止）
公開されず開発段階で終わった仕様です。実運用はされていません。
SSL 2.0（1994年・廃止）
初めて公開されたバージョンです。基本的な暗号化はありますが、設計上の欠陥で簡単に攻撃される可能性があり、現在は使われません。
例：簡単な改ざんや盗聴に弱い設計でした。
SSL 3.0（1995年・廃止）
大幅に改善されましたが、後に“POODLE”という脆弱性が見つかり廃止されました。
例：当時はウェブ閲覧の暗号化に用いられましたが、攻撃でセッション情報が漏れる恐れがありました。
TLS 1.0（1999年）／TLS 1.1（2006年）
SSLから名前を変えた世代です。TLS1.0と1.1は当時の標準でしたが、現在は安全性の観点から廃止または非推奨です。
TLS 1.2（2008年）
SHA-2など安全なハッシュ関数や、AEAD（暗号化と整合性を同時に担う方式）を導入しました。多くのサイトで今も使われています。
例：AES-GCMという方式が代表的で、高速で安全です。
TLS 1.3（2018年）
暗号方式を絞り、通信回数を減らして高速化しつつ安全性を高めました。復元（再接続）を速くする仕組みもありますが、ゼロ再送（0-RTT）は再送攻撃の注意が必要です。
現状：TLS1.3が推奨され、可能なら優先して使うのが良いです。TLS1.2は下位互換として多く残ります。
各バージョンの脆弱性と現状
SSL 2.0 / SSL 3.0
SSL 2.0は設計が古く、暗号強度やプロトコル保護に致命的な欠陥があります。SSL 3.0はPOODLEと呼ばれる攻撃で安全性が破られるため、両方とも使用禁止です。具体例としては、古いブラウザと通信すると簡単に中間者攻撃を受けます。
TLS 1.0 / TLS 1.1
これらは初期のTLSで、設計上の弱点や古い暗号を許す点が問題です。代表例はBEASTや圧縮に関連する攻撃で、現在は多くのサービスやブラウザがサポートを終了しています。互換性のために残すとリスクを招きます。
TLS 1.2
現役で広く使われます。強力な暗号（例：AES-GCM）や前方秘匿（PFS）を使えますが、設定ミスで危険になります。例えばRC4やSHA-1を許可したり、小さなDHパラメータを使うと安全性が低下します。サーバー側で安全な暗号順序を優先し、ECDHEやAEADを選ぶことが重要です。
TLS 1.3
設計を簡素化し、危険な機能を削除しました。ハンドシェイクが速くなり、前方秘匿が標準です。最新の推奨であり、対応できるなら導入を勧めます。
運用上の注意
ライブラリを常に更新し、古いバージョン（SSL2/3、TLS1.0/1.1）は無効にしてください。TLS1.2と1.3を有効にし、安全な暗号を優先する設定を行い、定期的に外部のテストで確認してください。したがって、設定と更新を怠らないことが最も重要です。
実際の運用・設定のポイント
運用ではTLS 1.3を優先し、互換性のためにTLS 1.2を必要に応じて許可することを基本とします。TLS 1.1以前やSSLは必ず無効化してください。
サーバー側の基本方針
- ライブラリ（OpenSSL等）を最新に保つ。脆弱性修正や性能向上が含まれます。
- プロトコルは最低限「TLSv1.3, TLSv1.2」とする。例（nginx）: ssl_protocols TLSv1.3 TLSv1.2;
- 鍵と暗号スイートは強いものを選ぶ。推奨はECDHEキー交換とAES-GCM/ChaCha20-Poly1305など。
互換性対策
- 古い機器向けにはTLS1.2を残すが、弱い暗号は拒否する。
- 非対応機器が多い場合はプロキシで翻訳する方法が有効です。
動作確認と監視
- curlやopensslで実際に接続確認する（例: curl –tlsv1.3 -I https://example.com）。
- 定期的に外部スキャナーやログでハンドシェイク失敗を確認し、対応を検討します。
証明書・運用管理
- 鍵長はRSA2048以上、可能ならECCを利用する。
- OCSP Staplingや自動更新（例: Certbot）で運用負荷を下げる。
これらを組み合わせて段階的に古いプロトコルを廃止し、安全な接続を維持してください。
SSLとTLSの違い・誤解しやすいポイント
概観
「SSL」という言い方をよく聞きますが、現代の安全な通信は実質的にすべてTLSで行われます。SSLは古い規格で、TLSがその後継です。名称は慣習として残っているだけで、実際の通信はTLSプロトコルが使われます。
主な違い（分かりやすい例）
- 世代の違い：SSLは古く、脆弱性が多かったためTLSに置き換わりました。例えると、SSLは旧型の鍵、TLSは改良された新型の鍵です。
- ハンドシェイクと暗号方式：TLSはより安全なハンドシェイクやAEAD（暗号と認証を同時に扱う方式）を導入しました。これにより通信の改ざんや復号がより困難になりました。
よくある誤解と正しい理解
- 「SSL証明書」という呼び方：実際にはX.509形式の証明書を使い、通信はTLSで行います。つまり“SSL証明書”＝“TLSで使う証明書”と考えて差し支えありません。
- ブラウザの鍵マーク＝SSLではない：ブラウザが示す鍵アイコンはTLSでの保護状態を表しています。
運用での注意点
- 設定はTLS 1.2以上を有効にして、古いSSL/TLSバージョンは無効にします。旧バージョンは攻撃に弱いです。
- サーバ設定で強い暗号スイート（AEAD、ECDHEなど）を優先してください。互換性だけを重視すると安全性が落ちます。
以上が、混同しやすいポイントと実務上の注意点です。
バージョン選択のまとめと今後の動向
推奨と理由
推奨はTLS 1.3です。接続の高速化や暗号化の強化、設定の簡素化といった利点があります。互換性が必要な場合はTLS 1.2を併用してください。
実務的な移行ポイント
- まずサーバーとライブラリ（OpenSSLなど）を最新版に更新します。2. テスト環境でTLS 1.3を有効化し、主要なクライアント（ブラウザやAPI利用者）で動作確認します。3. ロギングと監視を強化して、接続失敗や互換性問題を早期に発見します。
レガシー対応とリスク管理
古いシステムでTLS 1.3を使えない場合は、TLS 1.2を安全に設定してください。SSLv3やTLS 1.0/1.1は無効にし、強い暗号スイートとForward Secrecyを有効化します。証明書の期限管理も重要です。
今後の見通し
TLS 1.3が標準化されつつあり、新しい実装はこれを基本とします。したがって特別な理由がなければ早めに移行することをおすすめします。
