web-dev-qa-db-ja.com

SSL認証が予期せず失敗する-これはSSLインスペクション/フォーティネットが原因である可能性がありますか？

私は数日間私を悩ませてきたSSLの問題を扱っています。私はセキュリティについてほとんど知らないので、ここに誰かが助けを貸してくれるなら、私は非常に感謝します。

最終的に私がやろうとしていることは、特定のHelmリポジトリをKubernetesデプロイメントに追加することです。これは私のテスト環境（AWS）では問題なく機能しましたが、SSLの問題により、私の実稼働環境（クライアントによって提供されるオンプレミスのクラスター）では失敗します。具体的には、私が実行しているコマンドは次のとおりです。

helm repo add polyaxon https://charts.polyaxon.com

そして私が返すエラーは：

Error: Looks like "https://charts.polyaxon.com" is not a valid chart repository 
or cannot be reached: Get https://charts.polyaxon.com/index.yaml: 
x509: certificate signed by unknown authority

これは私を混乱させます：

  1. ローカルまたはAWSで作業しているときにこのエラーは発生しません。
  2. ブラウザで上記のURLにアクセスすると、COMODOによって発行された有効な証明書があるようです。
  3. ポリアクソンはかなり人気のあるプロジェクトであり、これはそれを使用するための基本的なステップです。それでも、他の誰かに起こっているこの単一のインスタンスを見つけることができません。

wget経由でリポジトリにアクセスしようとすると、より役立つエラーメッセージが表示されます。

:~$ wget https://charts.polyaxon.com
--2019-02-22 22:02:53--  https://charts.polyaxon.com/
Resolving charts.polyaxon.com (charts.polyaxon.com)... 104.27.149.134, 104.27.148.134, 2606:4700:30::681b:9586, ...
Connecting to charts.polyaxon.com (charts.polyaxon.com)|104.27.149.134|:443... connected.
ERROR: cannot verify charts.polyaxon.com's certificate, issued by 
\[email protected],CN=FGT37D4615801045,OU=Certificate Authority,O=Fortinet,L=Sunnyvale,ST=California,C=US\u2019:
  Self-signed certificate encountered.
To connect to charts.polyaxon.com insecurely, use `--no-check-certificate'.

これについて興味深い/混乱しているのは、私が知ることができるように、証明書がCOMODOではなく "Fortinet"によって発行されていることです。フォーティネットのことは聞いたことがなかったので、グーグルで調べたところ、SSL証明書を発行するのではなく、強力なファイアウォールなどを提供していることがわかりました。 this や this などのリンクにも出くわしました。これらは関連しているようです。

したがって、この時点での私の理論は、クライアントがネットワークにフォーティネット製品をインストールし、この製品が他では見られない不透明なSSLエラーを引き起こしていることです。しかし、再び、私はここで自分の深みから離れています。私は間違っている可能性が高く、たとえ私が正しいとしても、問題を解決する方法がわかりません。

だからと言って、私の質問は：

  1. 何が起こっていると思いますか？
  2. どうすれば修正できますか？

参考になれば、オプション here 。を介して明示的に証明書をhelmに渡すことができます

tlsauthenticationcertificatescertificate-authority
2
JJL

最初にクライアントと通信します。SSL検査のために意図的に構成されたFortinetアプライアンスを持っているかどうかを尋ねます。誰もがフォーティネットアプライアンスのように見える自己署名CAを作成する可能性があるため、これは、これを本物の中間者攻撃（MITM）攻撃と区別する唯一の方法です。

その後、次の選択肢がありますが、これはクライアントと綿密に話し合い、セキュリティと保守性の両方の長所と短所を比較する必要があります。

  1. サーバー全体に例外を追加して、透過的なHTTPSプロキシをバイパスします。 SSLインスペクションは組織内のユーザーがインターネットを自由に閲覧している間保護しますが、サーバーは信頼できるWebサイトにのみ接続する必要があります。

  2. サーバーが必要とするサイトの例外を追加します。これはより制限的です。ある程度のセキュリティが追加される可能性がありますが、場合によっては、より多くの例外を要求する必要があるため、より多くのメンテナンスが必要になります。

  3. クライアントにFortinetアプライアンスのパブリックCA証明書を要求し、このサーバーの信頼されたルート認証局にインストールします。これには、アプライアンスの秘密鍵が危険にさらされるというリスクがあります。また、クライアントがアプライアンスをアップグレードまたは別のアプライアンスに交換する場合も、これを再度行う必要があります。その時点で、古いCA証明書も削除することを忘れないでください。

SSLインスペクションを実行しているかどうかは、すべてのクライアントコンピューターに対して同じように行っている必要があるため、知っておく必要があります。一部の国では、従業員の同意も必要です。

2
Esa Jokinen

一部のフォーティネットアプライアンスは、中間者（MITM）攻撃、またはファイアウォールとネットワークベースの侵入検知システムのコンテキストではTLSインスペクションに相当するものを実行しています。これは、ファイアウォールが暗号化されたトラフィックを検査できるようにするために行われます。 Fortinetデバイスが使用する証明書はクライアントによって信頼されていないため、クライアントは（正当に）証明書の受け入れを拒否し、TLSハンドシェイク中にエラーをスローします。この問題には2つの解決策があります。

  1. ファイアウォールデバイスでTLS検査を無効にします。
  2. ファイアウォールのルート証明書を、関連するすべてのクライアントで信頼できるものとして設定します。

ファイアウォールがクライアントによって管理されておらず、暗号化された接続が削除されていることさえ知らなかった場合に可能である可能性が高い場合、デバイスのルート証明書のインストールと信頼にうんざりしています。ファイアウォールが侵害されるか、証明書が誤って生成された場合（ファイアウォールのソフトウェアが古いか、デバイスがアクティブにメンテナンスされていない可能性が高い）、攻撃者がネットワーク上の任意のデバイスに対して本物のMITM攻撃を実行する可能性が高くなります。

0
forest

フォーティネットはファイアウォールのベンダーであり、これらのファイアウォールはTLSインターセプトもサポートしています。つまり、トラフィックを復号化して再度暗号化することでトラフィックを分析します。これは基本的に、クライアントからサーバーへの単一のエンドツーエンドTLS接続で、ファイアウォールからサーバーへの1つのTLS接続と、クライアントからファイアウォールへの別のTLS接続になります。 TLSの仕組みにより、クライアントからファイアウォールへの接続はサーバーからの元の証明書を持つことができませんが、ファイアウォール上の認証局（CA）によって動的に発行された新しい証明書を持っています。詳細については 会社のSSLプロキシサーバーはどのように機能しますか？ を参照してください。

これを修正するには、ファイアウォールで例外を設定して、特定のターゲットに対して傍受が行われないようにする必要があります。または、インフラストラクチャに信頼できるものとしてファイアウォールのCAをインポートする必要があります。どちらの場合も、ファイアウォールを管理するローカルシステム管理者に連絡する必要があります。つまり、例外を取得するか、インポートできるCA証明書を取得します。

0
Steffen Ullrich