web-dev-qa-db-ja.com

IPSecを構成して、少なくとも現在のStunnel構成と同等の保護を提供するにはどうすればよいですか？

クラウドプロバイダーのプライベートネットワーク（プライベートIPアドレススペースの使用と同様）では、他の顧客が同じプライベートネットワークにアクセスできます。 Stunnelが提供するTLSを使用して、多くのホストとサービス間の通信を保護しました。

背景：現在のStunnel構成

現在の状況を簡略化するために、2つのノードA（IPアドレス_IP_A_）とB（_IP_B_）の間の通信に焦点を合わせます。ホストAからのスタンネルの例：

_; [ This config only shows the crypto-relevant parts ]

; Disable support for insecure SSLv2 protocol and low-strength ciphers
ciphers = TLSv1.2:TLSv1.1:TLSv1:SSLv3:!SSLv2:!SSLv1:!LOW:!eNULL:!aNULL:!ADH:!EXP:!MD5@STRENGTH
sslVersion = TLSv1

; The following options provide additional security at some performance penalty
; Default ECDH/DH parameters are strong/conservative, so it is quite safe to
; comment out these lines in order to get a performance boost
options = SINGLE_ECDH_USE
options = SINGLE_DH_USE

verify = 2

[my-service-B]
client = yes
accept = 127.0.0.1:15674
connect = IP_B:15675
CApath = /etc/stunnel/ssl/my-service/certs
CRLfile = /etc/stunnel/ssl/my-service/ca-crl.pem
cert = /etc/stunnel/ssl/my-service/certs/my-service-cert.pem
key = /etc/stunnel/ssl/my-service/private/my-service-key.pem
_

ホストBのStunnel構成は同じですが、サービスセクションが次のように置き換えられています。

_[my-service-localhost]
client = no
accept = IP_B:15675
connect = localhost:15674
; [ … the key and certificates are the same … ]
_

証明書は2048ビットのRSAキーを使用します。ログにデバッグ出力を含めると、Stunnelがレポートする

_Could not load DH parameters from /etc/stunnel/ssl/my-service/certs/my-service-cert.pem
Using hardcoded DH parameters
DH initialized with 2048-bit key
ECDH initialized with curve prime256v1
_

起動時。さらに、ホストAが接続すると、ログにエントリが含まれます

_SSL accepted: new session negotiated
Negotiated TLSv1/SSLv3 ciphersuite: ECDHE-RSA-AES256-SHA (256-bit encryption)
_

IPSec

ここで、IPSec認証ヘッダー（AH）、カプセル化セキュリティペイロード（ESP）、およびセキュリティポリシーに使用される暗号化アルゴリズムとキーの両方に関して、どのIPSec構成が上記のTLS/Stunnel構成と同じレベルのトランスポートセキュリティを提供するのかと思います。 ？ IPSecは影響を受けるホスト間のすべてのネットワークトラフィックを保護しますが、TLSは構成されたポート/アプリケーションのトラフィックのみを保護することを知っているので、それは私が求めていることではありません。

setkey(8)のマニュアルページによると、AHで使用できる認証アルゴリズムは次のとおりです。

_algorithm       keylen (bits)
hmac-md5        128             ah: rfc2403
                128             ah-old: rfc2085
hmac-sha1       160             ah: rfc2404
                160             ah-old: 128bit ICV (no document)
keyed-md5       128             ah: 96bit ICV (no document)
                128             ah-old: rfc1828
keyed-sha1      160             ah: 96bit ICV (no document)
                160             ah-old: 128bit ICV (no document)
null            0 to 2048       for debugging
hmac-sha256     256             ah: 96bit ICV
                                (draft-ietf-ipsec-ciph-sha-256-00)
                256             ah-old: 128bit ICV (no document)
hmac-sha384     384             ah: 96bit ICV (no document)
                384             ah-old: 128bit ICV (no document)
hmac-sha512     512             ah: 96bit ICV (no document)
                512             ah-old: 128bit ICV (no document)
hmac-ripemd160  160             ah: 96bit ICV (RFC2857)
                                ah-old: 128bit ICV (no document)
aes-xcbc-mac    128             ah: 96bit ICV (RFC3566)
                128             ah-old: 128bit ICV (no document)
