最近、SSLとTLSに関連する重大な脆弱性がいくつか発見されています。多くのユーザは、システム上で使用されているSSLとTLSのバージョンを確認する方法を知りません。今日は、TLS(Transport Layer Security)とSSL(Secure Sockets Layer)の基本的な仕組みについて説明します。
SSLはTLSの前身です。いずれもX.509証明書を使用し、非対称暗号化と呼ばれます。今日は、非対称暗号化と対称暗号化について説明します。
対称暗号化は、暗号化方式としては最も古い方法であり、暗号化と復号化に同じキーを使用します。たとえば、アルファベットの文字を対称キーに使い、位置をいくつか移動するだけといったシンプルな方法もあります。では、非常にシンプルな対称暗号化の例を紹介しましょう。「hey the redcoats are coming」というメッセージを送信したい場合、「mjceyljewjihtfyxefwjehtrnsl」というメッセージを送信します。このメッセージは、「5」というキーを使って復号化できます。「5」は、「アルファベットの文字を5つずらす」ことを意味します。
つまり、AはF、BはG、CはH、となります。アルファベットの最後に空白文字を追加すれば、暗号文がさらに複雑になります。YはDではなくCになり、空白文字がEになります。Eをすべて空白文字にすると、このようになります。
mjceyljewjihtfyxefwjehtrnsl
mjc ylj wjihtfyx fwj htrnsl
hey the redcoats are coming
アルファベットの変換(下線は空白文字)
対称暗号化の問題点は、メッセージを復号化するにはキーを送信しなければならない点です。キーを盗めば、誰でもメッセージを復号化できてしまいます。
このリスクを軽減する方法として考案されたのが、非対象暗号化です。非対象暗号化は、公開キーとも呼ばれます。この暗号方式では、平文の暗号化にキーを2つ使用します。1つは公開するキーであり、もう1つは秘密のキーです。公開キーは、テキストの暗号化に使用します。そして、公開キーに対応する秘密キーがないと、復号化できません。
非対称暗号化では、送信者と受信者が公開キーを交換します。暗号化には、相手の公開キーを使用し、復号化には自分の秘密キーを使用します。
この方式では、復号化に使用するキーはすでに手元にあるので、キーを交換する必要がありません。自分が送った公開キーで暗号化されたメッセージを自分の秘密キーで復号化するので、メッセージを他人に読まれてしまう危険はありません。また、秘密キーでメッセージを暗号化し、公開キーで復号化することも可能です。このように、暗号化が一方向で行われることから、「非対称」という名前が付けられています。
現在、コンピュータでは強力なブルートフォース攻撃が可能になっているので、かなり高度なアルゴリズムを使って生成された複雑なキーが使用されています。
SSLとTLSは、複数の暗号化方式(アルゴリズム)を使って公開キーと秘密キーのペアを生成できます。RC4は弱い暗号方式の1つであり、有効なデータ保護方法ではありません。これが、SSL v3.0をお勧めしない理由です。RC4-SHAは、SSL v.3.0スイートで使用できる最も高度な暗号化方式です。
これに対して、AESは強力な暗号方式であり、TLS v1.0、TLSv.1.1/v.1.2で使用できます。使用可能な暗号方式とその強度をチェックするには、Linuxコマンドラインで次のコマンドを実行します。
#openssl ciphers -v 'ALL:!ADH:@STRENGTH'
SSLとTLSの解説 Frank Dreamer
2015年07月22日
最近、SSLとTLSに関連する重大な脆弱性がいくつか発見されています。多くのユーザは、システム上で使用されているSSLとTLSのバージョンを確認する方法を知りません。今日は、TLS(Transport Layer Security)とSSL(Secure Sockets Layer)の基本的な仕組みについて説明します。
SSLはTLSの前身です。いずれもX.509証明書を使用し、非対称暗号化と呼ばれます。今日は、非対称暗号化と対称暗号化について説明します。
対称暗号化は、暗号化方式としては最も古い方法であり、暗号化と復号化に同じキーを使用します。たとえば、アルファベットの文字を対称キーに使い、位置をいくつか移動するだけといったシンプルな方法もあります。では、非常にシンプルな対称暗号化の例を紹介しましょう。「hey the redcoats are coming」というメッセージを送信したい場合、「mjceyljewjihtfyxefwjehtrnsl」というメッセージを送信します。このメッセージは、「5」というキーを使って復号化できます。「5」は、「アルファベットの文字を5つずらす」ことを意味します。
つまり、AはF、BはG、CはH、となります。アルファベットの最後に空白文字を追加すれば、暗号文がさらに複雑になります。YはDではなくCになり、空白文字がEになります。Eをすべて空白文字にすると、このようになります。
mjceyljewjihtfyxefwjehtrnsl
mjc ylj wjihtfyx fwj htrnsl
hey the redcoats are coming
アルファベットの変換(下線は空白文字)
対称暗号化の問題点は、メッセージを復号化するにはキーを送信しなければならない点です。キーを盗めば、誰でもメッセージを復号化できてしまいます。
このリスクを軽減する方法として考案されたのが、非対象暗号化です。非対象暗号化は、公開キーとも呼ばれます。この暗号方式では、平文の暗号化にキーを2つ使用します。1つは公開するキーであり、もう1つは秘密のキーです。公開キーは、テキストの暗号化に使用します。そして、公開キーに対応する秘密キーがないと、復号化できません。
非対称暗号化では、送信者と受信者が公開キーを交換します。暗号化には、相手の公開キーを使用し、復号化には自分の秘密キーを使用します。
この方式では、復号化に使用するキーはすでに手元にあるので、キーを交換する必要がありません。自分が送った公開キーで暗号化されたメッセージを自分の秘密キーで復号化するので、メッセージを他人に読まれてしまう危険はありません。また、秘密キーでメッセージを暗号化し、公開キーで復号化することも可能です。このように、暗号化が一方向で行われることから、「非対称」という名前が付けられています。
現在、コンピュータでは強力なブルートフォース攻撃が可能になっているので、かなり高度なアルゴリズムを使って生成された複雑なキーが使用されています。
SSLとTLSは、複数の暗号化方式(アルゴリズム)を使って公開キーと秘密キーのペアを生成できます。RC4は弱い暗号方式の1つであり、有効なデータ保護方法ではありません。これが、SSL v3.0をお勧めしない理由です。RC4-SHAは、SSL v.3.0スイートで使用できる最も高度な暗号化方式です。
これに対して、AESは強力な暗号方式であり、TLS v1.0、TLSv.1.1/v.1.2で使用できます。使用可能な暗号方式とその強度をチェックするには、Linuxコマンドラインで次のコマンドを実行します。
openssl ciphers -v 'ALL:!ADH:@STRENGTH'
SSLとTLSのバージョンは次の順序で進化してきました。
• SSL v. 1.0
• SSL v. 2.0
• SSL v. 3.0
• TLS v. 1.0
• TLS v. 1.1
• TLS v. 1.2
• TLS v. 1.3(現在ドラフト版)
バージョンが新しくなるほど暗号化方式も新しくなり、旧バージョンでは使用できなかったキーサイズが使用できるようになっています。SSLとTLSでは、複数のバージョンで同じ暗号化方式が提供されています。
SSL証明書は、メッセージの暗号化から信頼の確立まで、さまざまな用途に使用されます。
上記で説明したように、SSL/TLSとは、公開キーまたは秘密キーのいずれかでメッセージを暗号化し、もう一方のキーを使って復号化するシンプルな方法です。
Webサイトが信頼できるかどうかを判断する方法には、証明書が使用されます。信頼関係の確立には、信頼のチェーンを構築する必要があり、それを担当するのが認証局(CA)です。認証局は、ネットワーク上のサーバまたは第三者CAです。ドメインCAが発行した証明書の信頼性は、ローカルドメイン内のみで保証されます。外部に向けたWebインターフェイスの信頼を保証するには、WWWドメインを認証する認定を受けた第三者CAが発行した証明書が必要になります。CAはそれぞれが、その正当性を証明する「ルート証明書」を持っています。信頼関係の確立では、CAのルート証明書が拠り所となります。ルート証明書もとに中間CAルート証明書(ICA)が作成され、これによって信頼の階層構造が構築されます。このチェーンの末端にあるのが、「署名済み証明書」です。この証明書により、Web上でHTTPを処理するデバイスが識別されます。
以下は、.pem形式に含まれるチェーンバンドル全体を示しています。信頼のチェーンは、チェーンバンドルの下から上へとつながっています。
SSLとTLSでは、暗号化スイートが日和見的に選択されます。つまり、接続の相手側で使用できる暗号化方式のうち、強度が最も高いものが使用されます。ネットワーク通信で弱い暗号化方式が使用されている場合は、接続の両端で使用できる暗号化方式を確認してください。
SSL接続の確認(HTTPS):
#openssl s_client -connect :443 -showcerts
TLSを使用するメールサーバの確認:
#openssl s_client -connect :25 -starttls smtp -showcerts
バラクーダネットワークスのお客様の中には、強度の高い暗号方式が設定されているにもかかわらず、実際には弱い方式が使用されていたケースもあります。このような場合には、接続の両端のインターフェイスをチェックしてください。つまり、自分のインターフェイス(または顧客のインターフェイス)をチェックし、さらに相手のインターフェイスをチェックする必要があります。SSLとTLSは日和見的な暗号方式なので、通信の両端で使用できる方式のうち、強度が最も高いものを採用します。
たとえば、自分のインターフェイスではTLS v.1.2のAES256-SHAが使用可能であっても、相手側はSSL v3.0のRC4-SHAにしか対応していない可能性もあります。この場合、両端で最も強度の高い暗号方式を使用して通信が行われます。
以下に、SSLインターフェイスのopensslクエリの例を示します。
openssl s_client -connect 24.97.125.194:443 -showcerts
CONNECTED(00000003)
depth=0 /C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
verify return:1
Certificate chain
0 s:/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
i:/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
-----BEGIN CERTIFICATE-----
MIICjDCCAfWgAwIBAgIEU9cMJDANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJV
(certificate abbreviated for space constraints)
-----END CERTIFICATE-----
Server certificate
subject=/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
issuer=/C=US/O=Barracuda Networks, Inc/CN=Barracuda Firewall X400/ST=CA/L=Campbell
No client certificate CA names sent
SSL handshake has read 828 bytes and written 355 bytes
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 4E36015736D7DF91A4459D4C8E8D31D05B6D5BD5318185024026AFC5A643709F
Session-ID-ctx:
Master-Key: A6579CBB82C2B62626FCF82B7A15781C17887BF74B4AB4796B87FD24C25F59009CEFCE574868BB8D67E2BFBD083F2146
Key-Arg : None
Krb5 Principal: None
Start Time: 1415288412
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
上記のSSL証明書はTLS v.1を使用し、最も高い暗号強度はAES256-SHAです。この証明書は、SSL v.3で対応できる暗号化方式とのネゴシエーションが可能です。自己署名証明書であり、公開キーは1024ビットです。
バラクーダネットワークスのソリューションのSSLとTLSに関するご質問は、サポート部門にお電話またはサポートチケットでお問い合わせください。
ご質問をお待ちしております。
※本内容はBarracuda Product Blog 2015年7月9日SSL and TLS Explainedを翻訳したものです。
Frank Dreamer
本稿は、バラクーダネットワークスのWebサイトに掲載されている『バラクーダラボ』7月22日付の記事の転載です。