今回はあえて「CentOS7」ではなく「CentOS6」を使って「自己証明書（オレオレ証明書）」を作成し、HTTPS でアクセスできるようにサーバーを構築する手順を解説します。
※自己証明書（オレオレ証明書）とは、ベリサインやセコムなどのパブリック認証局（CA）が発行した証明書ではなく、自分で発行した証明書のことを言います。
通常ならより新しく、セキュリティアップデートを重ねている「CentOS7」を使うのが当然なのですが、アプリなど様々な環境に縛られて過去の OS を使わざるを得ない場合もあります。
そこは柔軟に対応しつつもセキュリティ等はしっかりと設定していきたいところです。
今回やりたいこと
今回は以下の環境を構築して実際に TLS 1.2 で暗号化されて通信されているか検証します。
- CentOS 6 で Webサーバー構築
- Webサーバーは「Apache」を利用する
- Webアクセスは「https」経由（SSLを使用する）
- 証明書は自分で作成する（オレオレ証明書）
- SSLのバージョン（TLSのバージョン）は、TLS1.2
- TLS 1.2 は OpenSSL で暗号化する
- 実際に TLS 1.2 で通信されているか tcpdump で確認
HTTPS 環境の設計
最初に設計をします。
バージョンは CentOS 6 の最新版（6.9）とします。
- OS：CentOS6（6.9）
- httpd（Apache）：2.2
- SSL証明書：自己証明書（オレオレ証明書）
- アクセス：https://192.168.1.11
環境
すでに VMware vSphere ESXi Hypervisor 6.5 上に「CentOS 6.9」の仮想マシンがあるので、今回はこの仮想マシンを使って手順と動作を検証します。
VMware 関連の手順については以下の記事を参照してください。
VMware ESXi 上で仮想マシンを構築する手順
iptables の設定
iptables はデフォルトで「自動起動（on）」なので特に何も設定変更をしなければ起動しています。
今回は作業時に邪魔にならないように、HTTPS でアクセス確認ができるまで停止しておきます。
|
[root@cent06 ~]# chkconfig iptables off ← 一旦 iptables の自動起動を停止します。 |
selinux の設定
selinux もデフォルトで「enforcing」の設定なので変更しなければ有効になっています。
selinux も作業時に邪魔にならないように、「disable」にしておきます。
|
[root@cent06 conf.d]# vi /etc/selinux/config ← config ファイルを開いて編集します。
# This file controls the state of SELinux on the system. |
設定を反映させるために再起動します。
|
[root@cent06 .ssh]# reboot |
HTTPS 化にするために導入するパッケージ一覧
以下のパッケージを導入します。
- httpd
- openssl
- mod_ssl
※すでに導入している場合はアップデートをして最新の状態にします。（古い状態のままだと脆弱性が出る可能性があります）
httpd のバージョン確認とアップデート
現環境のチェックからします。
httpd のバージョンをチェックします。
|
# rpm -qa | grep httpd |
パッケージをアップデートできるか確認します。
|
# yum update httpd 依存性を解決しました ======================================================================================================== トランザクションの要約 総ダウンロード容量: 919 k 更新: 依存性を更新しました: 完了しました! |
mod_ssl のインストールとバージョン確認
mod_ssl のインストール確認と、インストールされていたらバージョンアップ確認をします。
「mod_ssl」と「OpenSSL」を利用することで「Apache」に「SSL 機能」が追加されます。
|
[root@cent06 conf.d]# rpm -qa | grep mod_ssl [root@cent06 conf.d]# yum install mod_ssl ← 「mod_ssl」をインストールします。 依存性を解決しました ======================================================================================================== トランザクションの要約 総ダウンロード容量: 98 k インストール: 完了しました! |
mod_ssl とは一体何か？
簡潔にまとめると
- Apache で SSL 暗号化通信をするために必要（他には OpenSSL も必要）
- yum で簡単にインストールができる
- SSL v3 と TLS 1.x をサポートしている（SSL v2 はサポートしていない）
です。
OpenSSLのバージョンとアップデート確認
今回は「自己証明書（オレオレ証明書）」を作成するため、OpenSSL も利用するので OpenSSL のバージョンとアップデート確認をします。
|
# rpm -qa | grep openssl ← すでにインストールされているか確認します。 # openssl version ← openssl コマンドで OpenSSL のバージョンを確認します。 # yum update openssl ← OpenSSL がアップデート可能か確認します。 |
OpenSSLで何ができるのか？
ここで「OpenSSL」ついて解説します。
「OpenSSL」はフリーの暗号化モジュールです。
SSL/TLS での通信の暗号化を実装します。
※「実装する」とは「SSL/TLS」などの規格（概念）を実現化することを言います。この場合は「SLL/TLS」の規格を「OpenSSL」で実装することによりSSL での通信暗号化が実現します。
今回 OpenSSL を利用してプロトコル「TSL 1.2」での暗号化通信を検証しようとしていますが、プロトコル「TSL 1.2」と言っても1種類のアルゴリズムだけで実現しているわけではありません。
「コンピュータA」から「コンピュータB」に「データ」を送信するために、暗号化通信を達成するための多数のアルゴリズムが混在しています。
例えば現在 CentOS 6 で利用できる多数のアルゴリズムの組み合わせを確認するとこんな感じになっています。
|
[test@cent06 ~]$ openssl ciphers -v |
気が遠くなるほどの組み合わせですが、実際に利用するのは（利用できるのは）標準的なごく一部のみですのですべてを覚える必要はありません。
OpenSSLがサポートしているプロトコル
OpenSSLは以下のプロトコルバージョンをサポートしています。
- SSL 2.0（1994年リリース）
- SSL 3.0（1995年リリース）
- TLS 1.0（1999年リリース）
- TLS 1.1（2006年リリース）
- TLS 1.2（2008年リリース）
※TLS 1.3 はドラフト策定中です。（2017年現在）TLS 1.3 はかなり大幅な変更になるので「TLS 1.3」ではなく「TSL 2.0」にしたらどうかという案もあるようです。
OpenSSLがサポートしている通信の暗号方式
「コンピュータA」と「コンピュータB」が通信する場合、OpenSSL は以下の暗号方式で「データ」を暗号することができます。
こんがらがってしまうかもしれませんが、以下は「データ」を暗号化する方式です。
- Blowfish ← ブロック暗号。ライセンスフリー。
- Camellia ← 2000年に NTT と三菱電機が開発した。ブロック暗号。カメリアは植物の名前から取った。
- DES（Data Encryption Standard） ← アメリカの旧国家暗号規格。現在は3DES（トリプルDES）が利用されている。
- 3DES ← トリプル DES。
- RC2（Rivest Cipher 2） ← 1987年にロナルド・リベストが開発。ブロック暗号。
- RC4（Rivest Cipher 4） ← 1987年にロナルド・リベストが開発。ストリーム暗号。中間者攻撃で脆弱性あり。Microsoft社は非推奨。
- RC5（Rivest Cipher 5） ← 1994年にロナルド・リベストが開発。
- SEED ← ブロック暗号。Feistel構造を利用している。
- IDEA（International Data Encryption Algorithm） ← ブロック暗号。
- AES（Advanced Encryption Standart） ← DESの次のアメリカの国家暗号規格として公募され Rijndael （ラインダール）が採用された。
OpenSSLがサポートしているハッシュ方式（ハッシュ関数）
これらのハッシュ方式（ハッシュ関数）は「MAC」の部分で利用されます。
- MD5
- MD2
- SHA-1
- SHA-2
- MDC-2
OpenSSLがサポートしている公開鍵暗号方式（暗号化アルゴリズム）
- RSA暗号 ← もっとも一般的。「Ron Rivest」「Adi Shamir」「Leonard Adleman」によって開発。RSA秘密鍵の拡張子は「.key」や「.pem」。「素因数分解」。
- DSA ← 安全性が証明されていないためあまり利用されていない。
- Diffie-Hellman鍵共有（DH鍵交換、Diffie-Hellman key exchange / Digital Signature Standard、電子署名標準）
暗号化方式とハッシュ方式は何が違うのか？
ハッシュ化は暗号化とは違います。
暗号化はデータを隠します。
暗号化の場合は、復号化するための「鍵（キー）（例えば文字を「あいうえお」順に１つ進めてくださいなど）」があれば復号化してオリジナルのデータを確認できます。
ハッシュ化は「基本情報処理」を勉強した方なら聞いたことがあるかもしれません。
ハッシュは「不可逆性（ふかぎゃくせい）」といって、「test」というデータから「$6$mRCuydnLnCIcQhec$c4eLUP0N.Jcm08qOdwWHt0BIkEzzAoMCL8Sd3INmpWOKkn66Vl11dNQu3oP8Ub81JPJHisExhIYk34EDmu/d6/」というハッシュ値は作れますが、「$6$mRCuydnLnCIcQhec$c4eLUP0N.Jcm08qOdwWHt0BIkEzzAoMCL8Sd3INmpWOKkn66Vl11dNQu3oP8Ub81JPJHisExhIYk34EDmu/d6/」から「test」というデータは作れない（もしくはほとんど不可能）ことを言います。
たとえば、CentOS 6 上で、grub-crypt コマンドで「test」というパスワードをハッシュ化してみます。
|
[test@cent06 ~]$ grub-crypt –sha-512 |
ということは、「test」というデータは毎回「$6$mRCuydnLnCIcQhec$c4eLUP0N.Jcm08qOdwWHt0BIkEzzAoMCL8Sd3INmpWOKkn66Vl11dNQu3oP8Ub81JPJHisExhIYk34EDmu/d6/」になるのではないでしょうか？
では、もう一度「test」のハッシュ値を作ってみます。
|
[test@cent06 ~]$ grub-crypt –sha-512 |
同じ「test」なのにハッシュ値は異なる、しかしこのハッシュ値は「test」というデータとして利用できます。
一見すると「ハッシュ化も単なる暗号化じゃないの？」と思ってしまいますが、このハッシュ値の何がいいのかというと、データが改ざんされたときにすぐ気が付くということです。
例えば「test」というデータを送りたいとして、送信する途中で改ざんできる悪意を持ったクラッカーがいるとします。
途中で「test」を「password」に変更した場合 → 受信者は気が付きません。「password」だと勘違いします。
しかし「$6$9ZJTQzaOxPdj./HB$LrOviT7xdihtL8cn69HfhGRkbwthJZND60kUO1qdC1Cdp5z1pfY7aoCAZi2E53EEDooUqgMW0f9EMBp7AVbK20」を送って、途中でこの中も1字を改ざんした場合、復号化する時にエラーになり、改ざんされたことが分かります。
たとえハッシュデータが盗まれたとして「改ざんができない」もしくは「改ざんしたらすぐにバレる」のです。
「じゃあ、ハッシュ化された $6$9ZJTQzaOx～ のデータを復号して改ざんすればいいじゃないか」と思うかもしれませんが、そもそも「$6$9ZJTQzaOxPdj./HB$Lr～」のデータを「test」だと解読するために膨大な時間が掛かります。
このハッシュ化の機能は、後程出てきますが MAC の部分で利用します。
TLS1.2 と TLS1.3 で何が違うのか？
まだ実際に使ったことはありませんが、通信の「スピード」と「セキュリティ」が向上したと言われています。
今後レンタルサーバーでも「TLS 1.3」がスタンダードになるでしょう。
ユーザーにとっても「スピード」と「セキュリティ」が向上するのは大歓迎です。
- 古いアルゴリズムはすべて廃止・却下、AEAD（Authenticated Encryption with Associated Data）が残る
- ハンドシェイクの往復回数の削減
証明書を作成する流れ
これから CentOS 6 上で環境を構築しますが以下の手順で「鍵」「CSR」「証明書（オレオレ証明書）」を作成します。
- 秘密鍵（server.key）の作成
- CSR（server.csr）の作成
- 自己証明書（オレオレ証明書）（server.crt）の作成
※便宜上分かりやすくするために「server.key」「server.csr」「server.crt」で作成していますが、ファイル名は何でも構いません。
自身の環境で分かりやすくするために「host名.key」のような形式でも問題ありません。
※気を付ける部分としては、秘密鍵は重要なファイルなので（外部に漏れたらクラッキングされる危険性があるので）、漏れないようにrootしかアクセスできないディレクトリに入れるなどのセキュリティ対策をしましょう。
上図のように「SSL」を理解するためのキーワードが３つあります。
暗号化・認証機関・電子署名です。
単純に言えば
- 暗号化 → server.key（秘密鍵）
- 認証機関 → server.csr（CSR）
- 電子署名 → server.crt（サーバー証明書）
と関連付けてもいいかもしれません。
公開鍵は不要
公開鍵暗号方式について勉強した方なら「公開鍵の作成はしなくてもいいの？」と思うかもしれませんが、SSL/TLS プロトコルを利用して HTTPS（Hypertext Transfer Protocol Secure）で通信をする場合は「公開鍵」は不要です。
ちなみに、Teraterm 等で SSH プロトコルで鍵認証で（パスワード認証ではなく）ログインをしたい場合は「秘密鍵」と「公開鍵」が必要になります。
「秘密鍵」「公開鍵」は「ssh-keygen -t rsa」コマンドで作成できます。
|
[root@cent06 ~]# ssh-keygen -t rsa
[root@cent06 ~]# cd .ssh/ |
鍵の設計
これから証明書を作成しますが、最初にどの鍵をどのアルゴリズムで作成するのか設計をします。
- 秘密鍵暗号化アルゴリズム：RSA
- 共通鍵暗号化アルゴリズム：トリプルDES
秘密鍵の作成
openssl コマンドで秘密鍵を作成します。
コマンドのオプションの解説
- genrsa ← RSA秘密鍵を生成します。
- -des3 ← 秘密鍵の暗号化アルゴリズムに「トリプル DES」を指定します。秘密鍵の暗号化は、共通鍵暗号化アルゴリズムを利用します。
- -out ← アウトプットするファイル名を指定します。
- 2048 ← 鍵の長さを 2048bit にします。
|
[root@cent06 ~]# cd /etc/httpd/conf [root@cent06 conf]# openssl genrsa -des3 -out server.key 2048 —–BEGIN RSA PRIVATE KEY—–
SpPBPehLo7cxx4jrLWXR7eGLikSY535MpPqcEa0WVOgIBUzj/erPiYFOOsBCQFhS [root@cent06 ssl]# |
鍵の内容を確認します。
|
[root@cent06 conf]# openssl rsa -text < server.key |
【補足】openssl コマンドで秘密鍵を作成する際に指定できる暗号化一覧
RSA 暗号方式の秘密鍵を作成するには「openssl genrsa」コマンドを実行します。
秘密鍵は作成する時に「暗号化」が可能です。
何を「暗号化」しているのか混乱してしまうかもしれませんが
- × 通信を暗号化
- ○ 秘密鍵を暗号化（他人に知られたくないから）
です。
暗号化された秘密鍵を読むためには「復号化」しなければいけません。
秘密鍵を「復号化」するために「パスフレーズ」が必要になります。
ただし、毎回秘密鍵を読む際に「パスフレーズ」を入力するのが面倒な時があります。
その場合は「パスフレーズ」なしで秘密鍵を作成することもできます。
その代りセキュリティが甘くなります。
「パスフレーズなし」のコマンド例
|
[root@cent06 test]# openssl genrsa 2048 > server_no_pass.key |
パスフレーズありのコマンド例
DES、DES3、AES128、AES192、AES256 が指定できます。
|
[root@cent06 test]# openssl genrsa -des3 -out server_des3.key 2048 [root@cent06 test]# openssl genrsa -des -out server_des.key 2048 [root@cent06 test]# openssl genrsa -aes128 -out server_aes128.key 2048
[root@cent06 test]# openssl genrsa -aes192 -out server_aes192.key 2048
[root@cent06 test]# openssl genrsa -aes256 -out server_aes256.key 2048 |
CSR（証明書署名要求）（server.csr）の作成
秘密鍵を作成したら、その秘密鍵を基に CSR を作成します。
CSR とは認証局に提出する証明書署名要求（Certificate Signing Request）のことを言います。
CSR（証明書署名要求、Certificate Signing Request）とは、ベリサインやジオトラストなどのパブリックな認証局に対して「公開鍵」に「電子署名」をしてもらうように依頼するためのメッセージです。
「電子署名」とは具体的には認証局だけが持つ認証局の「秘密鍵」で署名してもらうことです。
その結果、認証局が認証したことの証明になります。
「公開鍵」は作成していませんが、「openssl req」コマンドで秘密鍵を指定することで内部的に「公開鍵」が取り出されて、その「公開鍵」を基に「CSR」ファイルが生成されるので問題ありません。
オプションを解説します。
- req -new ← 新規 CSR を作成します。
- -key server.key ← 秘密鍵を指定します。
- -out server.csr ← CSR のファイル名を指定します。
|
[root@cent06 ssl]# openssl req -new -key server.key -out server.csr Please enter the following ‘extra’ attributes |
【補足】Signature Algorithm: sha1WithRSAEncryption の意味について
Signature Algorithm: sha1WithRSAEncryption の意味について解説します。
先ほども解説しましたが、「Signature Algorithm」にはどのようにして暗号化したのかの情報が表示されます。
sha1WithRSAEncryption から以下のことが分かります。
- 公開鍵暗号方式は「RSA」を採用している
- ハッシュ関数は「SHA-1」を利用している
自己証明書（オレオレ証明書）の作成
最後に「秘密鍵」と「CSR」より「サーバー証明書」を作成します。
※サーバー証明書は通常パブリックなCA機関（ベリサイン、ジオトラスト等）が発行していますが、ここでは自分でサーバー証明書を発行しています。
下図ではパブリックな認証局の「秘密鍵」で「サーバー証明書」を作成して送り返していますが、今回は自分で作った「秘密鍵」で「サーバー証明書」を作成するので「自己証明書（オレオレ証明書）」になります。
■オプション
- -in server.csr ← CSR ファイルを読み込みます。
- -out server.crt ← 「server.crt」というファイル名で証明書を作成します。
- -req -signkey server.key ← サーバーの秘密鍵（server.key）を認証に使う鍵（signkey）として署名します。
※本来ならこのサーバー証明書の作成は「ベリサイン」や「ジオトラスト」等のパブリックな認証局が行います。その際に「ベリサイン」や「ジオトラスト」が保有している「秘密鍵（server.key）」を利用して「server.crt」を作成するので、お金を出して買う価値があります。今回の場合は自分で作った「server.key」を使って「サーバー証明書」を作成しているので「自己証明書（オレオレ証明書）」になります。
|
[root@cent06 conf]# openssl x509 -in server.csr -out serverc.crt -req -signkey server.key |
HTTPS通信をするためのコンフィグファイルの設定
HTTPS通信をするためのコンフィルファイルの設定をします。
/etc/httpd/conf/httpd.conf ファイルの編集
「/etc/httpd/conf/httpd.conf」ファイルを設定します。
特に以下の項目を設定します。
- Listen
- ServerName
- DocumentRoot
|
[root@cent06 ~]# vi /etc/httpd/conf/httpd.conf
# Change this to Listen on specific IP addresses as shown below to
# If your host doesn’t have a registered DNS name, enter its IP address here.
# DocumentRoot: The directory out of which you will serve your
|
/etc/httpd/conf.d/ssl.conf ファイルの編集
mod_ssl パッケージをインストールするとデフォルトで「/etc/httpd/conf.d」ディレクトリ配下に「ssl.conf」ファイルが作成されます。
|
[root@cent06 ~]# cd /etc/httpd/conf.d
～省略～
# Server Certificate: # Server Private Key:
～省略～
[root@cent06 conf.d]# |
変更する箇所は以下の設定の部分のみです。
- SSLCertificateFile
- SSLCertificateKeyFile
※今回は中間証明書を利用しないので「SSLCertificateChainFile」の設定は不要です。
変更する前に、最初にバックアップを取ります。
|
[root@cent06 conf.d]# cp -ip ssl.conf ~/backup/ssl.conf_20170715
# Server Certificate: # Server Private Key: |
「ssl.conf」の編集が完了したらコンフィグファイルの構文チェックをします。
|
[root@cent06 conf]# httpd -t |
問題なさそうです。
構文が問題ないことを確認後、httpd を再起動します。
|
[root@cent06 .ssh]# /etc/init.d/httpd restart
Server cent06.localdomain:443 (RSA)
OK: Pass Phrase Dialog successful. |
※パスフレーズ付きの証明書を作成しているので、httpd を再起動するたびに「パスフレーズ」の入力を求められます。
【補足】httpd の再起動に失敗した場合の対応・調査手順
ここでは、SSL通信の設定をする中で起こり得るエラー集とその対応・調査手順を記載します。
エラーが発生しなければ一番いいのですが、どうしても複雑な作業を重ねるとエラーが出ることがあります。
そのエラー集を記載します。
httpd: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName
「Syntax OK」と表示されているので構文的には問題ないですが、FQDN（fully qualified domain name）で不整合があると言っています。
|
[root@cent06 conf.d]# httpd -t |
原因が FQDN の不整合ということで、対応方法としては、まず「/etc/hosts」ファイルに「IPアドレス」と「ホスト名」を追記します。
|
[root@cent06 sysconfig]# vi /etc/hosts |
再度構文のチェックをします。
|
[root@cent06 sysconfig]# httpd -t |
再度「httpd: Could not reliably determine the server’s fully qualified domain name, using cent06.localdomain for ServerName」のメッセージが表示されましたが、この原因は「/etc/hosts」だけでなく「/etc/httpd/conf/httpd.conf」にも「ServerName」の設定がされていないからでした。
「/etc/httpd/conf/httpd.conf」も設定をします。
|
[root@cent06 conf]# cp -ip httpd.conf ~/backup/httpd.conf_20170716 # ServerName gives the name and port that the server uses to identify itself. |
再度、構文チェックをします。
|
[root@cent06 conf]# httpd -t |
今度は問題なさそうです。
Init: Unable to read server certificate from file ～ の場合
httpd の再起動に失敗した際のエラーです。
|
[root@cent06 conf]# service httpd restart |
まずはログを確認してみます。
Apache（httpd）のログは「/var/log/httpd/error_log」に出力されています。
|
[root@cent06 conf]# less /var/log/httpd/error_log
[Sun Jul 16 00:59:48 2017] [notice] caught SIGTERM, shutting down ← httpd を停止しています。 |
「Init: Unable to read server certificate from file /etc/httpd/conf/server.csr」を翻訳すると「server.csr から“サーバー証明書”が読めない」と翻訳できます。
よくよくメッセージを確認すると「server.csr」となっています。
しかし本来はサーバー証明書（server.crt）を読み込む必要があります。
エラーの原因は「server.crt」ではなく「server.csr」になっていることでした。
サーバー証明書のファイル名とパスは「ssl.conf」で指定します。
「権限」や「文字コード」や「改行コード」が原因の場合
構文チェックでは問題ないですが、httpd の起動に失敗する場合で、「権限」や「文字コード」や「改行コード」でエラーになる場合があります。
|
[root@cent06 conf]# less /var/log/httpd/error_log [Sun Jul 16 00:59:48 2017] [notice] caught SIGTERM, shutting down |
権限を確認します。
|
[root@cent06 conf]# ls -l |
権限周りは特に問題なさそうです。
※root 以外のアカウントに鍵の中身を見せないために「644」ではなく「600」の方がいいです。
文字コードを確認します。
「file -i」コマンドで文字コードを確認できます。
|
[root@cent06 conf]# file -i /etc/httpd/conf/server.crt |
nkf コマンドがあれば、「文字コードの確認」と「文字コードの変換」が可能です。
|
[root@cent06 conf]# yum install nkf ← nkf コマンドをインストールします。 依存性を解決しました ======================================================================================================== トランザクションの要約 総ダウンロード容量: 110 k インストール: 完了しました! |
nkf コマンドで証明書の「文字コード」と「改行コード」を確認することができます。
|
[root@cent06 conf]# nkf –guess /etc/httpd/conf/server.crt |
今回は、文字コードは「ASCII」で改行コードは「LF」だったので問題ないですが、仮に「SJIS（Shift JIS）」など他の文字コードの場合、 文字コードをUTF-8 に変換します。（Apache は UTF-8 を読み込めます。→ そもそもconfファイルに日本語が入ってなければ、「ASCII」として表示されます）
※ファイルをWindowsパソコン上で開いて保存したりすると文字コードが変わることがあります。
|
[root@cent06 conf]# nkf -w8 –overwrite /etc/httpd/conf/server.crt ← utf-8 に変換します。 |
動作確認
設定上は「TLS 1.2」で通信をしていることになっていますが、実際に「TLS 1.2」で通信をしているのか動作確認をします。
openssl コマンドで確認
まずは「openssl」コマンドで通信を確認します。
|
[root@cent06 .ssh]# openssl s_client -host 192.168.1.11 -port 443 -tls1_2 Start Time: 1500190976 HTTP/1.1 400 Bad Request <!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”> |
tcpdump で動作確認
tcpdumpでも「TLS 1.2」で通信していることを確認します。
|
[root@cent06 conf]# tcpdump -nn port 443 |
コマンドラインだと SSL のバージョンが分からないのでファイルにキャプチャして「WireShark」でパケット解析をすることにします。
tcpdump でパケット解析をする方法は以下も参照してください。
以下のようにパケットをキャプチャしたデータをファイルに吐き出します。
|
[root@cent06 ~]# tcpdump -i eth0 -w ssh_test.cap ← キャプチャしたデータを「ssh_test.cap」ファイルにダンプします。 |
このデータをパソコンに転送して「WireShark」で表示します。
「TLSv1.2」で通信をしているログがあるので「TLS 1.2」で通信をしていることが分かります。
まとめ
Apache をインストールして、httpd の設定をデフォルト状態にして「オレオレ証明書」を作成して https アクセスをして表示させるだけなら簡単ですが、細かく暗号化の規格やどこがどう関連しているのか調べると、まだまだ難しく感じます。
SSL/TLS プロトコルは奥が深いです。というよりいろんな要素が関連しているので複雑です。
参考サイト
非常に深いところまで勉強になりました。
http://d.hatena.ne.jp/ozuma/20130511/1368284304
コメント