web-dev-qa-db-ja.com

Gmailに接続すると、雇用主はどのようにして仲介者になることができますか？

SSL/TLSを理解しようとしています。以下は、シナリオの説明と、確認または反論できることを願っています。

質問

Gmailに接続すると、雇用主はどのようにして仲介者になれますか？彼はまったくできますか？

つまり、雇用者が私の仕事用コンピューターのブラウザーと雇用者のWebプロキシサーバー間の接続の暗号化を解除し、たとえばウイルススキャンのためにプレーンテキストでデータを読み取り、データを再暗号化してGoogleに送信することは可能ですか？気付かずに

従業員のコンピューターのブラウザー<->雇用者のWebプロキシサーバー<-> Gmailサーバー

雇用主は会社のコンピュータに自己署名証明書をインストールできます。結局のところ、それは彼のインフラです。

シナリオ：私がやっていること

  1. ブラウザーで http://www.gmail.com を開きます（httpではなく、httpsです）。
  2. Googleログインページにリダイレクトされます： https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl = default＆ltmplcache = 2＆emr = 1
  3. ユーザー名とパスワードを入力します
  4. Gmailにリダイレクトされます： https://mail.google.com/mail/u/0/?pli=1#inbox
  5. ブラウザのSSLロックアイコンをクリックします...

...そして以下を参照してください：

  • 発行先：mail.google.com
  • 発行元：「雇用主会社名」
  • 有効期限：2014年1月1日〜2014年12月31日
  • 証明書パス：「雇用主の会社名」->「雇用主のWebプロキシサーバー名」-> mail.google.com

仮定

現在、ブラウザーのSSLロックアイコンが緑色になっていると想定していますが、実際にはブラウザーからGmailサーバーへの安全な接続がありません。

あれは正しいですか？

ソース

私はこれらのソースを読みましたが、それでもまだ完全には理解していません。

まとめ

  1. 誰かがITインフラストラクチャを制御している場合、誰かが中間者になることは可能ですか？もしそうなら、正確にはどうですか？
  2. ログイン名とパスワードは、雇用主のWebプロキシサーバーでプレーンテキストで読み取られますか？
  3. ブラウザからGmailサーバーに完全に安全に接続していることを確認するには、ブラウザで何をチェックする必要がありますか？

編集、2014年7月18日

  • プライバシーは問題ではありません。この特定のシナリオでTLSがどのように機能するかを知りたいだけです。雇用主が通信を傍受しなければならない他のどのような意味（キーロガーなど）も、この特定の場合には関係ありません。
  • 法的な問題は問題ではありません。従業員は、会社のIT機器をプライベート通信に一定の制限内で使用することが許可されています。一方、雇用主はプライバシーを侵害することなく監視を行う権利を留保します。
encryptiontlsauthenticationman-in-the-middle
99
Lernkurve

あなたの仮定は完全に正しいです。

雇用主が所有および運営しているコンピュータを使用している場合、彼らは事実上、通信を完全に制御できます。あなたが提供したものに基づいて、彼らはルートCA証明書をインストールし、Googleの証明書に自分で署名できるようにしています。

暗号化されたトラフィックを検査して、ウイルスやデータの漏えいがないかどうかを確認できるため、企業ではこれは珍しいことではありません。

3つの質問に答えるには：

  1. はい、可能です。これらの監視にどれほど積極的に取り組んでいるかは不明です。

  2. あなたのパスワードは雇用主がプレーンテキストで読むことができます。 Webサーバーの意味がわかりません。

  3. すでに行ったように、証明書に署名して誰が署名したかを確認できます。また、フィンガープリントをGoogleのフィンガープリントと比較することもできます（ビジネス管理の範囲外のサードパーティから確認されます）。

編集：

私の雇用主はそれをどの程度正確に暗号化解除できますか？少し詳しく説明してもらえますか？

不正な証明書を使用してファイアウォールなどの中間デバイスに接続している場合、そのデバイスは正しい証明書を使用してGoogleに接続します。通信はクライアントからMITMに暗号化され、復号化されてから、Googleに向かう途中で再暗号化されます。

