¿Cómo puede mi empleador ser un intermediario cuando me conecto a Gmail? [duplicar]

Usted es absolutamente correcto en sus suposiciones.

Si está utilizando una computadora que es propiedad de su empleador y es operada por ella, tienen un control total sobre sus comunicaciones. En función de lo que proporcionó, han instalado un certificado de CA raíz que les permite firmar un certificado para Google.

Esto no es tan infrecuente en la empresa, ya que permite la inspección del tráfico cifrado en busca de virus o fugas de datos.

Para responder a sus tres preguntas:

1. Sí, es muy posible y probable. Se desconoce qué tan activos son en el monitoreo de estas cosas.

2. Su empleador puede leer su contraseña en texto sin formato. No sé a qué te refieres con el servidor web.

3. Puede verificar el certificado para ver quién lo firmó, como ya lo ha hecho. También puede comparar la huella digital con la de Google (verificada por un tercero fuera del control comercial)

Editar:

  

¿Cómo puede mi empleador exactamente desencriptar eso? Podrias tal vez   ¿Elaborar un poco sobre eso?

Está utilizando el certificado incorrecto para conectarse a un dispositivo intermediario como el firewall, ese dispositivo se conecta a Google utilizando el certificado correcto. La comunicación se encripta de su cliente al MITM, se descifra y luego se vuelve a cifrar de camino a Google.

1 y 2 son respondidos por David Houde

3:

En realidad, no hay ninguna manera de saber con certeza si usted está hablando de manera segura con Gmail cuando usa la máquina de su compañía (aparte de auditar la máquina hasta el fondo). Incluso si no cambiaran el certificado, podrían simplemente modificar el navegador web para reenviar todo el tráfico descifrado a algún lugar. Hay un millón de otras cosas que podrían hacer. Da la casualidad de que, en este caso, instalaron su propio certificado raíz que le permite ver lo que han hecho.

No veo a nadie que lo mencione, así que permítame señalar algo. Tal vez me equivoque, pero el anclaje de certificados implementado en Google Chrome (también hay un complemento para Firefox) impide la falsificación de certificados.

Preguntas y respuestas relacionadas .

Por supuesto, es posible detectar el tráfico de alguien si controla la infraestructura. Pero esto es posible hasta cierto punto y, en mi opinión, depende de qué tan restringidas sean las acciones de los usuarios y qué conocimientos tiene el usuario. Google Chrome es el navegador que se puede instalar dentro del Perfil de usuario y creo que no requiere privilegios administrativos. También puede verificar la suma de comprobación del paquete de instalación para verificar que no se haya modificado sobre la marcha. Dado que Google Chrome utiliza la fijación de certificados independientemente del almacén de certificados del sistema operativo, ¿sigue siendo vulnerable a MITM ?

No veo ninguna forma de evitar que los usuarios usen la versión portátil de VirtualBox con sistema operativo cliente que tendrá un montón de herramientas orientadas a la privacidad que elevarán significativamente la posibilidad de asegurar la comunicación a cualquier sitio web / dominio.

Por favor, siéntase libre de corregirme si me equivoco en cualquiera de los puntos anteriores.

----------

Editar.

Ok. Así que encontré una solución para comprobar si el certificado se ha falsificado . Supuestamente no funciona perfectamente para Google y Apple, pero podría ser lo que está buscando en el caso de otros dominios.

Al punto:

Hay un sitio enlace que puede comprobar la huella digital del certificado remoto para usted . Luego puede compararlo con el que ve en su navegador para verificar si coinciden. Si no coinciden, este certificado es falsificado ( Exception is mentioned in the section *What can go wrong with this test?* on the mentioned page. ).

Aquí está la prueba de que funciona. Certificado del navegador:

Huelladigitaldelaverificacióndegrc.com:

Creo que, dado que usted está mencionando algo en la línea de vigilancia masiva, la falsificación de certificados también se realizará en varios sitios https. En ese caso, si se confirma que una está falsificada, creo que puede asumir que todas son.

Edición siguiente.

Sólo por completar la respuesta. Dado que puede ser el caso en el que algún estado u organización modifique completamente el navegador y el navegador no sea de confianza para confirmar la validez del certificado. He encontrado una función powershell que realiza una conexión SSL a una dirección específica y muestra información útil sobre el certificado.

Aquí está el código (el alias es mío):

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

Puede pegarlo en la consola de powershell; esto registrará la función durante el tiempo de la sesión actual (hasta que cierre la ventana de la consola de powershell para que no quede ningún rastro).

Después de eso, puedes escribir en la misma ventana:

TSSL www.ipko.pl

La salida se verá así:

Heencontradouncódigodefunción aquí .

Como han señalado otros: Sí, es posible y se está haciendo en este caso.

Intentando detallar más los pasos involucrados en este MITM:

Sabes que el certificado 028CA85E6765 ... pertenece a gmail porque una CA (GeoTrust, Verisign ...) ha afirmado que sí. Su sistema operativo / navegador contiene una lista de las CA en las que confía para hacer lo correcto (no mentir, estar debidamente asegurado ...).

• Su empleador ha instalado en su computadora su propia CA.
• Cuando te conectas a accounts.google.com con TLS, el proxy emite un nuevo certificado para accounts.google.com firmado por esa CA (si aún no tiene uno).
• Su conexión al proxy se realiza mediante el certificado falso accounts.google.com . El proxy se entremezcla con el contenido que desea, luego se conecta al accounts.google.com real (usando el certificado de Google) y envía y recibe los contenidos que usted y gmail se entregan.
• Cuando su computadora confía en la CA proxy, considera que el certificado accounts.google.com emitido por su empleador es legítimo, por lo que no hay advertencias.

¹ La mayoría de la gente consideraría que no es legítimo porque no es el certificado de Google, pero es el certificado esperado dentro de esta compañía. Sin embargo, los empleados pueden estar en desacuerdo, es deseable. :-)

Para agregar a otras respuestas, la única manera de asegurarse, con una certeza razonable, de que tiene una conexión segura desde su navegador al servidor web, es usar su propio equipo. El equipo y la red propiedad del empleador no están bajo su control, y puede ser difícil determinar qué se incluye en su sistema operativo y aplicaciones estándar. Incluso si es ilegal en el país en el que se encuentra, si la privacidad es una preocupación, probablemente debería usar su teléfono móvil o computadora portátil personal.