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.


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


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?


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


  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.
  • 1
    At least your employer is fair enough to use his own name for the certificate, so you can see it. It would be much harder to find out if he copied everything from the original cert an change only the keys and checksums.
    – Calmarius
    Commented Jul 18, 2014 at 15:00
  • 1
    It is shocking that sites don't deploy SRP to help keep passwords secure as they assume that HTTPS is good enough simbo1905.wordpress.com/2014/05/16/…
    – simbo1905
    Commented Jul 18, 2014 at 22:15
  • Google implements HSTS to help solve this particular issue. HSTS is HTTP Strict Transport Security which locks down the CA of the certificate Gmail uses. Use a browser with support for HSTS to help prevent man in the middle attacks.
    – Frederik
    Commented Apr 27, 2015 at 9:15
  • @simbo1905 Could be an effect of Mozilla et al. pushing "Use HTTPS, it makes you secure!" to people who don't fully understand it. (That was still the case when this was posted, right?) Commented May 21, 2015 at 4:14
  • 1
    @gottlieb76 - are you sure about that? I think if the employer installed a root CA certificate on the computer that you are connecitng from, HSTS would not protect against them intercepting the data in a MITM way.
    – JonnyWizz
    Commented Oct 30, 2015 at 12:55

5 Answers 5


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)


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.

  • 14
    @Lernkurve: In the case of a man in the middle, your browser will receive your employer's forged Gmail certificate instead of the real Gmail certificate. Normally, the browser would detect this situation because it's assumed to be impossible to forge a public keys issued by a credible CA, but if your company install their own root CA certificate, the browser would trust any certificates issued by the company CA and doesn't issue any warnings.
    – Lie Ryan
    Commented Jul 17, 2014 at 11:17
  • 4
    It's worth noting that in many jurisdictions this might be considered a violation of a right to privacy (see article 12 of UDHR) depending on what your employer told you about what they were doing.
    – symcbean
    Commented Jul 17, 2014 at 13:26
  • 5
    @Lernkurve your browser is encrypting it with the public key from your employer's certificate. Then your employer's network monitoring device uses the private key from the employer cert to decrypt the message (and presumably make sure you're not smuggling proprietary data out). It then uses Google's public key to re-encrypt your message and sends it to Google. The same process in reverse occurs for Google's response. Commented Jul 17, 2014 at 13:40
  • 5
    @symcbean In some countries email is considered as normal mail. This means that if the employer reads it, whether encrypted or not, and independently of whether you are using their computer or not, is a criminal offence. For example in Italy you'd be violating art 616 of the criminal code; in which case the employer could be sent to prison for 1 year (3 if their knowledge of the contents of the email damaged the subject [this would probably include the employer fireing the employee])
    – Bakuriu
    Commented Jul 17, 2014 at 19:33
  • 5
    @Bakuriu: The employer isn't doing anything to the e-mail though. The data being inspected are web pages (HTTPS requests), not e-mail (SMTP+TLS or SMTP+SSL or SSMTP). The e-mail is processed by the gmail server, all you get is a web view of it. Trying to apply a strict interpretation would likely implicate gmail (their computers open your e-mail and convert it into an HTML page). If gmail is permitted to handle your e-mail because you've consented, surely your employer has demanded the same consent as a condition of network access.
    – Ben Voigt
    Commented Jul 17, 2014 at 21:46

1 and 2 are answered by David Houde


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.

  • 3
    And even with this way, they could just call their CA-Certificate Verisign3 or something and you would neven suspect it ;-)
    – Falco
    Commented Jul 18, 2014 at 20:24
  • 3
    Exactly. So eventually the question is: who sold you your private laptop and why are you running a preinstalled Windows containing who knows what? Somewhere you have a root of trust :) (And talking about trust roots, did anyone mention CAs? :D)
    – Luc
    Commented Jul 19, 2014 at 1:01

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.



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: enter image description here

Fingerprint from grc.com verification: enter image description here

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 {
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        [Parameter(Position = 1)]
        [int]$Port = 443,
        [Parameter(Position = 2)]
        [Parameter(Position = 3)]
        [int]$Timeout = 15000,
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 ""}).Format(0) -split ", "}
        catch {$SAN = $null}
        $chain = New-Object Security.Cryptography.X509Certificates.X509Chain -ArgumentList (!$UseUserContext)
        $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}
        [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: enter image description here

I've found a function code here.

  • The way that companies can prevent users from installing Virtual Box is to prevent them from installing Virtual Box - either by preventing all software installs, or using a whitelist of acceptable applications. Likewise, boot from USB can be disabled.
    – Johnny
    Commented Jul 18, 2014 at 15:57
  • 1
    @Johnny Yeah. That's quite obvious. If you got the control over GroupPolicy, you have admin rights and so on - you can prevent users from installing programs. You can deny them modification access to certain parts of registry. Still you will not be able to prevent them from executing whatever the program they like and that is why I've specifically stated that they can use **portable** version of Virtual Box. Portable means it works without installation hence no system-modification-rights are needed.
    – mnmnc
    Commented Jul 18, 2014 at 16:01
  • Interesting. Certificate pinning should detect it. But unfortunately, I can't test it. I can't put any unauthorized software on the machine -- not even a portable version of Google Chrome.
    – Lernkurve
    Commented Jul 18, 2014 at 17:34
  • 4
    mnmnc, it turns out pinning is not enforced for certificates chained from private anchors, see chromium.org/Home/chromium-security/… (via reddit)
    – Ángel
    Commented Jul 18, 2014 at 21:13
  • 2
    I remember reading that certificate pinning in Chrome intentionally does not warn if a cert is signed with a specially installed root CA, because this is a perfectly legitimate use-case. Certificate pinning is designed to protect against CA compromise. It is not designed to stop you from intentionally allowing a MitM, because that's the user's call (in this case it's a company computer, so the company gets to make the call). Also, as certificate stores are as protected as the browser, pinning can't be effective against someone adding new root CAs, and there's no reason it should be.
    – cpast
    Commented Jan 3, 2015 at 3:44

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. :-)

  • "certificate 028CA85E6765" Yeah I thought the same. Trouble is, Google uses dozens of certificates. Why they go through the trouble of having many certificates at the same time even if most of them are nowhere near expiring is a mystery to me, but they do. I think the best thing to do is compare fingerprints from the CA.
    – Luc
    Commented Jul 19, 2014 at 1:03
  • @Luc it probably boils down to different clusters/datacenters. AS you pointed out, the right thing for these big companies with many certificates is to check the CA. They usually have their own intermediate authoritym too (eg. “Google Internet Authority G2”)
    – Ángel
    Commented Jul 19, 2014 at 21:45

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.

Not the answer you're looking for? Browse other questions tagged .