Yandexは送信および受信メールの暗号化をサポートするようになりました

先週、電子メールの送受信にYandex.MailのSTARTTLSを使用したクロスサーバーSMTP接続の暗号化を含めました。 メールシステムからこのような暗号化をサポートする他のサービス（Gmailなど）のユーザーへのすべての手紙は暗号化された形式で送信され、途中で読むことはできなくなります。 この点で、暗号化された形式で電子メールを送信するときに使用されるプロトコルについて少しお話します。



ユーザーとメールインターフェース間の接続の暗号化は、大規模なサービスではすでに非常に一般的であるという事実にもかかわらず、メールシステム間の通信はしばしば保護されなくなりました。 また、通信のセキュリティは私たちにとって非常に重要なものです（ただし、平均的なユーザーにはあまり目立ちません）。







研究者は、インターネット技術者の略語に対する真の愛の理由をまだ見つけていません。 ARPANET以降、すべてのネットワーク、プロトコル、標準など。 略語と呼ばれることを好む。 この単純でわかりやすい単語形成方法は、「IETFが、 SSHFPでRSA、DSA、およびECDSAを使用したSHA-256の使用に関するCZ.NICによるRFC6594を公​​開しました」という形式の文につながります。 ご覧のとおり、暗号化にはこのような略語が特に多くあります。

SSLおよびTLSとは何ですか？

前世紀の90年代に、学術環境からのあらゆる種類の興味深いアイデアが現実に具体化された「インキュベーター」の1つがNetscapeでした。 昨年の初めに、接続の暗号化の可能性に気づき、プロトコルを公開し、Secure Sockets Layer（SSL）と呼んだのは彼女の従業員でした。 最初の公開バージョンはSSL v2であり、これにより多くの脆弱性がすぐに見つかりました 。 その後、現在利用可能な最後のSSL v3が続きました。 Netscape の元の説明は、AOLによるNetscapeの吸収の際に忘却に陥りましたが、2011年にRFC6101の形式でストーリーのために公開されました 。



その後、最初の無料のSSL実装が登場しました。 愛好家のEric Youngは、 BSDライクなライセンスの下でSSLeayライブラリ（今回はチームの略称：SSL + Eric A. Young）の公開を開始しました。 SSLeayは、数年後にはすべての専門家に知られているOpenSSLライブラリに変わります。



SSL v2およびv3について知っておくべき重要なことは何ですか？ まず、これらのプロトコルは、信頼性の高い配信と接続（TCPなど）を備えたトランスポートプロトコル上で動作するように設計されています。 第二に、SSL v2はもはや使用できなくなりました。公式には脆弱すぎると見なされており、現在の環境ではセキュリティの錯覚を与えるだけです。



SSL v3に基づいて、 IETF内の科学者とエンジニアのチームは、トランスポート層セキュリティ（ TLS）プロトコルを作成しました。 実際、TLS v1.0はSSL v3の小さな（ただし互換性のない）再設計であり、すべての機能が含まれ、詳細が追加されています。



90年代の終わりとゼロの始まりは、HTTPSの広範な使用（および、これは単にHTTP over SSL / TLS-暗号化HTTP）によってマークされ、その結果、 両方の色の帽子でコンピューターセキュリティの専門家によってこれらのプロトコルに細心の注意が払われました。 その結果、CBCモードでブロック暗号化アルゴリズムを使用してSSL v3またはTLS 1.0を使用した場合（およびSSLで他のブロックアルゴリズムモードが使用されなかった場合）、 すべてのクラスの脆弱性が発見されました。 2006年-すでに7年後-TLS 1.1の更新バージョンがリリースされ、これらの脆弱性が排除されました。 しかし、2011年まで、TLS 1.1を使用するブラウザに対する大規模な攻撃がBEASTと呼ばれる大規模な攻撃をインターネットにもたらしたとき、エンジニアはTLS 1.1の実装を急いでいませんでした。 いくつかの松葉杖がすぐに発明され（たとえば、ストリーム暗号への切り替え）、すべてをTLS 1.1+にアップグレードするための優先順位が上がりました。



