2025年05月10日(土) - 19:42 | カテゴリ:
Linux
PCとサーバの通信制御用にSquidを使っており検証用にSSL復号化(SSL Bump)も利用している筆者。
約3年前にSSL Bumpを構築してから放置してたが、証明書が期限切れとなり通信出来なくなった。
通信出来ないとWebサイトを閲覧出来ない上、通信を追いかける調査にも支障が出るので更新してみた。
SSL Bumpの設定方法はSquid wikiを見て貰うとして、
証明書更新で問題になるのがSSL Bumpで必須となるSSL証明書の自動生成キャッシュだった。
SquidでSSL Bumpを実行するには、Squid本体が中間者攻撃の様にインターセプトする動作となるので、
PC ⇔ Squid・Squid ⇔ サーバで通信セッションを都度作り直す事となる。
SSL Bumpを動かすにはSSL復号化用のオレオレ証明書を作成し、
認証局の証明書をPC、サーバ証明書をSquidにインストールする必要があるのだが、
サーバ証明書を更新してもSquidが保持するSSL復号化用の証明書キャッシュを更新してくれないため、
Webブラウザでガチの中間者攻撃と検知されてしまい通信が出来なくなる。
………
Squidのcacheログには次のログが出力されるのみで内容を判断しにくい状態となっており、
フォーラムでもOpenSSLの出力するログなので、Squidでは無くOpenSSLを見る様に書かれている。
| Error negotiating SSL connection on FD 1: error:00000001:lib(0):func(0):reason(1) (1/-1) RSA |
一概にズバリと解消できる方法は無いのがコレだが、
筆者の環境ではSquidの保持するSSL復号化用の証明書キャッシュを完全初期化する事で直った。
SSL復号化用証明書のキャッシュ保存先ディレクトリが “/var/cache/squid/ssl_db” の場合、
フォルダを削除した後に次の初期化コマンドを打ち込めばエラーが直るはず。
コレでもエラーが直らなかった場合は、証明書の生成コマンド自体を見直せば不具合が解消出来るかも。
rm -rf /var/cache/squid/ssl_db
security_file_certgen -c -s /var/cache/squid/ssl_db -M 4MB
chown -R squid.squid /var/cache/squid/ssl_db |
コマンドを打ち込んでSSL Bumpのキャッシュディレクトリを初期化した後は、
今まで通りにWebサイトをSSL復号化しつつ閲覧できた。
今の時代、SquidでSSL復号化をするケースは少ないかもだがTIPSとしてメモしておく。
« 続きを隠す
2025年05月03日(土) - 00:04 | カテゴリ:
Linux
筆者の自鯖でもメールは運用しており、何処からでも利用できる様にWebメールも備えている。
従来はWebフロントエンドにRainLoopを利用していたのだが、
OSSの更新が滞ってしまったのと、かと言って自力で開発する熱意まで昇華できず乗り換えを探していた。
先日、別のドキュメントを探している中でRainLoopの後継アプリケーションとなるSnappyMailの存在を知り、
調べてみると色々とメリットも多かったためWebフロントエンドを載せ替える事となった。
という事で、RainLoopからフォークしたアプリケーションとなるSnappyMailへ移行してみた。
OSSのWebメールと言われると真っ先にRoundcubeが上がる位には有名で、
エンタープライズ向けなら昨今話題のActive! mailは採用実績が多いと思われる。
教育機関だとZimbraの採用も多いらしいが、Microsoft 365に切り替える所が多いと聞いた事あるので、
今後はSaaSに移るケースがより増えていくのかもしれない。
それらのメジャー所に比べて、RainLoopは無名に近くSnappyMailは情報皆無だが、
必要最低限の機能が卒なく実装されていて動作も軽いため筆者はRainLoopを採用していた。
今回、SnappyMailへ乗り換える決め手になったのはGUIがRainLoopに近くてシンプルかつ使いやすいのと、
プラグインも互換性のある物が多く改修すれば使える事が多いのが決定打となった。
SnappyMail全体の設定項目は結構増えてるものの、
ドキュメントを読まずに項目名を読むだけでも設定が出来る程度には纏まっている。
また、RainLoopでは開発中の機能だったり、オプション実装だったSieveにも正式対応してたりするので、
必要最低限の機能を短時間で利用するには良い選択肢になると言えそう。
OSSで大規模なWebメールならRoundcubeが候補になってくるが、
アカウント少な目な小規模環境で管理負荷を下げつつも最新機能を使いたいなら、
SnappyMailはハマる可能性が高いので是非とも使って見て欲しい。
………
最大の課題はSnappyMailの情報が全くなく、ググっても出てこない事。
公式ドキュメントか技術ブログを読めば設定はなんとかなる。
それでもダメな場合はソースコードを読む必要が出るので覚悟が必要になって来るかも。
切り替えてから丸一日が経過しているが、
メール送受信は勿論のことフィルタリング修正などオプション機能も普通に使えている。
また、やる気を出せばログイン画面をreCAPTCHA対応させたりワンタイムパスワード化も出来るので、
セキュリティ観点でもメリットが十分あると言えそう。
まだまだ使って見る必要はあるが、ひとまずは連休の自由研究その1が無事終了となった。
その2として無線AP載せ替えがあるのでコチラは引き続き着手する予定。
« 続きを隠す
2025年04月26日(土) - 20:57 | カテゴリ:
Linux
今までも検証用にDNSドメインを運用しており直近にもドメインを追加購入していた。
権威DNSの技術検証には本番系のDNSドメインと自前のサーバを用いるものの、
SaaSの挙動を見る場面もあり今回が該当した。
無料・有料に限らずDNSホスティングサービスを検討していたが、
今回はCloudflareに乗せる事にしたので委任してみた。
以前から利用しているDNSドメインでもCloudflareを使っているので、
今回の追加分含め2個のドメインを管理する事になった。
追加したドメインで登録しているDNSレコードは悪用防止用の自衛レコードだが、
一部のサービス用にワイルドカードレコードを使っているのと、
そもそもドメイン名が短くタイポ含めた相応のDNSクエリが来そうな事もあり、
権威DNSが耐えられる様にする意味でもCloudflareが最適と考えた。
………
レジストラには長年お世話になっているValue Domainを採用したので、
DNSSEC用のDSレコードも設定をしてみた。
上位DNSにDSレコードが登録されるのに時間がかかったが、
Cloudflareの値とも同期がとれて無事に応答が返って来る様になった。
自前でDNSSECを作るのも可能だが大変なので、SaaSだからこそ手軽に出来る物の一つと思う。
