6.2. 暗号化/署名および認証のX.509証明書

6.2.1. SSL/TLSの基本とX.509証明書の役割

SSL/TLSの概要

SSL/TLS

SSL(Secure Sockets Layer)/TLS(Transport Layer Security)はトランスポート層の暗号化プロトコルでWebトランザクションを保護するために開発されたが、トランスポート層でTCPを利用するあらゆる種類のネットワークトラフィックの保護にも使用できる。

TLSとしてIETFによってRFC化され、SSL3.0からTLSが派生した。SSL3.1がTLS1.0に該当する。一般的名称として、SSLという言葉が広く普及しているため、SSL/TLSと呼ばれている。

現在、SSLは脆弱性が発見されているため使用は非推奨となっており、TLSの使用が推奨されている。暗号強度等ではTLS1.2、もしくは2018年3月にIETFに承認されたTLS1.3が良い。

TLS/SSLのハンドシェイクプロセス

TLS は、データを安全に送信する際のパフォーマンスとセキュリティの間で適切な妥協点を提供するため、公開鍵暗号方式と共通鍵暗号方式を組み合わせて使用​​する。 手順は以下の通り。

1. 各TLS証明書は、公開キーと秘密キーで構成されるキーペアで構成される。これらのキーは、Web サイトのトランザクション中に相互作用する。
2. Web サイトにアクセスするたびに、クライアント サーバーと Web ブラウザが通信して、安全な TLS/SSL 暗号化接続が確立されていることを確認する。
3. Web ブラウザ (またはクライアント) がセキュリティで保護された Web サイトにアクセスすると、Web サイト サーバーは TLS/SSL 証明書とその公開キーをクライアントと共有して、安全な接続と一意のセッション キーを確立する。
4. ブラウザは、SSL 証明書の発行者または認証局を認識し、信頼していることを確認する。また、ブラウザは、TLS/SSL 証明書の有効期限が切れていないこと、取り消されていないこと、および信頼できることを確認する。
5. ブラウザは対称セッションキーを送り返し、サーバーは秘密キーを使用して対称セッションキーを復号化する。次に、サーバーはセッションキーで暗号化された確認応答を送り返し、暗号化されたセッションを開始する。
6. サーバーとブラウザは、送信されるすべてのデータをセッションキーで暗号化するようになる。これらは、メッセージのプライバシー、メッセージの整合性、およびサーバーのセキュリティを保護する安全なセッションを開始することを意味する。

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

SSL と TLS はどちらも以下のセキュリティ要件を満たす。

• 交換されるデータを安全に暗号化する
• 少なくとも1人の当事者を認証する
• データの整合性を確保する
• リプレイ攻撃を防ぐ

トランスポート層のセキュリティは、PKI と一般的な暗号化の使用を通じてこれを実現する。

SSLに対する中間者攻撃

• POODLE攻撃の脆弱性
  • POODLE攻撃(CVE-2014-3566) はSSLセッション内の選択されたコンテンツを復号化できる中間者(MITM) エクスプロイトのこと。
• BEAST攻撃の脆弱性
  • BEAST攻撃(CVE-2011-3389)はSSL/TLS 暗号ブロック チェーン (CBC) の弱点を悪用し、中間者攻撃者が Cookie データなどの特定のセッション情報を何からでも回復できるようにする。

6.2.2. Apache HTTPDによるHTTPSサービスの提供

Apache SSL/TLSの基礎

HTTPSと呼ばれるプロトコルは、WebのプロトコルであるHTTPをSSL/TLSでセキュアなプロトコルとして通信させるもの。

代表的なWebサーバ（httpd）であるApacheは、mod_ssl モジュールを利用することでSSL/TLSに対応させる。このモジュールをロード（有効化）することで、HTTPSサービスの提供が可能となる。 Apacheの基本的な動作設定は/etc/httpd/conf/httpd.confにて行うが、SSL/TLSの設定は、デフォルトで用意されている/etc/httpd/conf.d/ssl.confに記述するのが一般的となる。

サーバー認証の設定(Apache)

サーバー認証とは、クライアント（ブラウザ）に対して、アクセスしているWebサイトが本物であることを証明するプロセスのこと。
Apacheでは、証明書ファイルと秘密鍵を指定することでこれを実現する。

以下は、HTTPSを有効化し、証明書と鍵を指定するための設定例。

<VirtualHost 192.168.0.1:443>
    ServerName test-server1.com
    DOCUMENTRoot /var/www/html/ssl_test-server1

    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!SHA1

    SSLCertificateFile /etc/pki/tls/certs/server1_cert.pem
    SSLCertificateKeyFile /etc/pki/tls/private/server1_key.pem
    SSLCertificateChainFile /etc/pki/tls/certs/cacert.pem

    ErrorLog logs/ssl_test-server1_error_log
    CustomLog logs/ssl_test-server1_access_log combined env=!no_log
