昔からある和製ProxyサーバDelegated Proxy Server。海外のオープンソースがひしめく中で高機能で堅牢なProxyサーバです。他のProxy Serverにはない機能が沢山あり使う度にこんなこともできるんだと感心することもあります。今回の投稿ではこの和製ProxyサーバでSSL接続する方法を紹介したいと思います。

まずはdelegated proxyサーバをダウンロードしましょう。ソースからコンパイルして使うのが良いですね。CentOSというかRedHat系はすんなりコンパイルできますが、Ubuntuは古いバージョンのDelegatedでないと確実にエラーが発生しますので、最新のDelegatedバージョンを入れるならバイナリーをダウンロードして設置しsslwayだけRedhat系でコンパイルしたものを持ってきて使うのが簡単です。当方で確認した限りでは特に問題なくこのやり方でSSLの接続動作しました。何故かsslwayはバイナリーパッケージにはバンドルされていなかった。

Delegated ダウンロード公式ページ(source) Delegated ダウンロード公式ページ (Binary)

※現在の最新は9.9.13でソースからコンパイルするならdelegate9.9.13.tar.gzをダウンロードしてください。

コンパイルの仕方

直接起動スクリプトにパラメータを設定してdelegatedを起動する場合の必要最低限のインストール

Reverse Proxy構成例

起動スクリプトの準備

下記は内部8080ポートで起動しているWEBサーバにproxy転送する場合だ。最近のプログラム言語は自前でWEBサーバが起動できるケースが殆どなので、マルチスレッドで内部WEBサーバを立てローカルホストでListen起動させておけば余計なポート＆アドレスへの攻撃から遮断した上で本格的なSSL接続仕様にできる。
Reverse Proxy仕様でSSLを行う場合のメリットは元のサーバのソースコードを弄らなくて良いところ、そして堅牢性に不安がある場合にある一定の防御壁として動作してくれるため通常の外部WSGIサーバ連携などよりもいい場合もある。やはりケースバイケースのSSL接続の方式選択があると思う。

このケースではSSLの証明書は作成時にパスワード無しで処理しているがパスワード付きで証明書を生成しているなら「-pass file:path」or 「-pass pass:password」をsslwayの引数指定で設定すれば問題ない。尚「POODLE」攻撃を防ぐ施策として「-tls1 -tls1_1 -tls1_2 -no_ssl23」の指定を行っている。このパラメータは本サイトで紹介されていないので非公開のスイッチかもしれない。ソースコードから調査して見つけました。ペネトレーションテストでも調査済みで有効なSSLスイッチでした。またCipherSuiteに関しても環境変数(SSL_CIPHER)で指定できることがわかりましたのでご紹介しています。

SSL証明書の指定は-certと-keyが使えるので、もしCA rootの証明書があるならサーバ証明書「-cert」のファイルにサーバ証明書とCA root証明書を結合して設置すればOK。

実行権を付与しdelegatedの起動