82
David Houde

1と2は、David Houdeによって回答されています

3：

あなたが会社のマシンを使用しているときに（マシンを金属まで監査することを除いて）安全にGmailと通信しているかどうかを確認する方法は実際にはありません。証明書を変更しなかった場合でも、Webブラウザーを変更して、すべての復号化されたトラフィックをどこかに転送することができます。他にもできることは100万あります。たまたま、この場合、彼らはあなたが彼らが何をしたかを見ることができる彼ら自身のルート証明書をインストールしました。

21
Harold R. Eason

誰も言及していないので、指摘してもらいます。たぶん私は間違っていますが、Googleに実装されていない証明書の固定Chrome（Firefoxのプラグインがよく）証明書のなりすましを防ぎますか？

関連 質問と回答

もちろん、インフラストラクチャを制御していれば、誰かのトラフィックを盗聴することは可能です。しかし、これはある程度可能であり、私の意見では、ユーザーのアクションがどの程度制限されているか、およびユーザーの知識が何であるかに依存します。 Google Chromeはユーザープロフィール内にインストールできるブラウザであり、管理者権限は必要ないと思います。インストールパッケージのチェックサムを確認して、それが変更されていないことを確認することもできます- the-fly。Google Chromeは、オペレーティングシステムの証明書ストアに関係なく、証明書のピン留めを使用します-それでもMITMに対して脆弱ですか？

ウェブサイトやドメインへの通信を保護する可能性を大幅に高めるプライバシー指向のツールを備えたクライアントOSで、ポータブルバージョンのVirtualBoxをユーザーが使用できないようにする方法はありません。

上記のいずれかに誤りがある場合は、遠慮なく訂正してください。

----------

編集。

OK。だから私は証明書が偽造されていないかどうかを確認する解決策を見つけました。おそらくそれはグーグルとAppleのために完全に機能しませんが、他のドメインの場合にあなたが探しているものかもしれません。

ポイントへ：

サイトがあります https://www.grc.com/fingerprints.htm これは、リモート証明書のフィンガープリントを確認できます 。次に、ブラウザで表示されるものと比較して、一致するかどうかを確認できます。一致しない場合、この証明書は偽装されています（Exception is mentioned in the section *What can go wrong with this test?* on the mentioned page.）。

これが機能する証拠です。ブラウザー証明書： enter image description here

grc.com検証からの指紋： enter image description here

あなたが大量監視の線に沿って何かについて言及しているので、証明書のなりすましも複数のhttpsサイトで行われると思います。その場合、なりすましであることが確認された場合、それらはすべて偽装されていると考えることができます。

次の編集。

答えを完成させるためだけに。一部の州または組織がブラウザーを完全に変更し、ブラウザーを信頼できない場合があるためです証明書の有効性を確認します。指定されたアドレスへのSSL接続を実行し、証明書に関するいくつかの有用な情報を表示するPowerShell関数を見つけました。

ここにコードがあります（エイリアスは私のものです）：

function Test-WebServerSSL {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        [string]$URL,
        [Parameter(Position = 1)]
        [ValidateRange(1,65535)]
        [int]$Port = 443,
        [Parameter(Position = 2)]
        [Net.WebProxy]$Proxy,
        [Parameter(Position = 3)]
        [int]$Timeout = 15000,
        [switch]$UseUserContext
    )