</VirtualHost>

拡張機能の利用

SNI

SNI(Server Name Indication)は1つのWebサーバで複数のドメインのSSL/TLS証明書を利用できる仕組み。 名前ベースのVirtualHostであってもSSLに対応できるようにしたSSL/TLSの拡張仕様ともいえる。

SNIでは、コネクション確立時にクライアントからサーバへアクセスしたいホスト名を渡すことにより、適切なサーバ証明書を返すことができる仕様とした。 これにより、コネクション前にホスト名を確認することが可能となり、名前ベースの仮想ホストを使用可能となった。

HSTS

HSTS(HTTP Strict Transport Security)はWebセキュリティの仕組みの一つでウェブサイトがHTTPSを使用することを強制するための仕組みのこと。
HSTSはウェブブラウザに対して、特定の期間内でHTTPSを使用するように指示する。

HSTSの主な目的はMITM攻撃を防ぐことにある。 通常、攻撃者はHTTP通信を盗聴し、変更することができるが、HTTPSを使用すると通信が暗号化され、改ざんや盗聴が難しくなる。 HSTSは、ウェブサイトがHTTPSを使用するように強制し、ユーザーが暗号化された通信を確実に得ることを支援する。 クライアントが一度HTTPSでアクセスしたサイトがHSTSを強制するようクライアントに指示した場合、以後一定の有効期間内はクライアント側からはHTTPSで通信を行うようになる。

また、初回のHTTPSアクセスまでの脅威に対応するため、予め「このドメインはHSTSに対応している」という情報をブラウザ側に知らせておく「プリロードHSTS（Preload HSTS）」という仕組みも提唱されてきている。

<VirtualHost 192.168.0.1:443>
    ServerName test-server1.com
    DOCUMENTRoot /var/www/html/ssl_test-server1

    :
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

6.2.3. 高度なセキュリティ機能とクライアント認証

クライアント（ユーザー）認証

SSL/TLSを利用したApacheでは、クライアントの証明書を使ってアクセス制御を行うことができる。 この仕組みを使うことで許可されたユーザのみにWebサーバへのアクセスを可能にできる。

「ssl.conf」では設定項目SSLVerifyClientにより、クライアントに対して証明書を提示させるよう指定することができる。

<VirtualHost 192.168.0.1:443>
    :
    SSLCACerificateFile /etc/pki/tls/certs/cacert.pem
    SSLCARevocationFile /etc/pki/tls/certs.crl.pem
    SSLVerifyClient require
    SSLVerifyDepth 1
    :
</VirtualHost>

証明書の失効確認

OCSP

OCSPはクライアントがOCSPサーバ（OCSPレスポンダ）へ問い合わせを行い、証明書の失効確認を行うためのプロトコル。

しかし、レスポンダとの通信次第で問い合わせに遅延が発生し、確認手続きが失敗するなどの弊害もあった。これに対応する方法としてOCSPを拡張したものが、OCSP stapling（OCSPステープリング）となる。 クライアントが行っていたOCSPレスポンダへの問い合わせを証明書提供側のサーバが行うことにより、クライアントが確認手続きで失敗するリスクをなくす。

OCSP Staplingの設定

OCSP Staplingを提供するようにmod_sslを設定（SSLUseStapling）。
「ssl.conf」では設定項目SSLUseStaplingにて有効化するか否かを選択できる。

#OCSP Stapling: 
SSLUseStapling On 
SSLStaplingResponderTimeiut 5
SSLStaplingReturnResponseErrors off
SSLStaplingCache "shmcb:logs/ssl_stapling(32 768)"

6.2.4. OpenSSLを利用したテストと検証

OpenSSLコマンドの利用

opensslではSSL/TLSクライアント/Webサーバとしててテスト動作可能。

• openssl s_serverコマンドでSSL/TLSのWebサーバとして動作
• openssl s_clientコマンドでSSL/TLSクライアントとして動作

# 証明書/秘密鍵/中間CA証明書を指定しWebサーバとして動作
openssl s_server -cert newcert.pem -key newkey.pem -XAfile cacert.pem -WWW

# SSL/TLSで192.168.0.1の1443ポートへ接続する
openssl s_client -connect 192.168.0.1:1443 -CAfile cacert.pem

暗号スイートの検証

CipherSuite

CipherSuiteは暗号化の組み合わせのことを指す。 SSL/TLSで使用できる暗号化には様々な種類があり、暗号といっても、目的によって使用できる暗号技術が異なる。

SSL/TLSの動作は複数の暗号技術の組み合わせで成り立っており、通信の開始から終了までの間に数種類の暗号技術を使用する。 この組み合わせは暗号スイートと呼ばれ、OpenSSLではopenssl chipersコマンドで使用できる暗号スイートを確認できる。