さらに厄介なことに、Linux には証明書を操作するためのライブラリが複数あります。
Mozilla の NSS を使用している場合は、certutil の -t trustargs を使用して、証明書を積極的に信頼しない (用語) ことができます。 オプション:
$ certutil -d <path to directory containing database> -M -t p -n "Blue Coat Public Services Intermediate CA"
Firefox の場合、<path to directory containing database> 通常は ~/.mozilla/firefox/<???>.profile です どこで <???> いくつかのランダムに見える文字です。 (certutil は、たとえば、ubuntu の libnss3-tools パッケージにあります)
内訳は次のとおりです。
-M データベースを変更する
-t p トラストを禁止に設定する
-n 指定された証明書に対して操作を実行する
NSS 内であっても、すべてのアプリケーションが同じデータベースを共有しているわけではありません。そのため、このプロセスを繰り返さなければならない場合があります。たとえば、Chrome で同じことを行うには、-d <path> を変更します。 -d sql:.pki/nssdb/まで .
$ certutil -d sql:.pki/nssdb/ -M -t p -n "Blue Coat Public Services Intermediate CA"
ただし、すべてのアプリケーションが NSS を使用しているわけではないため、これは完全なソリューションではありません。たとえば、OpenSSL ライブラリでこれを実行できるとは思えません。
結果として、OpenSSL を使用して証明書チェーンの構築 (TLS、IPSec など) を提供するすべてのアプリケーションは、Blue Coat 証明書を使用してチェーンを信頼し、署名したルート CA を削除する以外にできることはありません。トラスト アンカー ストア (インターネットの半分を信頼しないことになるので、Symantec ルート CA であることを考えるとばかげているでしょう) に対して、NSS に依存するアプリケーションは、Blue Coat 証明書を含むチェーンを信頼しないように、より詳細に構成できます。 .
たとえば、OpenVPN は証明書のライブラリとして OpenSSL を使用していると思います。そのため、OpenVPN を使用する商用 VPN プロバイダーに接続している場合、兄貴が知らないうちに OpenVPN トラフィックをリッスンしている可能性があります。それが本当に心配なら、あなたの商用 VPN プロバイダーのルート CA が誰であるかを確認してください。もしそれが Symantec/Verisign なら、他の誰かのためにそれらを捨てる時が来たのではないでしょうか?
SSH は X509 証明書を使用しないため、Blue Coat MITM 攻撃を心配することなく、SSH を使用して接続およびトンネリングできることに注意してください。