あきネット

フリーソフトウェアやオープンソースをはじめ、コンピューターやインターネットに関するTIPSや話題を扱います

北のまちから南のまちへと素敵な何かを届けます。
それは、六花かもしれないし、ナナカマドの実かもしれないし、雪の下キャベツかもしれません。

Postfix で Let's Encrypt の証明書をちゃんと使う

とても御無沙汰になってしまいました。


普段は使わない Windows 10 のアップデートを久々にしていたら1日かかったりしていました。(パソコンは1台しかないマルチブートなので、アップデートで「数回再起動します」とかいって使えない時間がかなりあったり。)


Postfix のポート番号増設 ( master.cf )


先日書いたように、(【日記】スタードメイン無料サーバーはメール非対応)
Google Compute Engine (GCE) の「インスタンス」(サーバ)からメール送信をするのに、OP25B (Outbound Port 25 Block) がかかっているため、SendGrid のポート2525で送信するようにしました。
しかし、よその業者を無駄に経由するのも厭だし、送信数制限が月ごとにあるため、 SendGrid を使いたくないと思い、
別の VPS で動かしているメールサーバ (Postfix) で25番以外の特殊なポート番号を追加して、そちらを使うように変更しました。


ポート番号の増設はそれほど難しいものではありません。
Postfix の設定ファイルは、はじめはとっつきにくいですが、マニュアルを読めば master.cf のシンタックスは単純なことがわかります。


また、ここにも書いてあります。


16. How can I get Postfix to listen on a port other than 25?


Set the port in an smtpd entry in the master.cf file. You can change the existing smtpd entry or add an additional one depending on what you need.


An entry like the following causes Postfix to listen on port 10025:


10025 inet n - n - - smtpd


行を追加すればよく、行の最初の項目は(smtps や submission のようなサービス名でなく)ポート番号でも指定可能です。


今回は、GCE のインスタンスの外部IPアドレスを $mynetworks に追加したので、
-o smtpd_recipient_restrictions=permit_mynetworks,reject
のオプションだけで、SMTP認証なしの簡単な設定にしました。
送信元を制限してしまえば、パスワード認証がなくたって、よそには使われません。
シンプルです。


Postfix で Let's Encrypt の証明書を使って TLS 接続する


手間取ったのが、 Let's Encrypt の証明書を使って、確実にTLS (旧称 SSL) 通信をする設定です。
今回は、GCE は Debian で、最終的にメールを受け取る VPS は CentOS です。


証明書の取得方法 (Certbot とか)については略。(ACME クライアントによって操作も異なりますし)


GCE (Debian) の /etc/postfix/main.cf の該当箇所


# 送信
# 今回は $relayhost にしか送らないので常に TLS
smtp_tls_security_level = encrypt
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# 確認のためログをとる
smtp_tls_loglevel = 1

# 受信
# 可能ならば TLS 通信
smtpd_tls_security_level = may
smtpd_tls_CApath = /etc/ssl/certs
# Let's Encrypt の 公開鍵はフルチェイン(中間CA証明書付き)で
smtpd_tls_cert_file = /etc/letsencrypt/live/gce.example.com/fullchain.pem
# サーバの秘密鍵
smtpd_tls_key_file = /etc/letsencrypt/live/gce.example.com/privkey.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
# 証明書の検証を求める
smtpd_tls_ask_ccert = yes
# 確認のためログをとる
smtpd_tls_loglevel = 1


解説

1.(注:混同したり見間違えたりして片方を忘れがち)
Postfix では、送信と受信で、smtp_* と smtpd_* というように設定項目が別々にわかれます。
送信でも受信でも TLS 通信させたいのであれば、それぞれに設定が必要です。
typo でもなんでもなく、別々の設定項目です。
忘れないように整頓して main.cf を書くようにしたほうがよいです。

2.
今回は、送信先になるのは VPS の Postfix 1台だけで、そちらは TLS 通信には対応しているので、送信は常に encrypt します。
こういう用途ではなく送信相手が限定されない一般的なメールサーバならば may が適切です(世の中にはTLS通信しないメールサーバもあるので、TLS通信に失敗するとメールが送れなくて困る)。

3.(注:これを忘れると、下記4に書いた証明書の検証がうまく機能しない)
smtp_tls_CApath と smtpd_tls_CApath に指定しているのは、一般に信頼する認証局の証明書が置いてあるディレクトリです。
Debian では、 /etc/ssl/certs に置いてあります。

