web-dev-qa-db-ja.com

単一のアプリケーションのSSLをラップするようにstunnelを設定する

stunnel を使用して、SSLをサポートする古いusenetクライアントを取得しようとしています。次の設定を試しました。

[myservice]
accept = <LOCAL_PORT>
connect = <REMOTE_Host>:<REMOTE_PORT>

しかし、stunnelはエラーで失敗し続けました：

Section myservice: SSL server needs a certificate

私は何が間違っているのですか？

stunnel
3
Mark Lodato

client = yesセクションで[myservice]を設定します。これは、connect（別名「サーバー」）側がSSL側であり、accept（別名「クライアント」）側がプレーンであることをstunnelに通知します。デフォルトは逆で、SSL証明書が必要です。

しかし、それだけではありません！なんらかの理由で、stunnelはデフォルトで完全に安全でないモードになり、サーバーの証明書の検証は行われません。つまり、man-in-the-middle（MitM）攻撃を受ける可能性があります。これを修正するには、verify = 2およびCAfileオプションを使用します。 Ubuntuでは、CAfileは/etc/ssl/certs/ca-certificates.crtにあります（ca-certificatesパッケージから）。その間、options = NO_SSLv2を設定して、安全でないSSLv2プロトコルを無効にします。

最後に、usenetプログラムを構成するときは、アプリケーションとstunnel間の接続がSSLを使用しないため、SSLを無効にします。

これを支援するために、次のラッパースクリプトを作成しました。必要に応じて<LOCAL_PORT>、<REMOTE_Host>、および<REMOTE_PORT>を置き換え、# ...を実行したいコマンドに置き換えます。

#!/bin/bash
PIDFILE=/tmp/stunnel-agent.pid

# Start stunnel in the background.
cat << EOF | stunnel4 -fd 0
pid = $PIDFILE

# Enable proper SSL security.  Without this, you are completely insecure!
verify = 2
CAfile = /etc/ssl/certs/ca-certificates.crt
options = NO_SSLv2

[myservice]
client = yes
accept = <LOCAL_PORT>
connect = <REMOTE_Host>:<REMOTE_PORT>
EOF

# Start whatever program you want.
# ...

# Kill stunnel.
kill $(cat "$PIDFILE")
3
Mark Lodato