2008年に、TLSの最新バージョン1.2の仕様がリリースされました。 多くのイノベーションが登場しました。 まず、 AES暗号化アルゴリズムを使用する機能が必須になり、CBC- GCMに加えて新しい暗号化モードが登場しました。 第二に、レガシーDESおよびIDEAアルゴリズムのサポートは除外されました。 第三に、プロトコルはMD5ハッシュアルゴリズムに基づくHMACの使用を放棄し、より安定したSHA256およびSHA384に切り替えました。 4番目に、TLS拡張メカニズムが登場しました。これにより、プロトコルを完全に再設計することなく、新しい機能を含めることができます。 これらの拡張機能の1つはSNIです 。これは、Yandexサービスで積極的に使用されています。 最後に、すべての革新が役に立たないように、プロトコルではSSLv3へのダウングレードの可能性は廃止され、推奨されていません。



要約すると、

1. SSLは、TCPを介した安全な接続プロトコルです。 新しいSSLバージョンはありません。 TLS─これは新しいSSLであり、新しいバージョン番号が付けられています。
2. 古いSSL v2があります。 使用できません-サポートされている場合は、無効にする必要があります。 SSL v3があり、これはどこでも長年にわたってサポートされています。 しかし、セキュリティに悪影響を及ぼす可能性のある欠陥が見つかりました。 TLS v1.0があり、SSL v3の脆弱性を保持しており、インライン暗号化アルゴリズムRC4 （理論的に脆弱であると別に考えられる）でのみ使用することをお勧めします。 したがって、TLS v1.1またはv1.2を使用して、RC4暗号を無効にすることをお勧めします。

メールプロトコル

HTTPは、電子メールを送信するための主要なユーザープロトコルであると自信を持って言えます。 これは異常に聞こえるかもしれませんが、大多数のユーザーは2013年にメールを読んで送信します。







メールプログラムは、背景に色あせていますが、まだ広く使用されており、3つのプロトコルで動作します。古いPOP3、少し新しいIMAP、ユニバーサルSMTPです。 以前 、POP3とIMAPの歴史について少し話をしましたが、 SMTPについて少し追加します。



電子メールは、最初のキラーラップトップコンピューターネットワークと呼ばれています。 現代のSMTP（Simple Mail Transfer Protocol）のルーツは、米国国防総省からの資金でアメリカの大学のコンピューター間でファイルを転送するTCP / IP以前の時代に、ARPANETに深く入り込みました。 これらは、暗号化だけでなく、単純な認証さえも必要とされない、素朴で広範にわたる相互信頼の素晴らしい時代でした。 ところで、数年後に私たちに何が起こったのかは、あなた自身のスパムフォルダで見ることができます。



インターネット用SMTPの最初のバージョン（大文字！）を参照してください。1981年の終わりにRFC 788で指定されました 。 それでも、それはARPANETでの電子メール開発の10年以上の結果でした。 そして、1999年のほぼ20年後にようやく、認証の公式標準、つまりSMTPでのログインとパスワードが登場しました。 これまで、SMTP経由でメールを送信することは、誰とでも誰でも接続した直後に可能でした。 もちろん、このモードは、多数の希望を持つネットワーク上のサーバー間通信に適していました。この場合、ホストは他の誰かのメールのリレーとして機能できます。 しかし、認証なしの最初の送信、いわゆるサブミッションは、スパムの出現につながり、SMTP SMTPの発明につながりました。 ところで、昔の人は、POP3をSMTPの認証松葉杖として使用した「POP3 before SMTP」モードをまだ覚えています。



プロトコルにパスワードが表示されるとすぐに、暗号化についてすぐに考え始めます。 2002年に、オープンSMTPセッションのTLSモードへのアップグレードをサポートする標準─RFC3207がリリースされました 。 これは、事実上の状況を修正および改善する試みでした。そのときまでに、別のポート465でのSMTP暗号化が数年間使用されていました。



STARTTLS操作スキームは特に重要です。 これは、任意のテキストプロトコルの汎用拡張機能です。 実際には、SMTP、IMAP / POP3、およびFTP用に少し配布されています。







