mcpField
C
configuring-tls-1-3-for-secure-communications

configuring-tls-1-3-for-secure-communications

github.com/mukul975セキュリティ35.2k174 回インストール8 週間前に更新
リポジトリ

configuring-tls-1-3-for-secure-communications について

サーバー管理者や開発者向けの TLS 1.3 設定・検証スキルです。nginx、Apache、Python を扱い、旧プロトコルの無効化や設定テスト、0-RTT のリプレイリスクを説明します。

主な機能

  1. 01nginx と Apache での TLS 1.3 設定
  2. 02Python の ssl モジュールの利用
  3. 03openssl と testssl.sh による検証
  4. 04鍵交換グループと暗号スイートの設定
  5. 05リプレイリスクを考慮した 0-RTT 設定

活用シーン

  1. 01Web サーバーでの TLS 1.3 有効化
  2. 02TLS 1.0 と 1.1 の拒否確認
  3. 03証明書チェーンと暗号設定の検証
  4. 040-RTT データのリプレイリスク評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill configuring-tls-1-3-for-secure-communications

インストール後、Claude Code で/configuring-tls-1-3-for-secure-communicationsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
assets/
template.md
references/
api-reference.md
standards.md
workflows.md
scripts/
agent.py
process.py

詳細

安全な通信のための TLS 1.3 の設定

概要

TLS 1.3（RFC 8446）は、Transport Layer Security プロトコルの最新バージョンであり、セキュリティとパフォーマンスの両面で TLS 1.2 を大幅に改善しています。ハンドシェイクのレイテンシーを 1-RTT（再開セッションでは 0-RTT）に短縮し、古い暗号スイートを廃止するとともに、完全前方秘匿性を必須としています。このスキルでは、サーバーでの TLS 1.3 の設定、設定の検証、よくある設定ミスのテストについて説明します。

使用する場面

  • 環境で安全な通信のための TLS 1.3 機能をデプロイまたは設定する場合
  • コンプライアンス要件に沿ったセキュリティ制御を確立する場合
  • このドメインのセキュリティアーキテクチャを構築または改善する場合
  • この実装を必要とするセキュリティ評価を実施する場合

前提条件

  • 暗号技術の概念とツールに関する知識があること
  • 安全に実行できるテスト環境またはラボ環境にアクセスできること
  • 必要な依存関係をインストールした Python 3.8 以降
  • テスト活動に必要な適切な許可を得ていること

目標

  • nginx および Apache ウェブサーバーで TLS 1.3 を設定する
  • ssl モジュールを使用して Python アプリケーションに TLS 1.3 を実装する
  • openssl と testssl.sh で TLS 設定を検証する
  • TLS 1.3 の暗号スイートと鍵交換メカニズムを理解する
  • 適切な保護策を講じて 0-RTT の早期データを設定する
  • 古い TLS バージョン（1.0、1.1）と脆弱な暗号スイートを無効にする

主な概念

TLS 1.3 の暗号スイート
暗号スイート鍵交換認証暗号化ハッシュ
TLS_AES_256_GCM_SHA384ECDHE/DHE証明書AES-256-GCMSHA-384
TLS_AES_128_GCM_SHA256ECDHE/DHE証明書AES-128-GCMSHA-256
TLS_CHACHA20_POLY1305_SHA256ECDHE/DHE証明書ChaCha20-Poly1305SHA-256
TLS 1.3 と 1.2 の改善点
  • 1-RTT ハンドシェイク：完全なハンドシェイクが 1 往復で完了します（TLS 1.2 では 2 往復）
  • 0-RTT 再開：再開した接続では、ただちにデータを送信できます
  • RSA 鍵交換なし：一時的な Diffie-Hellman のみを使用します（PFS が必須）
  • 簡素化された暗号スイート：CBC、RC4、3DES、静的 RSA、SHA-1 を廃止しています
  • 暗号化されたハンドシェイク：ServerHello の後、サーバー証明書が暗号化されます
鍵交換グループ
  • x25519：Curve25519 ECDH（推奨、高速）
  • secp256r1：NIST P-256 ECDH（幅広くサポート）
  • secp384r1：NIST P-384 ECDH（より高い安全性の余裕）
  • x448：Curve448 ECDH（最高レベルの安全性）

ワークフロー

  1. OpenSSL のバージョンが TLS 1.3 をサポートしていることを確認します（1.1.1 以降）
  2. TLS 証明書と秘密鍵を生成するか、取得します
  3. TLS 1.3 の暗号スイートを使用するようにサーバーを設定します
  4. TLS 1.0 と 1.1 を無効にします（互換性のために 1.2 を残すこともできます）
  5. 優先する鍵交換グループを設定します
  6. 証明書の検証のために OCSP ステープリングを有効にします
  7. openssl s_client と testssl.sh で設定をテストします
  8. HTTP Strict Transport Security の HSTS ヘッダーを設定します

セキュリティに関する考慮事項

  • 0-RTT データはリプレイ攻撃に対して脆弱です。冪等なリクエストに限定してください
  • 古いクライアントのサポートが必要な場合は、必ず TLS 1.2 へのフォールバックを含めてください
  • パフォーマンス向上のため、RSA より ECDSA 証明書を使用してください
  • クライアントによる証明書の検証を改善するため、OCSP ステープリングを有効にしてください
  • max-age を長くし、includeSubDomains を指定した HSTS ヘッダーを設定してください
  • Certificate Transparency ログを監視してください

検証基準

  • TLS 1.3 のハンドシェイクが正常に完了する
  • 承認された暗号スイートのみが提示される
  • 完全前方秘匿性が適用されている
  • TLS 1.0 と 1.1 が拒否される
  • OCSP ステープリングが機能している
  • 証明書チェーンが有効で完全である
  • testssl.sh で脆弱性が報告されない

コメント

Markdown 対応