/etc/ssl/certs に、Let's Encrypt のCA証明書も保存しておきます

  • ISRG Root X1 (self-signed)
  • Let’s Encrypt Authority X3 (IdenTrust cross-signed)
  • Let’s Encrypt Authority X3 (Signed by ISRG Root X1)
の3種類が現在使われているCA証明書ですが、
このうち最低でも "Let’s Encrypt Authority X3 (IdenTrust cross-signed)" は必要です。この証明書に署名している "IdenTrust DST Root CA X3" は一般にインストール済なので。
とはいえ、私は自信がないので、3種類とも /etc/ssl/certs に保存しました 😁

どういうことかというと、
Let's Encrypt 自身の証明書は、本来は、 Internet Security Research Group が署名しているものです。ところが、この ISRG の証明書は、ウェブブラウザやOSなどによっては、インストールされていないこともあるのです。
そこで、IdenTrust という既存の認証局が署名した証明書も用意されているわけです。



4.(注:この情報が見つかりにくかった)
smtpd_tls_ask_ccert = yes にしないと、通信相手(クライアント)に対して自分の証明書の検証を求めないため、暗号化はされるものの、(TLS証明書の意義のひとつである)なりすまし検知の機能がなくなります

ちなみに、クライアント側のログには
検証されていないときは: Untrusted TLS connection established to ...
検証されたときは: Trusted TLS connection established to ...
記録されます。
なりすましがされていないことが検証されたら、trusted (信頼された)ということになるわけです。
いずれでも、暗号化はされています

