Next: ドキュメントの閲覧, Previous: ホストのセキュリティ, Up: The Emacs Editor [Contents][Index]
Emacsがネットワーク接続を確立するときは、常にその確立された接続をNSM(Network Security Manager)に渡します。NSMは、あなたのコントロールのもとにセットワークセキュリティーを実施する責任があります。現在のところ、これはTLS(Transport Layer Security)の機能を使用して動作します。
変数network-security-level
はNSMが実施するセキュリティーレベルを決定します。変数の値がlow
ならセキュリティーのチェックは行なわれません。これは必須ではなく。基本的にはそのネットワーク接続が信頼できないことを意味しています。しかしネットワークの問題テスト時のように制限された状況ではこのセッティングは便利かもしれません。
この変数がmedium
(デフォルト)の場合、いくつかのチェックが行なわれます。チェックの結果、NSMがそのネットワーク接続を信頼できないと判断した場合は、それを知らせて、そのネットワーク接続にたいして何を行なうか尋ねます。
証明されていない接続(unverified connection)にたいして、永続的なセキュリティー例外(security exception)を登録したり、一時的な例外(temporary exception)とするか、接続を完全に拒絶することができます。
証明書の基本的な正当性チェック加えて、いくつかのTLSアルゴリズムによるチェックが利用可能です。 以前は安全だと思われていたいくつかの暗号化技術で脆弱性が判明しているものについては、(デフォルトでは)Emacsは問題に関して警告します。
プロトコルネットワークのチェックはnetwork-security-protocol-checks
変数を介して制御されます。
これは各連想値の最初の要素がチェックの名前、2つ目の要素がチェックの使用を要するセキュリティレベルであるようなalistです。
関数nsm-protocol-check--rc4
の結果内の(rc4
medium)
のような要素は(nsm-protocol-check--rc4 host port status settings)
のように呼び出します。この関数は接続を継続するなら非nil
、それ以外は非nil
をリターンします。
以下はデフォルトのmedium
で行なわれるチェックのリストです。
その接続がTLS、SSL、STARTTLS接続の場合、NSMは接続しようとしているサーバーの同一性(identity)を証明するために使用される認証が、検証できるかどうかチェックします。
無効な認証が懸念される場合(Man-in-the-Middleによりネットワーク接続がハイジャックて、あなたのパスワードが盗まれるかもしれません)や、とにかく接続を行なう正当な理由があるかもしれません。たとえばサーバーが自己署名された認証(self-signed certificate)を使用していたり、認証の期限が切れている場合もあるでしょう。接続の継続を容認するかどうかの決定は、あなたに任されています。
以前自己署名された認証を許容したが、今回はそれが変更されていて、それはそのサーバーが単に認証を変更しただけかもしれませんが、ネットワーク接続がハイジャックされている可能性もあります。
接続が暗号化されていないが、以前のセッションでは暗号化されていた場合、あなたとそのサーバーの間にSTARTTLSアナウンス(STARTTLS announcements)を剥奪して、接続を非暗号化するプロキシーがあることを意味するかもしれません。これは通常とても疑わしいです。
IMAPやPOP3のサーバーに接続するとき、ネットワーク越しにパスワードを送信するのが一般的なので、接続は通常暗号化されています。同様に、パスワードを要求するSMTPを通じてemailを送信する場合は通常、その接続が暗号化されていることを望むでしょう。その接続が暗号化されていない場合、NSMは警告します。
パグリックキーの交換を行なう際、そのチャンネルが第三者により盗聴できないことを確実にするために、プライムビット(prime
bits)の数は十分に高くあるべきです。この数があまりに低い(low)場合にはEmacsは警告を発するでしょう(これはnetwork-security-protocol-checks
のdiffie-hellman-prime-bits
チェック)。
RC4ストリーム暗号は低品質とされており、第三者による盗聴を許すかもしれません(これはnetwork-security-protocol-checks
のrc4
チェック)。
中間証明書(intermediate
certificate)がSHA1ハッシュアルゴリズムを使用していれば、第三者がその発行インスタンスを偽装して証明書を発行できると考えられています。したがってこれらの接続は中間者攻撃にたいして脆弱です(これらはnetwork-security-protocol-checks
のsignature-sha1
とintermediate-sha1
チェック)。
TLS1.0より古いプロトコルは、様々な攻撃にたいして脆弱とされており、あなたが行なうことがより高いセキュリティーを要する場合は、使用を避けたいと思うかもしれません(これはnetwork-security-protocol-checks
のssl
チェック)。
3DESストリーム暗号は最大112ビットの有効なセキュリティーを提供してローエンド向きと考えられていて、2016年に重大なセキュリティの脆弱性が開示されました(CVE-2016-2183)(これはnetwork-security-protocol-checks
の3des-cipher
チェック)。
network-security-level
がhigh
の場合、上記に加えて以下のチェックが行なわれます:
サーバーはキーを変更するときがあり、通常それは心配することはありません。しかし、サードパーティーのサービスにたいして新しい認証を発行する、偽装しやすい証明期間(pliable Certificate Authorities)へのアクセスをもつエージェントにより、ネットワーク接続がハイジャックされているか心配なときは、これらの変更を追跡したいと思うかもしれません。
最後に、network-security-level
がparanoid
の場合は、最初にNSMが新たな認証に遭遇したときに、それが通知されます。これによりEmacsによるすべての接続のすべての認証を検証することができるでしょう。
以下の追加の変数は、NSM操作の詳細を制御するために使用できます。