すでに確立されたオープン接続のクライアントとサーバーが両側のデータ伝送を暗号化する機会と希望があることを理解した瞬間に、クライアントはSTARTTLSコマンドを与えてすぐにTLSハンドシェイクを開始します。







暗号化を開始する前にTLSの相互サポートを確認する方法のみが、アプリケーションプロトコルに依存します。 SMTPの場合、これはESMTP拡張メカニズムを介して行われます。これには詳細があります。







標準ポート（多くの場合忘れられている25および2番目の587を思い出してください）またはポート465でのSTARTTLSを介したSMTP暗号化は、すぐに人気を博し始めました。 TLSは多くのことを可能にします。証明書認証とサーバー認証─これらはすべて興味深く、必要で、これまで利用できなかった機能です。 現在、暗号化された接続を介してユーザーからのメールを受け付けないメールシステムはないようです。 もう1つのことは、サーバー間通信です。



SMTPは単なる電子メールの馬ではなく、双頭の馬でもあります。



さまざまなメールシステムのサーバー間での手紙のやり取りもすべてSMTPを介して行われます。 もちろん、パスワード認証はありません─その代わりに、アプリケーションレベルでの手紙の受信者のアドレスの確認が使用されます。 存在しない場合は、オープンリレーであることが判明します。これにより、世界中のスパム対策システムが否定的な評判で罰せられることになります。 通常、そこには暗号化はありません。 これにはいくつかの理由があります。 第一に、メールシステムのサーバー間の通信チャネル自体は非常に安全であると考えられています。 実際、サーバー間で転送する場合、通常、文字は「ラストマイル」まで届きません。通常、「ラストマイル」では、小さな「カジュアルな」トラフィックインターセプトが発生します。 第二に、この送信は非同期で非対話的であるため、接続を受け取った当事者の証明書の違反または期限切れの場合に何をすべきかを人に明確にする方法はありません。



しかし、これらの議論はすべて受け入れがたいものです。 受信サーバーは、大規模な安全なデータセンターのラック内ではなく、どこにでもある可能性があります。 世界中の政府機関は、すべての通信チャネルで盗聴プログラムを開始しています。 証明書の検証は役立つ場合がありますが、情報の転送を保護するためには必要ありません。 したがって、多くの場合、すべての方法で暗号化された文字が表示されます-ユーザーのブラウザからHTTPSを介してメールシステムサーバー、受信者のサーバー、SMTP over TLS、そしてその後暗号化されたIMAPを介して宛先の電話メッセージ。 そしてそれは良いことです。

Yandex Mailプロトコルでの暗号化のサポート

2009年、 IMAPの立ち上げと同時に 、POP3インターフェイスにSSL / TLSサポートを追加しました。 ほぼ同時期に、SMTPで暗号化が行われ、電子メールプログラムから電子メールを受信しました。 現在、4年以上経っても、サーバーではメールプログラムから安全でない接続を開くことができますが、使用することはお勧めしませんが、可能であれば文書化することはできません。







Yandex.Mailモバイルアプリケーションは常にSSL / TLS接続を使用し、内部ではXMPPプロトコルを使用します。



2011年、Webインターフェースmail.yandex.ruで HTTPSを有効にし、ユーザー情報をクラウドに転送するすべての主要な方法をカバーしました。 今年、私たちはメールにアクセスするときにHTTPSを必須にし、今週は安全でないプロトコルを介して接続する機会を無効にしました。また、認証システムであるYandex.Passportでユーザーパスワードを保護する素晴らしい仕事をしました。







これは、外部とのSMTP通信サーバー上の暗号化されたトラフィックと通常のトラフィックの比率が現在どのように見えるかです。









終わりに近づいている2013年は、政府機関によるデータの大量盗聴に関連した注目を集めるスキャンダルの年と、広範囲にわたるクラウド暗号化の最初の年の両方と自信を持って呼ぶことができます。 業界の同僚全員にこのトレンドに参加し、ネットワーク上のすべてのユーザーデータの完全な暗号化に向けて講座を受講することをお勧めします。 そのようなこと。



PS：エドワード、こんにちは！ :)

PPS：エドワード・スノーデンは機能せず、Yandexで職を得たことはありません。