5.(注:デフォルトでは、TLSのログだけが載らなくなってしまう
今回は、TLS 通信に成功しているか確認するため、ログもとります。
(loglevel を設定しないと、ログ (/var/log/mail.log) に載りません。)

受信先 (CentOS)の /etc/postfix/main.cf の該当箇所


smtp_tls_security_level = may
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_loglevel = 1

smtpd_tls_security_level = may
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_ask_ccert = yes
smtpd_tls_loglevel = 1

解説

同じ Postfix なので、Debian とは概ね共通ではあります。

1.
よそにもメールを送信するため、smtp_tls_security_level = may です。
ちなみに、smtp_tls_security_level = may は、旧バージョン(2.2)では smtp_use_tls = yes でした
2.3以降でも、 smtp_use_tls = yes と書けば smtp_tls_security_level = may と同じ効果はありますが、smtp_tls_security_level = may に書き換えてしまうべき

smtpd_use_tls と smtpd_tls_security_level の関係も同じ



2.(注:この情報を載せているウェブサイトが特に少なかった)
RHEL/CentOS/Fedora 系は、Debian とは CA 証明書の扱いが異なります
CA証明書は、 Debian系と異なるディレクトリにあります。
しかも、後記の通り独特の設定方法があるので、ディレクトリでなくファイルを指定します。

smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt


このファイルに対して、例の Let't Encrypt のCA証明書を追記すればよいのですが、
正しい追記のしかたは、

  1. /etc/pki/ca-trust/source/anchors に証明書ファイルを置く
  2. # update-ca-trust の実行 (root 権限)

です。


QUICK HELP 1: To add a certificate in the simple PEM or DER file formats to the list of CAs trusted on the system:


add it as a new file to directory /etc/pki/ca-trust/source/anchors/

run update-ca-trust extract


update-ca-trust で、/etc/pki/tls/certs/ca-bundle.crt が再生成されます。



メールクライアント(メーラ)からの通信は、証明書を検証不能


メールクライアントはメールサーバに、メール送信を依頼するわけですが、
メールクライアントは、認証局が署名した証明書なんて持っていないのが普通です。


これは、ウェブブラウザとおんなじですね。
ウェブサーバは TLS 証明書を認証局から発行してもらいますが、
ウェブブラウザ(クライアント ; user-agent )を使っているときの我々って、証明書を発行してもらったおぼえなんてないですよね😂


つまり、ウェブサーバから見て訪問してくるウェブブラウザも匿名なのと同じで、
メールサーバから見て、メールクライアントは匿名(anonymous)です。


よって、メールサーバのログには、
Anonymous TLS connection established from...
というように載ります。
メールクライアントからの通信では、これが正常です。


相手が誰かわからないわけですが、通信自体は暗号化されています



「新入生は毎年入ってくる」とGreg KH (Linux 4.19 リリース)

Linus Torvalds は気に食わないことがあるとしばしば怒って、メーリングリスト内で罵倒するということを起こしてきました。
そのたびに、罵倒されたほうがおそれをなすのはもちろんのこと、メーリングリストを読んでいる人のなかにも震え上がる人もいました。
一方で、「またやっているよ」くらいにわらっている人もいるわけではありますが。


Torvalds は、下手なコードに対してもですが、ソースコードが長くなったり性能が落ちたりすることに関して、過剰なくらい敏感です。
そのたびに怒り喧嘩腰のやりとりになり、耐えられなくて居なくなってしまう人もいままで何人もありました。


ところが、重要な会議を忘れてプライベートをダブルブッキングしてしまい、会議のほうの開催地を変更するという失態をやらかしてしまって、いよいよ非難を受け、
4.19 の制作期間中に休暇(実質的には謹慎)になりました。


代わりに 4.19 を担当したのは、いつもはリリース後のバージョンを担当している Greg Kroah-Hartman です。


彼はまた、Linux カーネルコミュニティでは新人を指導してきました。


その 4.19 が先日完成しました。



I've been giving my "How the kernel is developed" talk all around the

world for over a decade now. After the first year or so, I was amazed

that it kept needing to be given as surely everyone knew how we did this

type of thing, right? But my wife, someone much smarter than I, then

told me, "Every year there is a new kindergarten class."


日本では、幼稚園に通ったことのない人も多いでしょうが、小学校に通って卒業した人はほとんどでしょう。
新1年生がいるかぎり、毎年、新学級があります。


人は死にますから、世代交代は必ずあります。
生まれてこなくならないかぎり、常に新世代があって、新人があって、若者があって、初心者があります。


その初心者に対して「こんなこともわからないのか!」って罵倒する上司、誰もがその上司におもねる、そうして「恐怖政治」が布かれる社会というのはどうなのでしょうか。


そしてそうなると、能力を高めるというよりもむしろ、
イジメ、ハラスメント、吊上げで、居られなくなったりします。
組織の憂さ晴らしにさんざん利用されたあげくに、追い出されてしまいます。


そうした現象は日本でも日常茶飯事ですが、Linux カーネルの共同体にもいくらか起こっていたということです。
そして、そうしてわざわざイジメ、ハラスメント、虐待をしておきながら、「これがオレ流」と居直るというところが少なくありません。自浄作用がないのです。
それで結局は、その組織は新陳代謝がなくなり腐敗し、人は劣化していきます。



毎年毎回、ジェンガか石積みみたいに同じように、初心者を指導し続けるのは、途方もなくて、
「俺はそんな暇ないんだ」と思っている人もいるでしょう。
しかし、そうして指導しなければ、次世代は育たないのです。




初心者がいつまでも初心者で、幼いまんまで、その幼いまんまの人々を利用するという社会システムを、拝金資本主義のポピュリズム社会は続けてきました。わざとですよね。


例えば Windows や iPhone にせよ、中身がわからないですよね。
それで、初心者は「教科書」を見よう見まねで「コピペ」して、いつまでも成長しない。
けれど、それで、商品が売れる、書籍が売れる。
結果さえよければいい人はどうしてもいますけれど、わざと成長させないようにして「カモ」にしつづけることで稼いでいる社会があるのです。


「コピペ」ですから、「劣化コピー」になります。
社会も、成長せず、退化していくのです。
社会構造と、カネのために、人がバカになっていくのです。


世代交代が続くからには、初心者はいなくなりません。
しかし、脱初心者がなければ、初心者は増える一方でしょう。


ほとんど誰しも幼い頃はあるでしょうが、そこから大人にならないまんま、幼稚なまま、ということですね。



Linus Torvalds はプログラマの技能としてはともかく、
人格としてはまだ幼いまんまで、長になってしまった、というところがあったのでしょう。


Greg KH のほうが人格者で、なんだか、人がついてくる指導力が高いように思えます。



Linux はもう、 Torvalds の私物でもなければ、既存の制作者のものでもなくて、
全世界で多数の人々が使っています。
Android にも入っていますし。
実際にもう、Linux は全世界の人々のものなのです。
そして、制作にも門戸は開かれていて、開かれていなければならず、そして常に新人が入ってきます。
新人を事実上追い払って、気に食う奴だけ選別して残すようでは、この構造は破綻してしまうでしょう。


そのあたりの直観力と論理性が、 Greg KH にはよく備わっているようですね。


Mozilla Firefox 63.0 が登場

Mozilla Firefox 63.0 がリリースされましたね



63.0 では、追跡目的の Cookie のみをブロックする(しようとする)機能など、コンテンツブロッキング機能が追加されています。


いままでは

  • Cookie をすべて受け入れる
  • サードパーティー Cookie を拒否する
  • Cookie をすべて拒否する

の3択を前提に、各サイトごとに例外を設定可能でした。
サードパーティー Cookie を拒否する設定だと、閲覧に支障が出るウェブサイトがあったり、利用不可能になってしまうウェブサービスがありました。
(例外を設定すればいいのですが、 Firefox は Cookie の例外設定がやりづらいうえ、必要なサードパーティーの Cookie を見つけ出すのには自力で調べないといけません。以前は Cookie の例外設定がやりやすくなるアドオン(Cookie Controller) があったのですが、Firefox のバージョンがあがったのに対応することなく終了。)


それが、あくまでも Mozilla を信用するという前提でしょうが、
追跡目的 ( Tracker ) Cookie のブロック機能を利用すれば、支障の起こらない Cookie だけに限定してブロックしようとするようになります。


「あくまでも Mozilla を信用する前提」と書いたのはつまり、このブロッキング機能を利用するには Mozilla に対して照会する必要があるだろうからです。


   


トラッキング防止機能は、Disconnect 社により提供されているトラッキングの識別とブロックのためのリストを利用します。



まあ実際には、トラッキングブロッキング機能だけではなく、フィッシングとマルウェア予防機能を利用する場合にも、Mozilla に情報を照会します。



偽装サイトとマルウェアからの防護機能は、偽装サイトやマルウェアのサイト、望ましくないソフトウェア、マルウェアのサイトとして報告されたリストを基に、ユーザーが訪問したサイトと照らし合わせることで動作します。これらのリストは自動的にダウンロードされ、30 分ごと、またはこの機能が有効化された時に更新されます。


Firefox とプライバシー


プライベートウインドウ

以前からとっくに実装されているものに「プライベートウインドウ」がありますね。
アクセス履歴を保存せず、 Cookie も保存されずウインドウを閉じたら消え失せる機能です。
この機能でもっても、IPアドレスやブラウザの情報などは訪問先に記録されるでしょうが、
アクセス記録が手元には保存されないので、追跡が困難になるという効果はあります。

DNS over HTTPS

ちなみに Firefox は、DNS over HTTPS も公式に実装予定です。
DNS でドメインを引くのには通常は UDP 53 ポート(あるいはTCPということもあるでしょう)を利用しますが、暗号化されていません。
よって、 DNS の問合せのやりとりを HTTPS を通じて行うことで暗号化しようというわけです。


そのためには対応するDNS兼HTTPSサーバが必要です。
Firefox では、ネットワーク設定のなかに「DNS over HTTPS を有効にする」の項目があるので利用可能ですが、
そこにデフォルトで入っている設定 (https://mozilla.cloudflare-dns.com/dns-query) は Cloudflare のサーバを利用するものです。
あくまでもCloudflare と Mozilla を信用するという前提ですね。




DNS問合せも暗号化してしまうと、途中経路には盗聴されないということになります。


いずれにせよ、訪問先には自分を隠せません。


VPN 実装予定

盗聴防止に関しては今後、 Mozilla も VPN を(有料で)提供予定のようです。 10 USD はちょっとたかいですね。 VPN プロバイダは ProtonVPN です。


VPNを通せば、自分の IP アドレスは隠蔽されるでしょう。(ブラウザの種類や画面の大きさなどはおそらく隠蔽されませんが。)

Firefox の ProtonVPN は、元は 8 USD の Plus プランなので、 Tor にも対応しているようです。





今日のニッキ

にほんブログ村のランキングが壊れていて、このブログの順位が圏外の表示になりっぱなしです。
# 基地局が停電なのでしょうか😂

スタティックデータはおそらくリバースプロキシなど活用してでもスムーズに表示されているので壊れていないようにみえますが、動的な部分は重症とみえます。

こんな昔のシステムとデータベースならば、通常は停めてでも全面リニューアルをすべきだと思うのですが、
ムラウチの社運がおそらくかかっている案件なので、
長期停止メンテナンスのうえリセットして新サイトにやり直し、っていうことはしないのでしょうね……