As I Please

MTのいんすとーるの練習と、その他びぼうろく・・・

タグ「openssl」が付けられているもの


let's encrypt のサーバ証明書を使っていて、iphoneのメールアプリでエラーが表示される件

let's encryptの無料サーバ証明書を、httpsサーバ(このサイト)や他サイトでも利用していて、webだけではなくて、smtp(s)でも流用できるので使っていた。
メールも受信(server)・送信(client) がデフォルトで smtps/starttls を利用するようになってきているようで、
グローバルにauthorized された証明書を使っているほうが、いろいろ良さそう。
imapsは相変わらずプライベートCA+証明書を利用しているけど。

先日、2021/09でlets encrypt の証明書のCA問題の影響を受けて、iOSの標準のメールアプリからメールサーバ(smtps)の接続がうまくいかない(メールが送れなく)なった。imapsでの接続でメールの取得・閲覧はうまくいっているに。
ということでいろいろ調べてみると、openssl 1.0.2 ではCA証明書への辿りの解釈に難があるよう。
で、問題を起こしているのは sendmail が共有ライブラリとして libssl.so をリンクしていてその中身が 1.0.2(またはそれ以前)のホストばっかり!ということに気づいた。opensslは 1.1系を /usr/local/bin/openssl にインストール,libssl.so は /usr/local/lib/ あたりにいたが、sendmailのを作成したときには /usr/lib/libssl.so あたり(/usr/bin/openssl は version 1.0.2!) の共有ライブラリをリンクしていた!
なので対応としては、


  1. openssl 1.1系列(今の最新は1.1.1l)をコンパイルして、共有ライブラリのバージョン(1.1.1)を用意する。

  2. sendmailを作成し直して、openssl(libssl.so or libssl.a) をリンクし直す。


ことに。
sendmailも8.15.2と思ったら、8.17.1が最新なのでこれも sourceから持ってきて recompileした。
$src/devtools/Site/site.config.m4 の設定をよくみて、、、。
EOLになってしまっている、FreeBSD-11.4だと、

