TLS 1.0の非推奨と軽減策
TLS 1.0の廃止が間近に迫っていることから、時代遅れのクライアント環境における接続とメール配信の問題を他の人がどのように処理しているかに興味があります。
それに直面してみましょう。最新かつ最高のアップデートを実行している環境よりも、廃止されたプロトコルを実行しているインターネット上に多くの環境が存在します。これらのユーザーからの「重要なビジネスメール」をどのように処理し、セキュリティを維持しますか？
セカンダリゲートウェイを設定して、安全性は低いがより厳密に調査された状態で着信メールを受け入れることを検討しましたが、プライマリ環境では無効にできない可能性があると言われています。
結局、私の質問は、エンドユーザーがメールを送信できないというレポートの受信を開始したときに、「アップグレードが必要」が有効な応答であるかどうかです。
「アップグレードする必要があります」は絶対に有効な応答です。 TLS 1.0は1999年に定義され、約20年になります。今日の標準で安全であると考えられているTLS 1.2は、2008年以来存在しており、遅い企業でさえ移行するのに十分な時間があります。
しかし、バージョン番号だけでは、マネージャーが古いシステムのアップグレードを注文することはできません。これは費用対効果分析であり、この場合は非常に簡単です。
TLS 1.0を使用することは、高いセキュリティリスクです。 POODLEやBEASTなど、TLS 1.0に対する十分に開発された攻撃がいくつか存在します。サーバーがアップグレードされていないと、電子メールが危険にさらされる危険があります。
個人的には、証明できるほど弱い暗号化をサポートすることはセキュリティリスクと考えます。また、このようなセキュリティリスクに関与することは、特にアップグレードが必要な警告が非常に多いため、ある企業がそうしたくない、またはできないという理由だけで正当化するのは困難です。
私が過去に取り組んでいたMTAで使用したテクニックについて説明し、あなたが作ることができるもののアイデアを得るでしょう。 TLS1.2バージョンをサポートせず、古いTLSバージョンのみをサポートする古いMTAと同じ問題が発生しました。このMTAはTLSのopensslライブラリを取得し、使用された宛先IP、ドメイン、およびTLSバージョンに応じて、管理者が接続を許可または拒否できるいくつかのセキュリティポリシーを使用していました。これにより、管理者は他のシステムにあまり影響を与えずに古いMTAを処理できます。そのため、インバウンドトラフィックの場合、一部のお客様は接続でTLS1.2を許可するだけで、アウトバウンドの場合は、tlsバージョンをIP /ドメインと組み合わせて使用することで、制限が少し緩和されます。