How can my employer be a man-in-the-middle when I connect to Gmail?

Question

I'm trying to understand SSL/TLS. What follows are a description of a scenario and a few assumptions which I hope you can confirm or refute.

Question

How can my employer be a man-in-the-middle when I connect to Gmail? Can he at all?

That is: is it possible for the employer to unencrypt the connection between the browser on my work computer and the employer's web proxy server, read the data in plain text for instance for virus scans, re-encrypt the data and to send it to Google without me noticing it?

Browser on employee's computer <--> employer's web proxy server <--> Gmail server

The employer can install any self-signed certificate on the company computers. It's his infrastructure after all.

Scenario: what I am doing

1. With a browser, open http://www.gmail.com (notice http, not https)
2. I get redirected to the Google login page: 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. I enter my username and password
4. I get redirected to Gmail: https://mail.google.com/mail/u/0/?pli=1#inbox
5. I click on the SSL lock-icon in the browser...

...and see the following:

• Issued to: mail.google.com
• Issued by: "employer company name"
• Valid from: 01.01.2014 - 31.12.2014
• Certification path: "employer company name" --> "employer web proxy server name" --> mail.google.com

Assumption

I'm now assuming that the SSL lock-icon in the browser turns green, but in fact I don't have a secure connection from the browser to the Gmail server.

Is that correct?

Sources

I've read these sources but still don't quite understand it:

• Is there a method to detect an active man-in-the-middle?
• Preventing a spoofing man in the middle attack?
• How does SSL/TLS work?

Summary

1. Is it possible for someone to be a man-in-the-middle if that someone controls the IT infrastructure? If so, how exactly?
2. Is my login and password read in plain text on the employer's web proxy server?
3. What should I check in the browser to verify that I have a secure connection from the browser all the way to the Gmail server?

EDIT, 18.07.2014

• Privacy is not a concern. I'm just curious about how TLS works in this particular scenario. What other means the employer has to intercept communication (keylogger etc.) are not relevant in this particular case.
• Legal matters aren't a concern. Employees are allowed to use company IT equipment for private communication within certain limits. On the other hand, the employer reserves the right to do monitoring without violating privacy.

Answer 1

You are absolutely correct in your assumptions.

If you are using a computer owned and operated by your employer, they effectively have full control over your communications. Based on what you have provided, they have installed a root CA certificate that allows them to sign a certificate for Google themselves.

This isn't that uncommon in the enterprise, as it allows inspection of encrypted traffic for virus or data leaks.

To answer your three questions:

1. Yes it is very possible, and likely. How active they are at monitoring these things is unknown.

2. Your password can be read in plain text by your employer. I don't know what you mean about the web server.

3. You can check the certificate to see who signed it, as you have already done. You can also compare the fingerprint to that of Google (checked from a third party outside of business control)

Edit:

How exactly is my employer able to unencrypt that? Could you perhaps elaborate on that a bit?

You are using the bad certificate to connect to an intermediary device such as the firewall, that device is then connecting to Google using the correct certificate. The communication is encrypted from your client to the MITM, decrypted, and then re-encrypted on its way to Google.

Answer 2

1 and 2 are answered by David Houde

3:

There's not actually any way to tell for sure whether you are securely talking to Gmail when using your company's machine (aside from auditing the machine down to the metal). Even if they didn't change the cert, they could simply modify the web browser to forward all decrypted traffic somewhere. There are a million other things they could do. It just so happens that in this case, they installed their own root certificate which allows you to see what they've done.

Answer 3

I don't see anyone mentioning it so allow me to point something out. Maybe I'm wrong but doesn't certificate pinning implemented in Google Chrome (there is a plugin for Firefox as well) prevents the certificate spoofing?

Related question and answers.

Of course it is possible to sniff someones traffic if you control the infrastructure. But this is possible to some extent and in my opinion it depends on how restricted user actions are and what is the knowledge of the user. Google Chrome is the browser that can be installed within User Profile and I think it does not require administrative privilege. You can also verify the checksum of installation package to verify it hasn't been modified on-the-fly. Since Google Chrome uses certificate pinning regardless of Operating System cert store - is it still vulnerable to MITM?

I do not see any way of preventing users from using portable version of VirtualBox with client OS that will have a bunch of privacy oriented tools that will significantly elevate the chance of securing the communication to any website/domain.

Please, feel free to correct me if I'm wrong in any of the above.

----------

Edit.

Ok. So i found out a solution to check if the certificate has been spoofed. It supposedly does not work perfectly for google and apple but it might be what you are looking for in case of other domains.

To the point:

There is a site https://www.grc.com/fingerprints.htm that can check remote certificate fingerprint for you. You can then compare it with the one u see within your browser to check if they match. If they do not match - this cert is spoofed (Exception is mentioned in the section *What can go wrong with this test?* on the mentioned page.).

Here's proof it works. Browser cert:

Fingerprint from grc.com verification:

I think since you are mentioning something along the lines of mass-surveillance the certificate spoofing will also be on multiple https sites. In that case if one will be confirmed to be spoofed i think you can assume all of them are.

---

Next edit.

Just for the sake of completing the answer. Since it might be the case where some state or organization modify the browser completely and the browser cannot be trusted to confirm the validity of certificate. I've found a powershell function that performs an SSL connection to specified address and displays some useful information about the certificate.

Here is the code (alias is mine):

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

You can paste it in the powershell console - this will register the function for the time of current session (until you close the powershell console window so you leave no trace).

After that you can type in the same window:

TSSL www.ipko.pl

The output will look like that:

I've found a function code here.

Answer 4

As others pointed out: Yes, it is possible and it is being done in this case.

Trying to detail more the steps involved in this MITM:

You know that certificate 028CA85E6765… belongs to gmail because a CA (GeoTrust, Verisign…) has asserted that it does. Your OS/browser contain a list of CAs it trust to do the right thing (not to lie, be properly secured…).

• Your employer has installed in your computer its own CA.
• When you connect to accounts.google.com with TLS, the proxy issues itself a new certificate for accounts.google.com signed by that CA (if it doesn't already have one).
• Your connection to the proxy is done using the fake accounts.google.com certificate. The proxy meddles with the content as it whishes, then connects to the real accounts.google.com (using Google's certificate) and sends back and forth the contents you and gmail give to each other.
• As your computer trusts the proxy CA, it considers that the accounts.google.com certificate issued by your employer is legitimate¹ thus why there are no warnings.

¹ Most people would consider it is not legitimate because it's not Google's certificate, but it is the certificate expected inside this company. Employees may disagree it is desirable, though. :-)

Answer 5

To add to other answers, the only way to ensure, with a reasonable certainty, that you have a secure connection from your browser to the web server, is to use your own equipment. The employer-owned equipment and network is not under your control, and it may be difficult to determine what is included in their standard operating system and applications. Even if it's illegal in the country you are at, if privacy is a concern, you probably should use your mobile phone or personal laptop.