APPENDDEF(`conf_smrsh_ENVDEF', `-DCMDDIR="\"/usr/local/libexec/sm.bin\""')
APPENDDEF(`conf_smrsh_ENVDEF', `-DPATH="\"/bin:/usr/bin\""')
define(`confEBINDIR',`/usr/local/libexec')
define(`confMANROOT',`/usr/local/man/cat')
define(`confMANROOTMAN',`/usr/local/man/man')
define(`confMBINDIR',`/usr/local/sbin')
define(`confSBINDIR',`/usr/local/sbin')
define(`confUBINDIR',`/usr/local/bin')
define(`confNO_STATISTICS_INSTALL',`True')
define(`confHFDIR', `/usr/local/share/sendmail')
APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
APPENDDEF(`conf_sendmail_ENVDEF', `-DDANE')
APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
APPENDDEF(`conf_sendmail_ENVDEF', `-DUSE_BLACKLIST')
APPENDDEF(`conf_sendmail_LIBS', `-lblacklist')
APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
APPENDDEF(`conf_sendmail_ENVDEF', `-DHASSRANDOMDEV')
APPENDDEF(`confINCDIRS', `-I/usr/local/include')
APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
APPENDDEF(`confLDOPTS', ``-Wl,-rpath=/usr/local/lib'')
APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -DTLS_EC')
APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
APPENDDEF(`conf_sendmail_ENVDEF', `-DPICKY_HELO_CHECK')
sendmail-8.15のときとの違いは、、、'_FFR_TLS_EC' だったものが 'TLS_EC'と正規?なパラメータ名になったこと、くらいか。いつものように、milter,sasl2,あたりをlinkすることも忘れないように。

sendmailを展開した $srcトップ にて、'sh ./Build;sh ./Build install'
実はこの作業の前に FreeBSD 11.2 -> 11.4, perlの入れ直し、gccの入れ直しなど大工事あり・・・
それにしても、、、古い OSを使い続けるとどんどん大変になる。

certbot on FreeBSD9

なかなかやめられない古いOSで、次は証明書(let's encrypt) を使い続けたくて。。。 運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。 ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない!のが問題(古い git clientすぎた)ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は git-remote-https.core を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。 コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。 ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。 いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で
source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com
と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。
[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'
なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、
python3 setup.py build
python3 setup.py install
で、/usr/local/bin/certbot にインストールされた。
certbot certonly --standalone -d test.example.com
でちゃんと証明書が降りてきた。

certbot on FreeBSD9

なかなかやめられない古いOSで、次は証明書(let's encrypt) を使い続けたくて。。。 運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。 ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない!のが問題(古い git clientすぎた)ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は git-remote-https.core を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。 コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。 ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。 いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で
source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com
と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。
[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'
なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、
python3 setup.py build
python3 setup.py install
で、/usr/local/bin/certbot にインストールされた。
certbot certonly --standalone -d test.example.com
でちゃんと証明書が降りてきた。

bind の入れ替え>openssl の入れ替え > perl の入れ替え > perl moduleのインストールしなおし。

あぁ、依存関係が面倒だった。

bind-9.14.12 : portsで入れると
openssl : ports で。 1.1.1g に。
これで named はちゃんと動き始めたが、libcrypto.so が変わったのでちょっと心配になっていくつかみたら、
いきなり apache (mod_ssl.so)が共有ライブラリ見失った。
apache24 も作り直し。
ここで MTも見てみたら、ssl通信関連のモジュールが見当たらないとか言い始める。

501 Attempt to reload IO/Socket/SSL.pm aborted. Compilation failed in require (LWP::Protocol::https not installed):

もう片っ端から入れ直し。 perl5, p5-LWP-Protocol-https,p5-IO-Socket-SSL。でもこれでも直らないので、探してみたら
perl-Socketを入れ直すらしい。
https://qiita.com/fukuchan-senpai/items/e6d6731b27ead15e22e8

やっとこれで元に復帰した(つもりでいるけど、まだどっかに落とし穴があるに違いない)

bind の入れ替え>openssl の入れ替え > perl の入れ替え > perl moduleのインストールしなおし。

あぁ、依存関係が面倒だった。

bind-9.14.12 : portsで入れると
openssl : ports で。 1.1.1g に。
これで named はちゃんと動き始めたが、libcrypto.so が変わったのでちょっと心配になっていくつかみたら、
いきなり apache (mod_ssl.so)が共有ライブラリ見失った。
apache24 も作り直し。
ここで MTも見てみたら、ssl通信関連のモジュールが見当たらないとか言い始める。

501 Attempt to reload IO/Socket/SSL.pm aborted. Compilation failed in require (LWP::Protocol::https not installed):

もう片っ端から入れ直し。 perl5, p5-LWP-Protocol-https,p5-IO-Socket-SSL。でもこれでも直らないので、探してみたら
perl-Socketを入れ直すらしい。
https://qiita.com/fukuchan-senpai/items/e6d6731b27ead15e22e8

やっとこれで元に復帰した(つもりでいるけど、まだどっかに落とし穴があるに違いない)

sendmail-8.15.2 .on FreeBSD-9

重力波関連の速報が知りたくて、GCN Circularsのメールを受信しているけど、NASAの シスアドからメールが。

Subject: TLSv1.1-related mail bounces with NASA/GSFC

Hello,

I am a system administrator with the Astrophysics Science Division at NASA/Goddard Space Flight Center.

Due to a directive from the US Department of Homeland Security, I have made a change today to our mail server "capella2.gsfc.nasa.gov" (the mail server for the Gamma-ray Coordinates Network, https://gcn.gsfc.nasa.gov/ ) such that it now blocks TLSv1 and TLSv1.1.

Our logs show entries of the form:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: STARTTLS=client: 11833:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:714:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: ruleset=tls_server, arg1=SOFTWARE, relay=, reject=403 4.7.0 TLS handshake failed.

I am not sure what changes might be needed on your side, but I at least wanted to alert you (because otherwise you or your users might have a "why is this suddenly failing" feeling!). I hope this is helpful.

Regards,

David

P.S. In terms of changes needed, you might need to upgrade your mail server software (sendmail, postfix, Exim, etc) to one that can "speak" TLSv1.2 or newer. Your site doesn't need to require TLSv1.2 as a minimum, as we have had to do, but it needs to be an option. Alternatively, you can let us know of a different mail address on your end to use.

と。sendmail のやりとりで TLS1.2じゃないから上げてね、というリクエスト。システムの自動応答かと思ったらどうもそうでもないような。

"US Department of Homeland Security"ってなんだ?と思ったら国土安全保障省 ?ひぇひぇ。こういうところが勧告するですね、アメリカは。
DNSのMXは primary 10,secondary 20にしていたので、通常は primary のメールサーバに来ていたが、このNASAのメールが急に secondary にメールが届くようになったので何事だろうと思っていたらこういうことだったのか。 実はprimary は TLS1.0,1.1は喋るが TLS1.2は対応していないlibssl.soをリンクしてるsendmail で動いていた。secondary はちゃんと TLS1.2を喋る libssl.soだったのでこちらに流れてきていたもののようだ。 openssl はちゃんと入れていたつもりが、sendmail はOS附属の古い libssl.so をリンクしていた。 ということで、古いOSに最新のsendmail + TLS1.2対応の ものを再インストールする必要が。 postfix,eximとかに変えることも一瞬考えるけど、milter系のものやMLソフトの整備を考えると手が出ない。 FreeBSDは、patchなどについては portsのファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。
  1. まず既存の bin,configのバックアップ
  2. 必要なpatch をあてる。
  3. sendmail の configの作成
  4. compile
  5. install
と言うことで作業。
  1. まず既存のbin,configのバックアップ
  2. sendmail だけではなくて、いくつかのバイナリ・設定ファイルが作られるので、それを調べて見る。 sendmail-8.15.2.tar.gz を展開して srcのトップディレクトリで 'sh ./Build' を実行すると、 "$src/obj.`uname`.`uname -r`.`uname -p'にバイナリ別のディレクトリができる。 具体的には、
    obj.FreeBSD.9.3-RELEASE-p49.amd64
    の下に、
    editmap libsmdb mail.local makemap rmap smrsh
    libsm lbismuitl mailstats praliases sendmail vacation
    が出来た(12ディレクトリ)。
    これらが後にインストールされると思われるので、おのおのバックアップ。

    /usr/local/bin/rmail
    /usr/local/bin/mailstats
    /usr/local/bin/vacation

    /usr/local/sbin/editmap
    /usr/local/sbin/makemap
    /usr/local/sbin/praliases
    /usr/local/sbin/sendmail

    /usr/lcoal/libexec/smrsh
    /usr/local/libexec/mail.local

    libが3つ(libsmdb,libsm,libsmutil)あるがこれらはコンパイル時にstaticにリンクされるようなのでとりあえずこのまま放っておいて良いみたい。
    src/libmilter があるがこれはBuildしても自動では作成されない。sendmail/milter.c があり、sendmailをコンパイルするとkには milter.o がリンクされているのでたぶんこれは sendmailを作成時には不要のよう。3rdパーティのプログラムを使う(かもしれない)ときに libmilter.a,libmilter.so とかでリンクするためにあるようだ。(see $src/libmilter/README)
    これは明示的に 'cd libmilter; sh ./Build; sh ./Build install' で良さそう。

    config系は

    /etc/mail/
    /usr/local/share/sendmail/
    /etc/rc.sendmail

    あたりをバックアップ。
  3. patchをあてる。
  4. ports の mail/sendmail/files/ 以下に patch-xxx がある。これらを当てればいいはず、、だが、ports用のマクロ設定(%%CC%%とかに置き換え等)がありちょっとためらう。特にこのパッチを当てなくても warningが少しでるがcompileはうまくいっているようなので、今回は当てなかった。
  5. configの作成
  6. $src/INSTALL にあるように、 $src/devtools/Site/site.config.m4 を作成する。 site.config.m4.sample があるが、これはほぼ当てにならない。portsの mail/sendmail/files/ の中に site.config.m4の機能別のファイルがあるのでこれらをconcatinate して作るのが正しいかと。このディレクトリにある、site.config.m4に、ipv6,tls,sasl2,milter を今回は追加した。
    dnl
    dnl 0) use site.config.m4
    dnl
    define(`confEBINDIR',`/usr/local/libexec')
    define(`confMANROOT',`/usr/local/man/cat')
    define(`confMANROOTMAN',`/usr/local/man/man')
    define(`confMBINDIR',`/usr/local/sbin')
    define(`confSBINDIR',`/usr/local/sbin')
    define(`confUBINDIR',`/usr/local/bin')
    define(`confNO_STATISTICS_INSTALL',`True')
    define(`confHFDIR', `/usr/local/share/sendmail')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
    APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
    dnl
    dnl
    dnl 1) use site.config.m4.ipv6
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
    dnl
    dnl 2) use site.config.m4.tls
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -D_FFR_TLS_EC')
    APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
    dnl
    dnl 3) use site.config.m4.sasl2
    dnl
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-I%%LOCALBASE%%/include')
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    dnl APPENDDEF(`confLIBDIRS', `-L%%LOCALBASE%%/lib')
    dnl APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
    APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    dnl
    dnl 4) use site.config.m4.milter
    dnl
    APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
    dnl
    
  7. compile
  8. $src にて、'sh ./Build'
  9. install
  10. $srcにて、'sh ./Build install'
元々 8.15.2 用で使っていた sendmail.cf はそのまま使えた。 これで TLS1.2も話す sendmail になったか。

ps.1
某日、STARTTLSを使ってちゃんとTLSで接続してくるメールを見てみたらいろいろあったので メモ。
クライアント証明書つきのTLS通信(但し認証(verify)はもちろんしていない)
  • NASA
  • Google (Gmailの転送)
  • SwarovskiのML
  • T-PointのML
  • オレオレCA証明書で発行したクライアント証明書を使っているMTA
ただの TLS通信。転送路は TLSのようだが特に認証無し。
  • shopify の広告DM
  • SBIのDairy mail
  • Land's Endの広告DM
  • 東洋経済のML
  • トクバイのML
  • キタムラのML
  • ホンダのML
  • DMMからのメール
  • JustsystemからのML
  • AmazonからのDM
  • GU(ユニクロ)からのML
  • みずほ銀行からのDM
  • OpenHouseからのDM
  • GMOからのML
  • EXPANSYSからのML
  • MoneyforwardからのML
  • JTBからのML
  • Generate DesginからのML
  • Wealthnavi からのML
  • QNAP からのML
  • Nature RemoからのML
  • furusat taxからのML
  • IPCamのメール通知クライアント(sasl認証)
単に forged なだけか、おかしな通信
  • security.criminalip.com
  • ninja.census.shodan.io
  • わざわざ SSL3.0,TLS1.0,TLS1.1,TLS1.2と繋がるか調べにやってきてる。
  • bezeqint.net
今後は sendmailもクライアント接続してくる側も証明書呈示するようになっていくんですかね。 とりあえず、うちも STARTTLSで接続したときに let's encryptあたりの証明書を呈示するようにしておいてみるか?

ps.2
TLS1.2対応になったことを、NASAのシスアドに連絡してみたところ、返答が。

I am glad to hear it is working for you once again!

Yes, I can see the moment in our logs when it got fixed:

Here is the last line of failure and the first line of success:

May 11 xx:xx:xx capella2 sendmail[15971]: ruleset=tls_server, arg1=SOFTWARE, relay=aaa.bbb.ccc, reject=403 4.7.0 TLS handshake failed.

May 11 yy:yy:yy capella2 sendmail[15971]: STARTTLS=client, relay=aaa.bbb.ccc., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128

Thanks,

David


わざわざ丁寧にありがとう。

sendmail-8.15.2 .on FreeBSD-9

重力波関連の速報が知りたくて、GCN Circularsのメールを受信しているけど、NASAの シスアドからメールが。

Subject: TLSv1.1-related mail bounces with NASA/GSFC

Hello,

I am a system administrator with the Astrophysics Science Division at NASA/Goddard Space Flight Center.

Due to a directive from the US Department of Homeland Security, I have made a change today to our mail server "capella2.gsfc.nasa.gov" (the mail server for the Gamma-ray Coordinates Network, https://gcn.gsfc.nasa.gov/ ) such that it now blocks TLSv1 and TLSv1.1.

Our logs show entries of the form:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: STARTTLS=client: 11833:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:714:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: ruleset=tls_server, arg1=SOFTWARE, relay=, reject=403 4.7.0 TLS handshake failed.

I am not sure what changes might be needed on your side, but I at least wanted to alert you (because otherwise you or your users might have a "why is this suddenly failing" feeling!). I hope this is helpful.

Regards,

David

P.S. In terms of changes needed, you might need to upgrade your mail server software (sendmail, postfix, Exim, etc) to one that can "speak" TLSv1.2 or newer. Your site doesn't need to require TLSv1.2 as a minimum, as we have had to do, but it needs to be an option. Alternatively, you can let us know of a different mail address on your end to use.

と。sendmail のやりとりで TLS1.2じゃないから上げてね、というリクエスト。システムの自動応答かと思ったらどうもそうでもないような。

"US Department of Homeland Security"ってなんだ?と思ったら国土安全保障省 ?ひぇひぇ。こういうところが勧告するですね、アメリカは。
DNSのMXは primary 10,secondary 20にしていたので、通常は primary のメールサーバに来ていたが、このNASAのメールが急に secondary にメールが届くようになったので何事だろうと思っていたらこういうことだったのか。 実はprimary は TLS1.0,1.1は喋るが TLS1.2は対応していないlibssl.soをリンクしてるsendmail で動いていた。secondary はちゃんと TLS1.2を喋る libssl.soだったのでこちらに流れてきていたもののようだ。 openssl はちゃんと入れていたつもりが、sendmail はOS附属の古い libssl.so をリンクしていた。 ということで、古いOSに最新のsendmail + TLS1.2対応の ものを再インストールする必要が。 postfix,eximとかに変えることも一瞬考えるけど、milter系のものやMLソフトの整備を考えると手が出ない。 FreeBSDは、patchなどについては portsのファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。
  1. まず既存の bin,configのバックアップ
  2. 必要なpatch をあてる。
  3. sendmail の configの作成
  4. compile
  5. install
と言うことで作業。
  1. まず既存のbin,configのバックアップ
  2. sendmail だけではなくて、いくつかのバイナリ・設定ファイルが作られるので、それを調べて見る。 sendmail-8.15.2.tar.gz を展開して srcのトップディレクトリで 'sh ./Build' を実行すると、 "$src/obj.`uname`.`uname -r`.`uname -p'にバイナリ別のディレクトリができる。 具体的には、
    obj.FreeBSD.9.3-RELEASE-p49.amd64
    の下に、
    editmap libsmdb mail.local makemap rmap smrsh
    libsm lbismuitl mailstats praliases sendmail vacation
    が出来た(12ディレクトリ)。
    これらが後にインストールされると思われるので、おのおのバックアップ。

    /usr/local/bin/rmail
    /usr/local/bin/mailstats
    /usr/local/bin/vacation

    /usr/local/sbin/editmap
    /usr/local/sbin/makemap
    /usr/local/sbin/praliases
    /usr/local/sbin/sendmail

    /usr/lcoal/libexec/smrsh
    /usr/local/libexec/mail.local

    libが3つ(libsmdb,libsm,libsmutil)あるがこれらはコンパイル時にstaticにリンクされるようなのでとりあえずこのまま放っておいて良いみたい。
    src/libmilter があるがこれはBuildしても自動では作成されない。sendmail/milter.c があり、sendmailをコンパイルするとkには milter.o がリンクされているのでたぶんこれは sendmailを作成時には不要のよう。3rdパーティのプログラムを使う(かもしれない)ときに libmilter.a,libmilter.so とかでリンクするためにあるようだ。(see $src/libmilter/README)
    これは明示的に 'cd libmilter; sh ./Build; sh ./Build install' で良さそう。

    config系は

    /etc/mail/
    /usr/local/share/sendmail/
    /etc/rc.sendmail

    あたりをバックアップ。
  3. patchをあてる。
  4. ports の mail/sendmail/files/ 以下に patch-xxx がある。これらを当てればいいはず、、だが、ports用のマクロ設定(%%CC%%とかに置き換え等)がありちょっとためらう。特にこのパッチを当てなくても warningが少しでるがcompileはうまくいっているようなので、今回は当てなかった。
  5. configの作成
  6. $src/INSTALL にあるように、 $src/devtools/Site/site.config.m4 を作成する。 site.config.m4.sample があるが、これはほぼ当てにならない。portsの mail/sendmail/files/ の中に site.config.m4の機能別のファイルがあるのでこれらをconcatinate して作るのが正しいかと。このディレクトリにある、site.config.m4に、ipv6,tls,sasl2,milter を今回は追加した。
    dnl
    dnl 0) use site.config.m4
    dnl
    define(`confEBINDIR',`/usr/local/libexec')
    define(`confMANROOT',`/usr/local/man/cat')
    define(`confMANROOTMAN',`/usr/local/man/man')
    define(`confMBINDIR',`/usr/local/sbin')
    define(`confSBINDIR',`/usr/local/sbin')
    define(`confUBINDIR',`/usr/local/bin')
    define(`confNO_STATISTICS_INSTALL',`True')
    define(`confHFDIR', `/usr/local/share/sendmail')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
    APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
    dnl
    dnl
    dnl 1) use site.config.m4.ipv6
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
    dnl
    dnl 2) use site.config.m4.tls
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -D_FFR_TLS_EC')
    APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
    dnl
    dnl 3) use site.config.m4.sasl2
    dnl
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-I%%LOCALBASE%%/include')
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    dnl APPENDDEF(`confLIBDIRS', `-L%%LOCALBASE%%/lib')
    dnl APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
    APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    dnl
    dnl 4) use site.config.m4.milter
    dnl
    APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
    dnl
    
  7. compile
  8. $src にて、'sh ./Build'
  9. install
  10. $srcにて、'sh ./Build install'
元々 8.15.2 用で使っていた sendmail.cf はそのまま使えた。 これで TLS1.2も話す sendmail になったか。

ps.1
某日、STARTTLSを使ってちゃんとTLSで接続してくるメールを見てみたらいろいろあったので メモ。
クライアント証明書つきのTLS通信(但し認証(verify)はもちろんしていない)
  • NASA
  • Google (Gmailの転送)
  • SwarovskiのML
  • T-PointのML
  • オレオレCA証明書で発行したクライアント証明書を使っているMTA
ただの TLS通信。転送路は TLSのようだが特に認証無し。
  • shopify の広告DM
  • SBIのDairy mail
  • Land's Endの広告DM
  • 東洋経済のML
  • トクバイのML
  • キタムラのML
  • ホンダのML
  • DMMからのメール
  • JustsystemからのML
  • AmazonからのDM
  • GU(ユニクロ)からのML
  • みずほ銀行からのDM
  • OpenHouseからのDM
  • GMOからのML
  • EXPANSYSからのML
  • MoneyforwardからのML
  • JTBからのML
  • Generate DesginからのML
  • Wealthnavi からのML
  • QNAP からのML
  • Nature RemoからのML
  • furusat taxからのML
  • IPCamのメール通知クライアント(sasl認証)
単に forged なだけか、おかしな通信
  • security.criminalip.com
  • ninja.census.shodan.io
  • わざわざ SSL3.0,TLS1.0,TLS1.1,TLS1.2と繋がるか調べにやってきてる。
  • bezeqint.net
今後は sendmailもクライアント接続してくる側も証明書呈示するようになっていくんですかね。 とりあえず、うちも STARTTLSで接続したときに let's encryptあたりの証明書を呈示するようにしておいてみるか?

ps.2
TLS1.2対応になったことを、NASAのシスアドに連絡してみたところ、返答が。

I am glad to hear it is working for you once again!

Yes, I can see the moment in our logs when it got fixed:

Here is the last line of failure and the first line of success:

May 11 xx:xx:xx capella2 sendmail[15971]: ruleset=tls_server, arg1=SOFTWARE, relay=aaa.bbb.ccc, reject=403 4.7.0 TLS handshake failed.

May 11 yy:yy:yy capella2 sendmail[15971]: STARTTLS=client, relay=aaa.bbb.ccc., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128

Thanks,

David


わざわざ丁寧にありがとう。