ITプロデュース熊本

‘SSL’ タグが付けられた記事

SSL通信はなぜ安全なのかを解説するシリーズの記事です。

今回は初回ですので、SSLとは何のために使用するものなのかを紹介します。

インターネットでの通信

インターネットでやり取りされる通信は、実は簡単に盗聴できます。

原理を説明すると難しくなるので省きますが、例え話で説明しましょう。

ここは、学校の教室だと思ってください。ちょっと悪知恵のつき始めた小学校高学年くらい。

先生の目を盗んで、紙切れに手紙なんかを書いて回してます。

インターネットの通信は丸見え

紙の表には「宛名と送り主」を書いてあり、裏にメッセージが書いてあると思ってください。

間の席にいる生徒たちは紙が回ってきて、自分宛でなければ隣や前後の生徒に渡します。自分宛だったら裏のメッセージを読みます。

インターネットのしくみは、簡単にすればこのようなものです。

ところで、生徒同士のメッセージのやりとりの例では、途中の生徒が見ようと思えば、簡単にメッセージの内容を見ることができます。隣に回す前に、裏返して見てしまえばいいだけです。

実は、インターネットでの通信もこの程度のものなのです。

例えば、職場によっては従業員のネット利用を監視していることがあります。それは、通信内容を途中で見ることができるから、可能なのです。

暗号化

秘密のメッセージを送る必要がある場合は、どうすればよいのでしょうか。

直接手渡しをする、という方法ももちろんあります。丸めて抜群のコントロールで投げつけるとか、エアシューター を設置して飛ばすとか・・・。どちらにしても現実的ではありませんね。

PCのネットワークでは、インターネットを使わずに専用線を引くこともできます。こちらはまあ現実的な手段です。ただし、コストを考えると現実味は薄れます。

また、不特定多数を相手にするのは事実上不可能です。

今ある仕組みをそのまま使って、秘密にメッセージを送る方法が、暗号化です。

秘密のメッセージを送ることができる

暗号化通信の役割の1つ目は、そのままですが「秘密のメッセージを送る」ために使用するというものです。

A君はE君にしか分からない（＝E君は復号できるけど、それ以外は解読できない）ように暗号化するのです。

今さらですが、出てくる言葉の説明をしておきます。

暗号化とは「平文（ひらぶん＝伝えたいメッセージそのままの文章）を何らかのルールで変換し、第三者が読めないようにすること」。

復号化とは「本来読むべき相手が、きちんとした手続きで平文に戻すこと」。

それに対して解読とは「本来ならば読むべきでない第三者が、不正な手続きで平文に戻すこと」をいいます。

誰が暗号化したのかが分かる

もう一つ役割があります。こちらは多少分かりにくいのですが、「誰が暗号化したものかを示す」ためにも使えます。

ある暗号化方式を使うと、「この暗号のかけ方は A君だ」ということが分かるのです。

これは、暗号に使用する「鍵」を、1人1人が違うものを使用する、というルールによって成り立っています。

A君の「鍵」はA君だけが使い、他の鍵ではA君の鍵とは別の暗号になります。

他の誰かが「Aより」なんて書いたとしても、A君の暗号にはできないので、ばれてしまうのです。

これについては、「公開鍵方式」で説明します。

まとめ

SSLでできることは、

• 盗聴 を防ぐことができる
• なりすまし を防ぐことができる

です。

最近書いた記事に、よく SSL という言葉が登場します。

どの記事でも「SSLで暗号化通信をすれば安心」と、さも当然のように書いてしまっています。

ですが、読んでくださっている方の中には、「本当に安全なの？」「なんで安全と言い切れるの？」と疑問を感じる方もいらっしゃるでしょう。

そこで、何回かに分けて「SSL通信はなぜ安全なのか」について、解説します。

目次

解説記事の目次です。書き終わった記事へはリンクを張っていきます。まだ書いていない記事は、予定なので変更するかもしれません。

1. SSLでできること
2. 共通鍵方式とは
3. 公開鍵方式とは
4. SSLのしくみ
5. なぜSSLで「盗聴」を防げるのか
6. なぜSSLで「なりすまし」を防げるのか

先日、Subversion のリポジトリアクセスを SSL 対応にする手順を紹介しました。

SSL接続のみ許可する

さらに、/etc/apache2/conf.d/subversion.conf ファイルの記述に SSLRequireSSL の行を追加することで、

<Location /svn/[リポジトリ名]>
        DAV svn
        SVNPath /var/lib/svn/[リポジトリ名]
        AuthType Basic
        AuthName "Subversion Repositries"
        AuthUserFile /var/lib/svn/itpk/conf/.htpasswd
        Require valid-user
        SSLRequireSSL
</Location>

このリポジトリには、 Apache2 経由では SSL通信でしかアクセスできなくなります。

こうしておくことで、設定ミスで（または面倒だからという理由で）通常のHTTPで通信することがなくなるので、安全性が高まります。