tcp-md5         8 to 640        tcp: rfc2385 (tcp-md5 support only on BSD)
_

ESPで使用できる暗号化アルゴリズムは次のとおりです。

_algorithm       keylen (bits)
des-cbc         64              esp-old: rfc1829, esp: rfc2405
3des-cbc        192             rfc2451
null            0 to 2048       rfc2410
blowfish-cbc    40 to 448       rfc2451
cast128-cbc     40 to 128       rfc2451
des-deriv       64              ipsec-ciph-des-derived-01
3des-deriv      192             no document
rijndael-cbc    128/192/256     rfc3602
twofish-cbc     0 to 256        draft-ietf-ipsec-ciph-aes-cbc-01
aes-ctr         160/224/288     draft-ietf-ipsec-ciph-aes-ctr-03
camellia-cbc    128/192/256     rfc4312

Note that the first 128 bits of a key for aes-ctr will be used as AES
key, and the remaining 32 bits will be used as nonce.
_

もちろん、AHとESPアルゴリズムとキーの長さのいくつかの組み合わせが上記のSTunnel構成と同等のセキュリティレベルを提供する場合、私はより高い帯域幅とより低いCPUのために最適化したいと思います-使用法。

さらに、（ほぼ）同等のTLSとIPSec構成のペア（アルゴリズムとキーの長さ）のリストはありますか？

更新

上記の「セキュリティのレベル」を書いたとき、おそらくもっと具体的で、「セキュリティの強さ」や「セキュリティのビット」などの概念を参照していたはずです。これは、米国国立標準技術研究所（NIST）で定義されています。 NIST Special Publication 800-57：Recommendation for Key Management – Part 1：General（Revision 3） ：

暗号化アルゴリズムまたはシステムを解読するために必要な作業量（つまり、操作の数）に関連付けられた数値。この勧告では、セキュリティ強度はビットで指定され、セット{80、112、128、192、256}からの特定の値です。

ただし、ビットのセキュリティは、特定の暗号に使用される鍵長と（必然的に）等しくないことに注意してください。さらに、「5.6.1同等のアルゴリズムの強み」のセクションでは、次のように述べています（強調は私が追加したものです）：

[...] 2つのアルゴリズムは、「アルゴリズムを壊す」か、または決定するために必要な作業量がある場合、指定されたキーサイズ（XおよびY）に対して同等の強度キー（指定されたキーサイズ）は、指定されたリソースを使用した場合とほぼ同じです。与えられた鍵サイズのアルゴリズムのセキュリティ強度は、伝統的に、鍵サイズが「X」の対称アルゴリズムのすべての鍵を試すのにかかる作業量の観点から説明されています「ショートカット攻撃はありません（つまり、最も効率的な攻撃は、考えられるすべてのキーを試すことです）。

したがって、上記のTLS/Stunnel構成と同じレベルのトランスポートセキュリティを提供するIPSec構成を尋ねたとき、答えはおそらく、前述のように、Stunnelによってネゴシエートされた暗号の暗号化強度と、 IPSecセキュリティモデルとTLSセキュリティモデルが暗号の有効性やトランスポートセキュリティ全体にどのように影響するか。

tlsnetworklinuxserveripsec
3
Martin Thorsen Ranang

さて、どちらのIPSec構成が上記のTLS/Stunnel構成と同じレベルのトランスポートセキュリティを提供するのでしょうか。

2つの完全に異なるテクノロジー間で「同じレベル」を盲目的に探すことは、多かれ少なかれ意見です-存在する意味のある測定値の単一の包括的なセットに気づいていません。

iPSec認証ヘッダー（AH）に使用される暗号化アルゴリズムとキー、

あなたが提供したリストから、私はstunnelのECDHE-RSA-AES256-SHAがhmac-sha1と最も同等であると推測します。少なくともhmac-sha256に移行することをお勧めします。

セキュリティペイロードのカプセル化（ESP）

指定したリストから、stunnelのECDHE-RSA-AES256-SHAは、長さが288のaes-ctrと最も同等です。ヨーロッパまたは日本にいる場合は、camellia-cbcを長さの256に置き換えてください。ツバキ亜種はそれらの標準です。

とセキュリティポリシー？

通常、代わりにOpenVPNを使用しているため、その部分にはお答えできません。申し訳ありません。

1
Anti-weakpasswords