SSL通信の必要性について
1. はじめに
SSLについて、「通信暗号化のために必要」「証明書配置により信頼されたサイトであることを保証」などの基本的なことは分かっているが、昨今話題となる暗号強度の問題でTSL化が必須だとか、SHA1は脆弱だといった話に対して何がどう問題なのか詳しく分かっていないことが多いなと思い、SSL通信について勉強して、情報をまとめてみた。
2. SSL通信の仕組み
SSL通信は以下のフローで行われます。
－－前処理－－
- クライアント －－－ SSL通信要求 －－＞ サーバ
- クライアント ＜－－ サーバ証明書（公開鍵）送付 －－－ サーバ
- クライアント －－－ サーバ証明書（公開鍵）で暗号化した共通鍵を送付 －－＞ サーバ
- サーバは暗号化された共通鍵を秘密鍵で復号化
－－暗号通信－－
5. クライアント －－－ 共通鍵で暗号化したリクエストデータを送付 －－＞ サーバ
6. サーバは4で受け取った共通鍵で復号化
7. クライアント －－－ 共通鍵で暗号化したレスポンスデータを送付 －－＞ サーバ
2.1. SSL通信詳細
1のSSL通信要求ではクライアント（ブラウザ）は処理可能な暗号スイートの選択肢をサーバに送付し、サーバ側はその中から好ましいもの（セキュリティレベルが高いもの）を選択し、暗号スイートを確定する。
暗号スイートでは以下を指定する
| 説明 | 名称 | 参考値 |
|---|---|---|
| プロトコルバージョン | SSLLv3 | |
| 鍵交換に使われる暗号化アルゴリズム | Kx (Key Exchange) | RSA |
| 認証に使われる暗号化アルゴリズム | Au (Authentication) | RSA |
| アプリケーション層の暗号化に使われる暗号化アルゴリズム | Enc (Encryption) | AES(128) |
| メッセージの検証に使われるハッシュアルゴリズム | Mac(Message Authentication Code) | SHA1 |
| Kx / Au / Enc / Macの組み合わせで暗号化 |
SSL通信では上記指定された暗号スイートに基づき暗号化される。「SSLLv3にはPOODL攻撃の脆弱性がある。」など指定する暗号スイートによって脆弱性が存在する状態となるため、脆弱性を伴う暗号スイートはサーバ側で許容しない設定としておく必要がある。（SSLアクセラレーションを行うノードで設定する）
最新のブラウザでアクセスされれば、TLS1.xでの通信要求がされますが、古いブラウザやフューチャーフォンなどはTLSでの通信が実装されていないものもあるため、サーバ側でSSL通信を禁止するとアクセス不能となる。
対処は２パターンある。
- サーバ側ではSSLLv3も許容する。この場合、最新ブラウザでアクセスすればTLSが利用されるが、TLSが使用できないクライアントアクセスではSSLLv3が使用される。SSLLv3は脆弱性を含むプロトコルだが、それを前提として使用してもらう。
- サーバ側でSSLLv3を禁止する。この場合、TLSが使用できないクライアントからのHTTPSでのアクセスはエラーとなる。
2の場合、一部の利用環境が使用不可となるため、サービスとして許容されるかという議論となる。セキュアでないアクセスが許容できるのであればHTTPでアクセスしてもらうという選択もあるが、それなら1のパターンで脆弱性を含むプロトコルを利用するという整理でもよいのではないかとも思う。
少なくともアクセスしている利用者以外の個人情報を含む通信の場合、自己責任ではすまないため利用禁止とするしかないが、利用者自身の個人情報や機密性のない情報に対してのアクセスであれば選択の余地はあるのかもしれない。
2.2. SSL証明書の生成
SSL証明書を作成する場合、サーバ管理者は以下の情報を入力して生成されたCSRを認証局に送付し、SSL証明書（公開鍵）とそれに対応する秘密鍵を生成してもらう。
| フィールド | 説明 | 例 |
|---|---|---|
| Country Name | 国を示す2文字のISO略語 | JP |
| State or Province Name | 組織が置かれている都道府県 | Tokyo |
| Locality Name | 組織が置かれている市区町村 | Koto-Ku |
| Organization Name | 組織の名称 | Nttdata |
| Organization Unit Name | 組織での部署名 | Digital Business Division |
| Common Name | WebサーバのFQDN | www.nttdata.co.jp |
認証局では、申請者がCSRの通りの企業に所属し、Common Nameで定義されたドメインを所有しているかの調査を行い、問題が無ければSSL証明書の払い出しを行う。
証明書には3種類の認証レベルが存在する。
| 証明書種別 | 説明 | 認証レベル | 挙動 | 想定するWebサイトの目的 |
|---|---|---|---|---|
| ドメイン認証（DV : Domain Validation）型SSLサーバ証明書 | Common Nameのドメイン使用権の有無のみを認証 | ★ | 鍵マーク | 内部向けWebサイト（イントラネット、グループウェア） |
| 企業認証（OV : Organization Validation）型SSLサーバ証明書 | ドメイン使用権に加え、ウェブサイト運営団体の実在性を認証 | ★★ | 鍵マーク | 外部向けWebサイト（問合せページ） |
| EV（Extended Validation）SSL証明書 | ドメイン使用権に加え、EVガイドラインに基づきウェブサイト運営団体の実在性を厳格に認証 | ★★★ | 鍵マーク＋緑バーと社名表示 | 重要な外部向けWebサイト（企業Webサイト、クレジットカード番号を入力するECサイト） |
DVとOVはブラウザからの表示上は同じ鍵マークのみで挙動に違いはないが、証明書の情報を見るとサブジェクト内に含まれる情報がドメインのみか企業情報も含まれるかの差があることが分かる。
証明書としての信頼性はOVのほうが高いことは分かるが、証明書の中身までみる利用者はほとんどいないので、意味があるのかいまいちよく分からない。
認証レベルが上がるため当然DVよりOVのほうが高い。DVについてはLet's Encryptのように無料で提供されているものもあり、OVである必要がないのであればこれでもよい気もする。
Let's Encrypt
https://letsencrypt.jp/
どうなんでしょうか？
2.3. SSL証明書のハッシュアルゴリズムの脆弱性
近年まで証明書ハッシュ化アルゴリズムとしてsha1が使われていたが、マシン性能の向上等により安全性が低下してきており、SSL証明書作成時の署名ハッシュアルゴリズムをsha2にする必要がある。
SSL証明書の署名アルゴリズムはCSRを生成する時に指定する。
2.4. 認証局で証明書を取得する必要性について
SSL証明書は自分でも作成することが可能（自己証明書）だが、なぜお金を払って認証局で証明書を取得する必要があるのか？
その理由はブラウザがSSLアクセスした場合に、証明書からそのサイトが信頼できるかどうか判断する手順から分かる。
ブラウザは信頼する証明書を登録することで、その証明書でのアクセスがあった場合に信頼できると判断している。つまり登録されていない証明書の場合、鍵マークは表示されず、証明書が信頼されていないというメッセージが表示されてしまう。（メッセージはブラウザによって異なる）
ブラウザにその証明書を信頼するように設定すればメッセージは表示されなくなるが、インターネットに公開するサイトで全てのユーザに証明書の登録をしてもらうのは現実的ではないため、ブラウザは初期インストール時に世の中的に信頼されている証明書をルート証明書として登録しておき、そのルート証明書の下位に属する証明書についても信頼するようになっている。
ルート証明書に紐付く証明書の発行はルート証明書を管理している認証極でしか行えないため、認証局で証明書を取得刷る必要がある。
3. SSL通信によって防げる攻撃
SSL通信の考え方は2で記載した通りですが、それによってどのような攻撃が防げるのか
盗聴
通信を暗号化するため盗聴を防止できる。盗聴防止のためには暗号スイート（プロトコルや暗号化方式）として適切なものを選択する必要がある。
なりすまし
クライアント側のDNSサーバが攻撃され、サービス提供しているドメインのキャッシュが改ざんされた場合、誘導されたサイトの管理者はサービス提供しているドメインの証明書の取得ができないため、証明書エラーとなり、なりすましを防止できる。
システムの管理者として必要となる最低限の知識としてこのくらいおさえておく必要があるかと思います。