確立されたHTTPS接続は、回線が本当に安全であることを意味しますか？
Webアプリケーションを提供している誰かの観点から、誰かがTLS（https）を使用してサービスに接続し、正しい認証データを送信した場合、すべての機密データをこの回線で送信しても安全ですか、それとも盗聴されている可能性がありますか？
この質問は今週のITセキュリティ質問でした。
詳細については、2011年7月29日ブログエントリをお読みください。または自分で送信今週の質問。
特にこれは誤解の非常に一般的な原因であるため、SSLの機能と機能しないことを理解することが重要です。
- チャネルを暗号化します
- 整合性チェックを適用します
- 認証を提供します
つまり、「はい、機密データを送信するのに十分安全です」ということになります。しかし、物事はそれほど単純ではありません。
- SSLの最新バージョン-バージョン3以降：TLSは、TLS 1.2であっても、以前のバージョンよりも明らかに優れています。例えば。 SSL 2はMITMに比較的簡単でした（中央の男性）。したがって、最初はプロトコルのバージョンによって異なります。
- チャネルの暗号化と整合性チェックの両方がプロトコルで構成可能です。つまり、使用するアルゴリズム（暗号スイート）を選択できます。明らかに、RSA1024/SHA512を使用している場合は、はるかに優れています...ただし、SSLはNULL暗号化のモードもサポートします。つまり、暗号化をまったく行わず、SSLプロトコルを介してトンネルするように要求をラップするだけです。つまり、保護されていません。 （これはクライアントとサーバーの両方で構成可能です。選択された暗号スイートは、構成された順序に従って最初に一致するセットです）。
- SSLでの認証には、サーバー認証のみと相互認証（クライアント証明書）の2つのモードがあります。どちらの場合も、暗号化証明書によって保証されるセキュリティは十分に強力ですが、実際の認証の有効性は、有効性チェックと同じくらい良好です。その有効性を確認していますか？信頼チェーン？誰が発行したのですか？等。
- この最後のポイントの再認証は、Web アプリケーションではるかに簡単です。クライアントはサーバー証明書を簡単に表示でき、ロックアイコンは簡単に表示できます。WebServicesを使用すると、通常は、その有効性のチェックをより明確にする必要があります（選択したプラットフォームによって異なります）。この同じ点が非常に多くのモバイルアプリを作動させていることに注意してください。アプリの開発者が電話とサーバー間でTLSのみを使用することを覚えていたとしても、アプリが証明書を明示的に検証しない場合、TLSは壊れます。
- SSLの暗号化にはほとんど理論的な攻撃がいくつかありますが、私のPoVからは、ほとんどすべての目的に十分なほど強力であり、長い間続くでしょう。
- 反対側のデータで実際に何が行われますか？例えば。非常に機密性の高い、またはクレジットカードのデータでさえ、ブラウザのキャッシュや履歴などにそれを入れたくない場合.
- Cookie（および認証）は、 "secure"属性で明示的にマークされていない限り、セキュアなSSLチャネルと非セキュアなHTTPチャネルの間で共有できます。
だから、短い答え？はい、SSL canは十分に安全ですが、（ほとんどの場合と同様に）SSLの使い方によって異なります。 :)
ここにはいくつかの問題がありますが、主な問題は認証です。両端は、中間者攻撃を阻止するために適切な人物または機関と話していることを確認する必要があります。あなたの側では、ユーザーのブラウザによって信頼されているSSL証明書を使用することが重要です。そうすることにより、ユーザーのブラウザーは、実際に正しいサイトと通信していることを確認できます。接続が確立されると、そのユーザーと常に通話していることが確認でき、接続は暗号化されます。つまり、盗聴から保護されます。
逆方向の認証（つまり、実際のユーザーと通信していることを確認する）は、通常、アプリケーションレベルのSSLプロトコルの外部で、たとえば、ユーザー名/パスワード、openID、またはその他の形式の資格情報によって処理されます。
最後の注意点として、SSL接続中にハンドシェイククライアントとサーバーが 暗号スイート に同意し、クライアントが「null暗号化」のみを行うふりをする可能性があること、つまり、データを暗号化しないことに注意してください。サーバーがそのオプションに同意する場合、接続はSSLを使用しますが、データはまだ暗号化されていません。サーバーの実装は通常、オプションとしてnull暗号を提供しないため、これは実際には問題ではありません。
AviDのリストに加えて、SSLは、そのサーバーに接続するDNSインフラストラクチャと通信パス内の企業プロキシと同じくらい安全です。
DNSインフラストラクチャがハッキングされている場合（キャッシュポイズニングなど）、攻撃者はユーザーを多くの攻撃にさらす可能性があります。
さらに、クライアントが Fiddler などのソフトウェア、または企業プロキシを経由している場合、そのソフトウェアはSSL会話を容易に実行できます。
これを軽減するには、SSL証明書の「発行者」を確認します。 SSL接続がプロキシを経由している場合、発行者はプロキシの発行者になります。直接接続している場合は、関連する公的に信頼されたCAが表示されます。
[詳細]
企業のHTTPSプロキシは、Webブラウザとプロキシ（WebサーバーログにIPアドレスが表示される）間の接続を管理するものです。その場合、Webコンテンツ（HTTPSパスワードも）が復号化され、後で企業プロキシで再暗号化されてサーバーに提示されます。
誰がプロキシを管理しているか、およびそのログがどのように使用されているかによって、これは許容できるか、またはあなたの観点から悪いことかもしれません。
SSLインターセプトがどのように行われるかについての詳細は、これを参照してください link ：
SSLプロキシはSSL接続をインターセプトするときに、エミュレートされたサーバー証明書をクライアントブラウザに提示します。ブラウザはProxySGが使用する発行者を信頼していないため、クライアントブラウザはセキュリティポップアップをエンドユーザーに発行します。 SSLプロキシで使用される発行者の証明書が信頼できるルートとしてクライアントブラウザの証明書ストアにインポートされている場合、このポップアップは発生しません。
ProxySGは、構成されたすべての証明書を管理コンソールからダウンロードできるようにします。 Internet ExplorerまたはFirefoxを介して発行者の証明書をダウンロードし、選択したブラウザーに信頼できるCAとしてインストールするようにエンドユーザーに依頼できます。これにより、エミュレートされた証明書のポップアップがなくなります...
一部の企業は、GPOを介して各ワークステーションに（プロキシの）ルート証明書を展開することにより、上記の証明書ポップアップの問題を回避しています。ただし、これはMicrosoft証明書ストアを使用するソフトウェアにのみ影響します。 FirefoxやChrome=などのソフトウェアは、別の方法で更新する必要があります。
SSLは認証局（CA）に依存しており、基本的にあらゆる組織がCAになることができるため、偽のまだCA署名の証明書による中間者攻撃が常に可能です。そのため、SSLはまだ暗号化されていないことよりも大幅に改善されていますが、CAシステムが壊れているため、セキュリティは過大評価されています。その点で、自己署名証明書はCA署名証明書と同じくらい安全ですが、ブラウザはそれらを疑わしいものとしてマークします。
SSLは非常に安全ですが、暗号化されていない行で任意のページを実行すると、誰かが誰かのセッションCookieを盗む可能性があります。できれば、サイトをすべてSSLにします。または、暗号化された接続に対してのみCookieを送信し、そのユーザーに固有ではない、セキュリティで保護されていないパブリックページを使用することもできます。
中間者攻撃の可能性はまだあります。これは、あなたの場合、ユーザーがあなたのサイトであると主張してサードパーティに接続し、リクエストを転送することになります。もちろん、経験豊富なユーザーはSSL接続の欠如や間違った証明書に気付くはずですが、ほとんどのユーザーはこれがオンになっておらず、南京錠ファビコンに騙されています。
これは実際にはSSL自体の問題ではなく、注意すべき問題です。サイトと接続のソースとの間のSSL接続を誰も盗聴できないと安全に想定できます。ただし、接続のソースが実際にユーザーであることを確認することはできません。
SSLは送信を暗号化するので、（証明書が信頼されているため）データを盗聴することはできません。
問題はWebアプリケーションのどこで（そしてどのくらい）SSLを使用しているかに依存しますが、たとえば、ユーザーを認証するためにのみSSL接続が必要だとします（暗号化されたユーザー/パスのペアをサーバーに送信するため）次に、Cookieを送り返すときは、簡単に傍受される可能性があることに注意してください（ユーザーが保護されていないワイヤレス接続を使用している場合など）。
最近のFireSheepドラマはこれについてすべてです。
いいえ。 トラフィック分析 でも、誰かに多くのことを伝えることができます。
トラフィック分析は、通信のパターンから情報を推測するためにメッセージを傍受および検査するプロセスです。メッセージが暗号化されており、復号化できない場合でも実行できます。一般に、観測されたメッセージの数、または傍受して保存されたメッセージの数が多いほど、トラフィックから推測できる量が多くなります。
TLSは通常、機密性を維持するために導入されます。攻撃者は、通信の内容について高い信頼を得てはなりません。
仮定すると、
- 攻撃者はあなたのプロトコルを知っています、
- 攻撃者は誰が誰と通信しているかを知っています
- 攻撃者はメッセージを復号化できません。
- 多くのナンセンスなトラフィック（チャフ）で実際のトラフィックを不明瞭にしない
攻撃者は、プロトコルに関係なく、起きているときと眠っているときを知ることができます。また、使用しているプロトコルの性質によっては、さらに多くのことを知ることができる場合があります。
プロトコルが非常に単純な場合：
- あなたが核を発射したいとき、あなたは「核を発射して...」というメッセージを送ります
- 核を発射したくないときはメッセージを送信しません。
データを解読できない盗聴者は、メッセージの存在だけで、誰にではなく核を発射したいかを判断できます。
プロトコルがより複雑な場合：
- あなたは本を求めます。
- 内容をお送りします。
攻撃者は誰が読んでいるかはわかりません "戦争と平和"対 "アトラスシュラグド" メッセージサイズに基づいて、前者とカフカの55のどちらを読んでいるかを区別できますページ小説「変身」。
SSLは、認証と暗号化という2つの基本的なタスクを実行します。
認証は認証局（CA）によって行われます。ブラウザには、CAの署名鍵用のSSL証明書のリストが付属しています。 CAは、エンティティの公開鍵を記述する証明書に署名します。たとえば、Google.comを所有している場合、それをVerisignに証明すると、彼らは一定期間私の証明書に署名します。 CAで問題が発生すると、署名してはならない証明書に署名します。これは、誰かが別のドメインを所有しているふりをしたり、広すぎるワイルドカード証明書を取得したり、単純な XKCDs CAが悪質なもの（政府、おそらく？）上記のすべてのインスタンスが発生するのを見てきましたが、それはかなりまれです。
サイトの証明書が適切に署名されていて、信頼チェーンに偽の証明書が存在しない場合は、サイトに接続すると、証明書が一致することを確認できます（説明のため）。通常の状況では、その接続は暗号化されます。これにより、誰もあなたのデータを読み取ることができなくなります。
SSL証明書は非常に複雑であり、SSLの実装に対して多くの攻撃が存在します。 SSLが効果的にできることは、GMailでメールをチェックするときに、ローカルのスターバックスでトラフィックを監視できないようにすることです。それができないことは、私がMITM攻撃を使用できないようにすることです。SSLなしですべてをリレーし、クライアントは、暗号化されたセッションを開始したことがないという事実を気にするように設定されていません。
SSL 3.0と強力な暗号化を使用していると仮定すると、他の潜在的な問題に関する他の人からのさまざまな回答を考慮せず、安全である必要があります。
古いsslプロトコル（2.0）を使用するか、弱い暗号化キーを使用すると、脆弱性にさらされる可能性があります。
SSLは通常、以下を提供することによりセキュリティを向上させます。
- サーバー認証（ユーザーは「正しい」サイトと通信していることを知っています）
- データの整合性（ユーザーとサーバーは、トラフィックが途中で変更されていないことを知っています）
- （オプション、ただし通常）データのプライバシー（ユーザーとサーバーは、途中でトラフィックが傍受されていないことを知っています）
- （オプション、ただしまれ）クライアント認証（クライアントにも証明書がある場合）
基本的に、SSL証明書には、サーバー証明書（常に含まれる）とクライアント証明書（オプション）の2種類しかありません。
これは単なるスケッチで、if、ands、butsがたくさんあります。最も一般的なシナリオであるブラウザベースのSSLでは、暗号化やプロトコルを破ることなく、多くの場合スキームを破ることができますが、ユーザーに頼って間違ったことを行うだけです（つまり、ブラウザの警告を無視して接続します）。フィッシング攻撃は、SSLで保護された偽のサイトにユーザーを送信することによっても機能し、URL以外のすべての点で実際のサイトに似ています。
SSLとそのいとこTLSは、絶対安全とは言えませんが、少なくとも安全な通信が可能であるため、依然として非常に有用です。
@Vladimirは正しい http://en.wikipedia.org/wiki/Forward_secrecy が望ましいが、詳細が間違っている。サーバー選択これらの暗号スイート提供によってブラウザから。 「メッセージ認証用にSHA1を備えたRC4_128で暗号化」は、RC4 128ビット暗号化とHMAC-SHA-1整合性チェックを使用します。 （最近までSHAと言うまでのSSL/TLSの暗号スイート名ですが、SHA-1を意味し、実際にはHMAC-SHA-1を意味します。）「鍵交換メカニズムとしてのECDHE_ECDSA」は個々のメッセージには適用されません、それはセッションの最初に一度発生するハンドシェイクの一部（ほとんど）です：ECDHEは、エフェメラルモードでDiffie-Hellmanの楕円曲線バリアント（およびここでは重要ではないいくつかの追加手順）を使用してセッションを作成しますkeys暗号化とHMACに使用されます; ECDHE鍵交換（のみ）は、デジタル署名アルゴリズムの楕円曲線バリアントによって署名されます（DHまたはECDHを使用して直接暗号化することはできません。契約。）
SSLを使用していない場合、すべての通信が簡単に傍受される可能性があります。これを行うには、パケットスニファ（Wiresharkなど）を起動するだけです。
SSLはそれを防止します。すべてのパケットは暗号化されるため、送信しているものを知る方法はありません。基本的に、パスワードやプライベートコンテンツを傍受から保護するために使用されます。あなたは明らかに他の誰かにあなたのプライベートメールを読んでほしくないのですよね？
Google検索に関しては、人々が求めているものを隠すために彼らは単にそれをしました。これは、一部の政府が好奇心が強いためです。
SSLはどのようにセキュリティを強化しますか？それ自体ではありません。暗号化（SSLキー）とPKI（公開キーインフラストラクチャ）の組み合わせが主に証明書です。 OK、問題はその方法でした。一方では、通信チャネルを保護し（上記を参照）、もう一方では、正当なビジネスと通信していることを保証します-サーバーを認証します。したがって、チャネルは安全で信頼されています。
PKIサービス がかなりあるので、SSL証明書はかなりあります。基本的に、異なるサービスには異なるタイプのSSL証明書が必要です。したがって、コード署名、電子メールの暗号化と署名、サーバー認証などに関する証明書があります。
誰かがSSL（https）を使用してサービスに接続し、正しい認証データを送信した場合、すべての機密データをこの回線で送信しても安全ですか、それとも盗聴されている可能性がありますか？
このチェーンの弱いリンクはほぼ間違いなくSSLではありませんが、ユーザーは通常、Webスプーフィング/ハイパーリンクスプーフィングを介して、または無効な証明書が提示され、ブラウザーの警告を無視して次の手順に進むことにより、偽の中間サイトに接続されます。とにかく接続します。
しかし、あなたが説明するシステムはとにかくベストプラクティスであり、他にできることは多くありません（できる限り、ユーザーにSSL警告を真剣に受け止めるように教育することを除いて）。
短い答えはノーです。より長い回答：上記の回答のコレクションに加えて、認証を解決する場合、つまり中間者である場合、従来のSSL接続を使用して、トラフィックにリストするsomoneは、サーバーの秘密鍵を取得した場合、後でそれを復号化できます（考えてみてください） of NSA and National Security Letters）。TLSプロトコルには、Diffie-Helmanプロトコルを使用してリンクを秘密裏に保証するオプションがあります。Chromeを使用してgmail.comにアクセスしている場合は、次の画像を参照してください。 
メッセージ認証ECDHE_ECDSAについては、SHA1でテキストRC4_128を確認してください。これは次のようになります。
- サーバーはSHAダイジェストを使用してSSLチャネルRC4_128bを提供しました
- このトンネル内では、各メッセージは楕円曲線で暗号化され、キーはDiffie-Helman関数を使用して導出され、デジタル署名アルゴリズムを使用して楕円曲線暗号で署名されます
つまり、誰かがSSLサーバーの秘密キーを持っている場合でも、メッセージは使用後すぐにメモリから破棄される一時キーで暗号化されています。頑張ってNSA！
ユーザーにとって安全ですか、それともあなたにとって安全ですか？中間者攻撃を想定します。攻撃者は、ユーザーのトラフィックをキャプチャし、ユーザーになりすましたり、ユーザーになりすましたりします。ユーザーに与えられた証明書が正しくないため、この種の攻撃は通常失敗します。たとえば、攻撃者はユーザーにWebサイトの自己署名証明書を提供します。ただし、ユーザーが愚かに行動する場合、ユーザーはその自己署名証明書を受け入れる可能性があります。これで、攻撃者はユーザーとあなたの間のすべてのトラフィックを読み取って変更できるようになりました。私が知る限り、これを検出する方法はありません。
したがって、トラフィックのスヌーピングと変更がユーザーに害を及ぼす場合、それは実際にはユーザー自身の責任であり、ユーザー自身の問題です。とにかく、それを完全に防ぐことはできません。MITMが完全にあなたを切り取って、あなたになりすましているユーザーに話しかけるだけだからです。しかし、トラフィックのスヌーピングと変更があなたに害を与える場合、あなたはそのユーザーが愚かでないことを信頼するか、そのユーザーをよりよく認証する必要があります（ユーザーは証明書を必要とし、MITMができない方法でそれをチェックすることができます）偽）。
クライアントがCAを信頼している場合、TLSを使用するHTTPSの最新バージョンでさえ、MitM（たとえば、目的のために設定された Juniper device ）によって簡単に傍受される可能性があります。その特定のケースでは、それは安全ではありません。
ここの人々は質問を理解していないと思います：
安全でない回線があり、この回線でSSH/SSL接続が成功した場合、彼は、回線が「安全」であり、暗号化されていないデータを暗号化された接続でALONGSIDEに渡すことができると想定して安全かどうかを尋ねます（たとえば、暗号化されたSSL/SSH接続内ではなく、一目でわかります）。
私はノーと言うでしょう。この場合、暗号化されたデータを単に無視し、暗号化されていないデータを保存する受動的な盗聴者が存在する可能性があります。
しかし、アクティブな盗聴者（MITM）がないことを確認できます。つまり、認証された回線と同じ送信元/宛先を使用して、認証されていないSSL/SSH接続を安全に確立できます。これにより、選択的な盗聴者がMITMの特定のコネクタに提供されませんでしたが、盗聴者は接続を認証するかどうかを認識できないため、MITMへのどの接続が検出を回避するかを知ることができません。 MITMerは、もし彼がMITMである場合、すべての接続をMITMにして、人々がすべての認証ダイアログをクリックするだけであることを望みます。
したがって、たとえば、123.123.123.123から24.24.24.24にSSLサービスに認証されて接続する場合、SSHフィンガープリントを相互認証せずに、SSHクライアントを安全に接続することもできます。反対側のNATルーターまたはファイアウォール。
しかし、一般的に安全であるとしても、IS盗聴者が単にランダムなMITM接続を検出し、検出されないことを期待するという小さなリスクがあります。そのため、ターゲットIPへの認証済み接続がすでにあるので、なぜですか認証された接続を使用してSSHフィンガープリントを相互に検証しませんか？SSLで保護されたWebサイトに正しいSSHフィンガープリントを投稿するだけの簡単な方法です！