web-dev-qa-db-ja.com

TLSは、サポートする暗号について厳密にできますか？

SMTPトラフィックをリレーするためにOutlook.comへのTLSチャネルを確立しようとすると、接続エラーが発生し、暗号化せずに続行する必要があります。

そのような接続の例：

openssl s_client  -starttls smtp -crlf -connect x-com.mail.eo.Outlook.com:25 -CApath /etc/ssl/certs/ -cipher DHE-RSA-AES256-SHA  
CONNECTED(00000003)
139677700306600:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 343 bytes and written 137 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

上記のスニペットによると、DHE-RSA-AES256-SHAを使用してTLSを試みます。 2つの当事者が同意してTLS接続を確立するまで、再交渉を行うべきではありませんか？当事者の1人が必要な暗号とアルゴリズムをすべて使用できない場合はどうなりますか？

tlssmtp
6
George

共通の解決策が見つかるまで、すべての当事者が交渉し、再交渉したバザーとのTLS交渉を混同しないでください。すべてのメッセージは配信に時間がかかるため、非常に遅くなります。したがって、クライアントが希望する順序で、クライアントがサポートしようとするすべての暗号を含む、クライアントによる単一のオファーのみがあります。サーバーがこれらの暗号のいずれかをサポートしている場合、サーバーまたはクライアントの設定に基づいて最適なものを選択します。オーバーラップがない場合、ネゴシエーションは永続的に失敗します。

あなたの場合、サーバーは次の暗号を受け入れます（ このツール によって決定されます）。

ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA

単一の暗号DHE-RSA-AES256-SHAのみを提供し、この暗号はサーバーでサポートされていないため、ネゴシエーションは失敗します。

13
Steffen Ullrich

はい。TLSは、サポートする暗号スイートについて厳密でなければなりません。暗号スイートを注意深く選択しないと、危険にさらされる可能性のある安全でない暗号スイートと交渉するリスクがあります。第三者が標準に準拠した暗号スイートをサポートしておらず、その接続のセキュリティを非常に重視している場合は、システムを低品質の暗号スイートで動作させないでください。

ただし、賢明なTLS実装は複数の暗号スイートもサポートし、他の関係者との互換性の可能性を高めます。さまざまな暗号スイートの弱点に関する最近の多くの暴露にもかかわらず、安全であると考えられるいくつかがまだ残っています。会話の片側のみを制御する限り、システムを1つの暗号スイートのみをサポートするように制限し、インターネット全体が個別の標準に従って動作することを期待するのはばかげたことです。

ここで起こっていることは、あなたがonly1つの暗号スイート。もう1つのシステムは、その暗号スイートをサポートするためにnotを選択しています。 （理由を言うことができるのは他のシステムの所有者だけですが、私の推測では Logjam に関係している可能性があります。）ただし、他のシステムはおそらく同等である他のいくつかの暗号スイートをサポートしています（それ以上ではない場合）選択したセキュリティで保護します。 （@SteffenUllrichがリストを持っているように見えます。）快適なものを1つ選び、それを許可するようにシステムを構成してください。

または、その接続にTLSを使用しないでください。

または、そのサーバーとまったく通信しないでください。

あなたの選択。

4
Iszi