Redmineからリポジトリへアクセス

ところで、Redmine では プロジェクトにリポジトリを対応付けられます。

とてもよくできた機構で、どのチケット（＝Redmineでは1つの作業をチケットで管理する）のために、どのファイルのどこを変更したのかが分かるのです。

で、Redmineでこの機能を使うためには、プロジェクトの設定で リポジトリを指定する必要があります。

ところが、SSL通信を使って “https://…” を指定すると、Redmineからはリポジトリにアクセスできません。

どうも、SSL通信で失敗しているようです（正式な証明書を使用していないせいかもしれません）。

普通に “http://…” ならばアクセスできるのですが、Redmine のためだけに抜け道を用意するのは、躊躇（ためら）われます。

社員に何の悪気がなくても、その抜け道を使ってしまえば、悪意のある盗聴者に重要なファイルが漏れる恐れがあるからです。

解決策

解決策は非常に簡単でした。

Redmine に リポジトリ の設定をする際には、http 以外にも file や svn といったプロトコルを使って URL 指定をすることができます。

svn プロトコルは、svnserve というプロセスが動いていないといけないのですが、 file はファイルアクセスができればOKです。

我がITPKの社内サーバでは、Redmine が動いているマシンに、Subversion リポジトリの実体があるので、もちろんファイルアクセス可能です。

なので、 file:///var/lib/svn/[リポジトリ名]/ を指定することで、SSL通信だけに制限しても、Redmine からリポジトリアクセスできます。

もちろん、Redmine はローカルファイルアクセスをしているだけなので、盗聴の恐れもありません。

Redmine や Subversion を動かしている 自社サーバ（Vine Linux 5） に SSL通信 を導入した時の作業メモです。

外部向け（このサイト）のWebサーバはホスティングを使っているので、自社サーバの Apache2 は これら Redmine と Subversion だけのために動かしています。

準備

OpenSSL は通常インストールで入っていました。

ただ、Apache2 が標準では SSL に対応していないので、mod_ssl をインストールします。

# apt-get install mod_ssl

証明書の作成

まず、秘密鍵を作成する。

# cd /usr/share/ssl/certs
# make server.key
（パスフレーズ入力）×2回

秘密鍵からパスフレーズを削除する。

# openssl rsa -in server.key -out server.key

公開鍵を作成する。

# make server.csr

認証書を作成する。有効期限は1年にしておく。

# openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 365

Apache2 の設定ファイルを書き換える

/etc/apache2/conf/httpd.conf を書き換えます。

    （略）
# Dynamic Shared Object (DSO) Surpport
    （略 : LoadModule が並んでいる後に追加すると分かりやすい）
LoadModule ssl_module modules/mod_ssl.so

（/etc/apache2/conf/httpd.conf に書いてもいいのですが）SSL関連の記述は、/etc/apache2/conf.d/ssl.conf に書きます。

<IfModule mod_ssl.c>
    NameVirtualHost *:443
    Listen 443
    <VirtualHost *:443>
        ServerAdmin noboru@itpk.jp
        DocumentRoot /var/www/html/
        SSLEngine on
        SSLCertificateFile /usr/share/ssl/certs/server.crt
        SSLCertificateKeyFile /usr/share/ssl/certs/server.key
    <Files ~ "\.(cgi|shtml)$">
        SSLOptions +StdEnvVars
    </Files>
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    </VirtualHost>
</IfModule>

接続確認

信頼できない接続（FireFox）

ブラウザで今回設定したサーバにアクセスしてみます。この時に必ずURLを、”https://…”とすること（そうしないと、SSL接続の確認になりません）。

すると、図のような画面が表示されるはずです（ブラウザによって多少は異なる）。

今回使用した証明書は、自分で作って発行したものだからです。

ところで、SSL通信の役割は2つあります。

1つは通信を暗号化することにより安全性を高めること。

証明書エラー（Internet Explorer）

もう1つは、通信相手が信頼できる相手だと保証することです。

ただ、今回の使用目的の場合は、通信の暗号化だけが目的です。アクセスするのは社員だけなので（自社サーバーであることは確実なので）信頼はしてもらえる、という前提で作っています。

これが仮に、不特定多数の人が機密性の高いデータをやり取りするようなサービスである場合（ショッピングサイトなど）は、きちんとした認証局に間に入って貰う必要があります。

接続する

そんなこんなで、このサイトに関しては信頼することにして、接続することにします。

「危険性を理解した上で接続するには」の中の「例外を追加…」ボタンを押します。

セキュリティ例外の追加

しばらく（証明書を取得している間は待つことになる）すると「不正な証明書です」など、散々な書かれ方をされますが、今回は信頼できるサイトなので（「表示」ボタンを押せば先程作った証明書であることが分かります）、「セキュリティ例外を承認」を押します。

この時、「次回以降にもこの例外を適用する」にチェックを入れておけば、次回からはこの辺のやりとりはなくなります。