トランスポート層セキュリティ

提供: ArchWiki
（HSTSから転送）
ナビゲーションに移動 検索に移動

Wikipedia より:

Transport Layer Security (TLS) およびその前身の Secure Sockets Layer (SSL) はコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。ウェブブラウザやメール、インスタントメッセージ、voice over IP (VoIP) などのアプリケーションで幅広く使われているプロトコルとなっている。ウェブサイトは TLS によってサーバーとウェブブラウザ間の通信を暗号化できる。

実装

TLS の実装は 5 種類あり、公式リポジトリで公開されています。OpenSSL は base メタパッケージの間接的な依存関係であるため、すでにシステムにインストールされているはずです(base > coreutils > openssl)。GnuTLS は多くのパッケージで必要とされているため、すでにシステムにインストールされている可能性があります。

  • OpenSSL — 堅牢・商業品質・フル機能の TLS と SSL プロトコルのツールキット。汎用の暗号ライブラリでもあります。
https://www.openssl.org/ || openssl
  • GnuTLS — TLS, SSL, DTLS プロトコルのフリーソフトウェア実装。X.509, PKCS #12, OpenPGP などの API を提供します。
https://www.gnutls.org/ || gnutls
  • Network Security Services (NSS) — TLS/SSL と S/MIME をサポートする暗号ライブラリの実装。TLS アクセラレーションとスマートカードもサポート。
https://firefox-source-docs.mozilla.org/security/nss/index.html || nss
  • mbed TLS — ポータブルな SSL/TLS 実装。別名 PolarSSL。
https://tls.mbed.org/ || mbedtls
  • LibreSSL — OpenBSD プロジェクトによって2014年に OpenSSL からフォークされた TLS/crypto スタック。コードベースを近代的に改修してセキュリティを向上させることを目標としています。
https://www.libressl.org/ || libressl

認証局

TLS では、一連の認証局（CA）の 1 つが、サーバーからの公開鍵証明書の信頼性をチェックし署名します。TLS でサーバーに接続するクライアントは、CA の電子署名を通じて、その証明書の信頼性を確認することができます。電子署名を確認するために、クライアントは、別の経路から取得し自己署名証明書として保存された CA の公開鍵を持っている必要があります。Arch Linux では CA 証明書のデフォルトセットは ca-certificates パッケージで提供されています。

ノート: 現在、Arch Linux は Mozilla CA Certificate Store からの CA 証明書をデフォルトセットとして使用しています。

Arch Linux は CA 証明書を管理するために、システム全体の集中化されたインターフェースを提供します。このインターフェースは libp11-kit パッケージの /usr/lib/pkcs11/p11-kit-trust.so というライブラリで、証明書のための PKCS #11 API を提供し、/usr/share/ca-certificates/trust-source/ ("Default Trust" トークン) と /etc/ca-certificates/trust-source/ ("System Trust" トークン) に格納されています。

コマンドラインからインターフェースを使用するために、p11-kit パッケージは trust(1) ユーティリティを提供します。

CA 証明書の管理に独自の論理を使用しており PKCS #11 に移植されていないライブラリのために、ca-certificates-utils パッケージは update-ca-trust(8) スクリプトを提供し、集中管理インタフェースを通して得られた CA 証明書を /etc/ca-certificates/extracted/ と /etc/ssl/certs/ にコピーします。

CA 証明書のデフォルトセットをロードするためのメカニズムの概要

実装 メカニズム Arch Linux 設定
OpenSSL ハードコードされたディレクトリまたはファイルから証明書をロードする API 関数を提供するSSL_CTX_set_default_verify_paths(3)。 デフォルトファイルは /etc/ssl/cert.pem です。デフォルトディレクトリは /etc/ssl/certs/ です。
GnuTLS ハードコードされたディレクトリ、ファイル、または設定された PKCS #11 モジュールから証明書をロードする API 関数を提供する。最後のケースでは、ハードコードされた URL によって、任意の信頼できる証明書、または trust-policy: yes とマークされたモジュール上の信頼できる CA 証明書、オプションで追加のフィルタリング基準を持つ証明書をロードすることができます[1], [2]。 設定された PKCS #11 モジュールから、trust-policy: yes でマークされた、信頼できるすべての CA 証明書をロードします。
Network Security Services 専用の API で管理されている PKCS#11 モジュールの動的に構成されたリストから証明書を自動的にロードします。構成は、ユーザーが指定した任意のディレクトリに保存できます。 [3], modutil(1).
mbed TLS ユーザーは証明書をロードする必要があります。 [4].
LibreSSL ハードコードされたディレクトリまたはファイルから証明書をロードする API 関数を提供します。 libressl-SSL_CTX_load_verify_locations(3) デフォルトのファイルは /etc/libressl/cert.pem で、デフォルトのディレクトリは /etc/libressl/certs/ です。
ノート: 現在、LibreSSL は独自の CA 証明書のリストを使っています。詳細は FS#69298 を参照して下さい。

信頼管理

信頼管理のために trust(1) というユーティリティが提供されています。 trust-policy: yes と設定され priority: の設定と共に保存されている PKCS #11 モジュールのリストを元に動作します。モジュールの設定の詳細については pkcs11.conf(5) を参照して下さい.

ノート: PKCS #11 インターフェースをサポートしていないライブラリーでの管理状態を修正した場合、毎回 update-ca-trust(8) を実行して下さい。
ヒント: p11tool(1) や pkcs11-tool(1) といった PKCS #11 モジュールの操作のための、統合的なツールを使って管理する事も可能です。

信頼された証明書のリスト

$ trust list