Add-Type @"
using System;
using System.Net;
using System.Security.Cryptography.X509Certificates;
namespace PKI {
    namespace Web {
        public class WebSSL {
            public Uri OriginalURi;
            public Uri ReturnedURi;
            public X509Certificate2 Certificate;
            //public X500DistinguishedName Issuer;
            //public X500DistinguishedName Subject;
            public string Issuer;
            public string Subject;
            public string[] SubjectAlternativeNames;
            public bool CertificateIsValid;
            //public X509ChainStatus[] ErrorInformation;
            public string[] ErrorInformation;
            public HttpWebResponse Response;
        }
    }
}
"@
    $ConnectString = "https://$url`:$port"
    $WebRequest = [Net.WebRequest]::Create($ConnectString)
    $WebRequest.Proxy = $Proxy
    $WebRequest.Credentials = $null
    $WebRequest.Timeout = $Timeout
    $WebRequest.AllowAutoRedirect = $true
    [Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
    try {$Response = $WebRequest.GetResponse()}
    catch {}
    if ($WebRequest.ServicePoint.Certificate -ne $null) {
        $Cert = [Security.Cryptography.X509Certificates.X509Certificate2]$WebRequest.ServicePoint.Certificate.Handle
        try {$SAN = ($Cert.Extensions | Where-Object {$_.Oid.Value -eq "2.5.29.17"}).Format(0) -split ", "}
        catch {$SAN = $null}
        $chain = New-Object Security.Cryptography.X509Certificates.X509Chain -ArgumentList (!$UseUserContext)
        [void]$chain.ChainPolicy.ApplicationPolicy.Add("1.3.6.1.5.5.7.3.1")
        $Status = $chain.Build($Cert)
        New-Object PKI.Web.WebSSL -Property @{
            OriginalUri = $ConnectString;
            ReturnedUri = $Response.ResponseUri;
            Certificate = $WebRequest.ServicePoint.Certificate;
            Issuer = $WebRequest.ServicePoint.Certificate.Issuer;
            Subject = $WebRequest.ServicePoint.Certificate.Subject;
            SubjectAlternativeNames = $SAN;
            CertificateIsValid = $Status;
            Response = $Response;
            ErrorInformation = $chain.ChainStatus | ForEach-Object {$_.Status}
        }
        $chain.Reset()
        [Net.ServicePointManager]::ServerCertificateValidationCallback = $null
    } else {
        Write-Error $Error[0]
    }
}

Set-Alias TSSL Test-WebServerSSL

あなたはそれをpowershellコンソールに貼り付けることができます-これは現在のセッションの時間の関数を登録します（トレースを残さないようにpowershellコンソールウィンドウを閉じるまで）。

その後、同じウィンドウに入力できます。

TSSL www.ipko.pl

出力は次のようになります。 enter image description here

関数コード here を見つけました。

9
mnmnc

他の人が指摘したように：はい、それは可能であり、この場合それは行われています。

このMITMに含まれる手順を詳しく説明しようとしています。

証明書028CA85E6765…は、CA（GeoTrust、Verisign…）がgmailに属しているため、gmailに属していることを知っています。 OS /ブラウザには、正しいことをするために信頼するCAのリストが含まれています（嘘をつくのではなく、適切に保護されている…）。

  • 雇用主がコンピュータに独自のCAをインストールしています。
  • TLSを使用してaccounts.google.comに接続すると、プロキシは自身にそのCAによって署名されたaccounts.google.comの新しい証明書を発行します（まだ証明書がない場合）。
  • プロキシへの接続は、偽のaccounts.google.com証明書を使用して行われます。プロキシは、コンテンツがウィッシュされると干渉し、実際のaccounts.google.comに接続し（Googleの証明書を使用）、あなたとgmailが互いに提供するコンテンツを相互に送信します。
  • コンピューターがプロキシCAを信頼しているため、雇用主が発行したaccounts.google.com証明書は正当なものであると見なされ、警告が表示されません。

¹ほとんどの人は、それがGoogleの証明書ではないため、正当なものではないと考えますが、それはisこの会社内で期待される証明書です。しかし、従業員はそれが望ましいとは思わないかもしれません。 :-)

7
Ángel

他の回答に追加するには、ブラウザからWebサーバーへの安全な接続を確保するための妥当な確実性を持つ唯一の方法は、独自の機器を使用することです。雇用主が所有する機器とネットワークはユーザーの管理下にないため、標準のオペレーティングシステムとアプリケーションに何が含まれているかを判断するのが難しい場合があります。あなたがいる国ではそれが違法であっても、プライバシーが懸念される場合は、おそらく携帯電話または個人用ラップトップを使用する必要があります。

6
Jay