web-dev-qa-db-ja.com

EximTLSとセキュアSMTP

クライアントの暗号化されたSMTPをサポートするように既存のメールサーバーを変換している最中ですが、転送に役立つログデータがほとんどないこのレンガの壁に遭遇しました。通常の暗号化されていないSMTPを使用すると、すべて正常に機能します。物事が洋ナシ型になるのは、暗号化されたSMTPを使おうとしたときだけです。


私のexim設定ファイルには次のものが含まれています。

# Allow any client to use TLS
tls_advertise_hosts                       =  *

# Specify the location of the Exim server's TLS certificate and private key.
tls_certificate                           =  /etc/exim/exim.crt
tls_privatekey                            =  /etc/exim/exim.key 


最初は、Exim appears期待どおりに機能しているので、メールサーバーに安全に接続して自分自身を認証できますが、SMTPセッションで受信者セクションに入った直後に接続が切断されます。暗号化されていない接続を使用している場合、この問題は発生しません。


安全なSMTPをテストするには、次のコマンドを使用します。

openssl s_client -starttls smtp -crlf -connect localhost:25


そしてこれは私が得る出力です:

CONNECTED(00000003)
depth=0 C = ZA, etc, etc
verify error:num=18:self signed certificate
verify return:1
depth=0 C = ZA, etc, etc
verify return:1
---
Certificate chain
 0 s:/C=ZA/etc,etc
   i:/C=ZA/etc,etc
---
Server certificate
-----BEGIN CERTIFICATE-----
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXX==
-----END CERTIFICATE-----
subject=/C=ZA/etc,etc
---
No client certificate CA names sent
---
SSL handshake has read 1275 bytes and written 444 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Session-ID-ctx: 
    Master-Key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket:
    0000 - d0 cd ff b6 0c a2 fb 6c-f6 69 dc 0b a7 aa f3 1a   .......l.i......
    0010 - 10 76 75 05 15 d8 8c 21-cb eb b8 ae ec 34 7d b3   .vu....!.....4}.
    0020 - 7a bf f0 d6 7d df 26 27-41 1e d1 2a 35 bf 2f 0c   z...}.&'A..*5./.
    0030 - 25 6a 32 15 6e 53 d2 30-31 1b d9 60 e6 11 20 73   %j2.nS.01..`.. s
    0040 - 57 e3 76 96 e7 7e dc da-98 f2 cc a7 e5 58 62 b2   W.v..~.......Xb.
    0050 - ec db 58 91 16 14 18 ff-15 64 d6 66 1f 75 92 96   ..X......d.f.u..
    0060 - 65 43 f8 2c 4a 42 81 41-0c 2f 46 84 38 0c c5 e0   eC.,JB.A./F.8...
    0070 - 8d 7b d7 7e 12 0e 28 ca-f0 f9 b5 d0 b2 a6 ab 66   .{.~..(........f
    0080 - f8 c5 33 e3 cb 16 f5 76-8f e7 49 0c 49 69 31 43   ..3....v..I.Ii1C
    0090 - 05 25 dc 75 3a 07 13 91-63 ff 13 fd b0 2c 9f 8b   .%.u:...c....,..

    Compression: 1 (zlib compression)
    Start Time: 1315250595
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
250 HELP
HELO localhost
250 OK
MAIL FROM:[email protected]
250 OK
RCPT TO:[email protected]
RENEGOTIATING
depth=0 C = ZA, etc, etc
verify error:num=18:self signed certificate
verify return:1
depth=0 C = ZA, etc, etc
verify return:1
421 lost input connection
read:errno=0

上記の出力では、電子メールアドレスと組織ツリーをガベージデータに置き換えました。これは、通常のSMTPを使用しているときに同じ問題が発生しないため、関係がないためです。上記のトランザクションは、ローカルホストから接続しようとしたか、外部ソースから接続しようとしたかに関係なく発生します。また、OpenSSLを使用して生成された自己署名証明書を使用していることにも注意してください。また、上記の例では、ローカルホストからテストを実行しているため、認証データはありません。これにより、認証なしですべてのメールが許可されます。

上記の出力でわかるように、Eximは、文字列「RENEGOTIATING」の発行中/発行後に壊れているようです。

SMTPセッション中に受け取った出力はあまり役に立たないので、Eximをデバッグ+すべてモードで実行してみました。簡潔にするために、受信者アドレスを指定するまで、セッション全体が非常に正常であるため、完全なSMTPトランザクションを投稿しません。これは、受信者のアドレスを入力してEnterキーを押すと取得するEximデバッグデータの正確なスニペットです。

21:42:10  7425 SSL info: before accept initialization
21:42:10  7425 SSL info: before accept initialization
21:42:10  7425 SSL info: SSLv3 read client hello A
21:42:10  7425 SSL info: SSLv3 write server hello A
21:42:10  7425 SSL info: SSLv3 write certificate A
21:42:10  7425 SSL info: SSLv3 write server done A
21:42:10  7425 SSL info: SSLv3 flush data
21:42:10  7425 SSL info: SSLv3 read client key exchange A
21:42:10  7425 SSL info: SSLv3 read finished A
21:42:10  7425 SSL info: SSLv3 write session ticket A
21:42:10  7425 SSL info: SSLv3 write change cipher spec A
21:42:10  7425 SSL info: SSLv3 write finished A
21:42:10  7425 SSL info: SSLv3 flush data
21:42:10  7425 SSL info: SSL negotiation finished successfully
21:42:10  7425 SSL info: SSL negotiation finished successfully
21:42:10  7425 Got SSL error 2
21:42:10  7425 SMTP>> 421 lost input connection
21:42:10  7425 tls_do_write(1db4020, 48)
21:42:10  7425 SSL_write(SSL, 1db4020, 48)
21:42:10  7425 outbytes=48 error=0
21:42:10  7425 LOG: lost_incoming_connection MAIN
21:42:10  7425   unexpected disconnection while reading SMTP command from (localhost) [127.0.0.1]
21:42:10  7425 search_tidyup called
21:42:10  7194 child 7425 ended: status=0x100
21:42:10  7194 0 SMTP accept processes now running
21:42:10  7194 Listening...
6
Richard Keller

グーグルで30秒でこれを見つけました "openssl s_client RENEGOTIATING"s_clientのR "機能"

要約すると、s_clientセッションで「R」を押すと、opensslが再ネゴシエートします。 「RCPTTO」の代わりに「rcptto:」と入力してみてください。

Tony Finchのsmtpcswaks など、SMTP固有のテストにより適したツールを試すこともできます。

5
jj33

eximでの認証に暗号化を要求するには/etc/exim/exim.confで設定します。

auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}

また、tls 1.2を強制します:

openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1

2つの同一のeximサーバー間で、一方がAES-GCMを使用し、もう一方が暗号化にChaCha20-Poly1305を使用していることに気付き、その理由がわかりませんでした。 使用される暗号化スキームは、 `cpuでHostAESハードウェアアクセラレーションがあるかどうかによって異なります

0
Stuart Cardall