信頼された証明書のリストへ追加する方法

# trust anchor certificate.crt

証明書は、 persistence フォーマットあるいは、 DER や PEM フォーマット (OpenSSL がサポートする trusted certificate フォーマットを含む) でリストされている必要があります。このコマンドは、証明書をモジュールリストの一番始めの書き込み可能なトークンとして追加します。

警告: この方法はシステムの全ユーザが秘密鍵にアクセスする事を可能とし、TLS トラフィックの傍受ができ得る状態になります。詳細は HTTPS MITM プロキシ を参照して下さい。

信頼された証明書のリストからの削除

$ trust anchor --remove 'pkcs11:id=%00%11%22%33%44%55%66%77%88%99%AA%BB%CC%DD%EE%FF%00%11%22%33;type=cert'

デフォルトの証明書リストの上書き

/usr/share/ca-certificates/trust-source/ にある証明書のトークンは書き込み制限が掛けられているため、デフォルトの証明書を無効化するためには次の様なコマンドを使います: 

$ trust extract --format=pem-bundle --filter='pkcs11:id=%00%11%22%33%44%55%66%77%88%99%AA%BB%CC%DD%EE%FF%00%11%22%33;type=cert' /etc/ca-certificates/trust-source/blocklist/untrusted_authority.pem

証明書を取得

最初に RSA 秘密鍵を生成してください。鍵を生成する前に、umask でファイルモード作成マスクを制限的に (例えば 077) 設定してください。

ノート: openssl パッケージは他のディストリビューションと違って /etc/ssl/private ディレクトリを保護しません。FS#43059 を参照。

証明書は 証明書署名要求 (CSR) を使って認証局から取得するか、あるいは 自己署名 することができます。自己署名証明書は簡単に生成できますが、クライアントはデフォルトでは拒否するため、自己署名証明書を信頼するようにクライアントを設定する必要があります。

実際の生成コマンドは以下の実装の記事を見てください:

ヒント: ACME を使うことで Let's Encrypt 認証局からフリーの証明書を取得できます。

サーバーサイドの推奨事項

TLS に対する攻撃 は多数存在するため、ベストプラクティスに注意してください:

TLS のチェック

TLS をチェックするプログラム:

TLS をチェックするウェブサイト:

その他

ACME クライアント

Automated Certificate Management Environment (ACME) プロトコルは Let's Encrypt などの 認証局 から X.509 証明書をリクエストできるプロトコルです。

ACME クライアントの一覧 も参照してください。

  • acme-client — C で書かれたセキュアな Let's Encrypt クライアント。
https://kristaps.bsd.lv/acme-client/ || acme-clientAUR[リンク切れ: パッケージが存在しません]
  • acme-tiny — Let's Encrypt から TLS 証明書を作成・更新するための200行の Python スクリプト。
https://github.com/diafygi/acme-tiny || acme-tiny
  • acme.sh — Unix シェルスクリプトだけで作られた ACME クライアント。
https://github.com/Neilpang/acme.sh || acme.sh-gitAUR
  • acmetool — Go で書かれた使いやすい ACME CLI。
https://github.com/hlandau/acme || acmetoolAUR, acmetool-gitAUR
  • Certbot — Python で書かれた、Let's Encrypt によって推奨されている ACME クライアント。
https://github.com/certbot/certbot || certbot
  • dehydrated — Bash で書かれた ACME クライアント。
https://github.com/lukas2511/dehydrated || dehydrated, dehydrated-gitAUR
  • getssl — Bash で書かれた ACME クライアント。
https://github.com/srvrco/getssl || getsslAUR, getssl-gitAUR
  • lego — Go で書かれた Lets Encrypt クライアントと ACME ライブラリ。
https://github.com/xenolf/lego || lego-gitAUR
  • letsencrypt-cli — もうひとつの Letsencrypt (ACME) クライアント。Ruby を使用。
https://github.com/zealot128/ruby-acme-cli || letsencrypt-cliAUR
  • manuale — 完全手動の Let's Encrypt クライアント。Python で書かれています。
https://github.com/veeti/manuale || manualeAUR
  • ruby-acme-client — letsencrypt の ACME プロトコルの Ruby クライアント。
https://github.com/unixcharles/acme-client || ruby-acme-clientAUR
  • simp_le — シンプルな Let's Encrypt クライアント。Python で書かれています。
https://github.com/zenhack/simp_le || simp_le-gitAUR

オンラインのインタラクティブな、https://gethttpsforfree.com クライアントでは、ウェブページからシェルコマンドラインにコピーペーストして、10 回ほどやり直す必要があります。その間に推奨されるコマンドを実行します。また、おそらくそのページで手動更新をしなければならないでしょう。あるいは、他の方法で更新を行う必要があります。一方、あなたは、それが成功したかどうか、すべてのステップで見ることができます。証明書を要求するためだけにソフトウェアをインストールする必要はありません。そして、秘密鍵やサーバー・ソフトウェアを、完全に意識的にしか触れないようにすることができるようになります。

OCSP

Online Certificate Status Protocol (OCSP) は Firefox によってサポートされています。Chromium は独自のメカニズムを備えています [5]。

GnuTLS の ocsptool(1) や OpenSSL の ocsp(1ssl) も参照。

HSTS

HTTP Strict Transport Security (HSTS) メカニズムは Firefox, Chromium, wget (~/.wget-hsts) によってサポートされています。

DNS CAA

See Wikipedia:DNS Certification Authority Authorization.

参照

「https://wiki.archlinux.jp/index.php?title=トランスポート層セキュリティ&oldid=38403#HSTS」から取得