Teams Protector Forward Proxy - Technical Deep Dive

Prerequisites

  1. User desktops are configured to send selected Teams traffic to the SphereShield proxy.

    1. HTTPS traffic is proxied for the following host names and some of their subdomains:
      sharepoint.com
      sharepointonline.com
      teams.microsoft.com
      pipe.skype.com
      Further explanations of why this traffic needs to be intercepted: https://agatsoftware.atlassian.net/wiki/spaces/SKYP/pages/645333048

    2. A PAC file or other method (e.g. proxy chaining) is used to ensure that only the relevant HTTPS traffic is proxied. All other traffic including real time media traffic isn’t proxied.

  2. The Bastion proxy is configured with a SSL certificate to decrypt the traffic from the client. The certificate can be provided by the customer, signed by their internal CA or an AGAT certificate can be used.

    1. The relevant CA will need to be trusted on the client desktop.

Traffic Flow

  1. User opens desktop client or http://teams.microsoft.com in browser

  2. Client is redirected to authenticate using either vanilla O365 authentication, ADFS or another federated authentication process.
    SphereShield does not intercept this traffic and therefore doesn’t process user credentials.

  3. Client downloads and opens the Teams web app. The desktop client is an Electron wrapper of the web app.

    1. The Teams app comprises a number of javascript and static files such as CSS, audio and graphics. The majority of these files are downloaded directly from Microsoft Teams servers (teams.microsoft.com/statics/*)

    2. Others static files are downloaded via the SphereShield proxy.
      Primarily: /hashedjs/3.1-app.min-xxxxxx.js and /hashedjs/3.2-app.min-xxxxxx.js
      We modify these files to provide us with the capability to monitor user activity and provide visual indications when we block user actions due to Ethical Wall (EW) or DLP functionality.

    3. Microsoft frequently modifies these files, so the SphereShield proxy dynamically injects the required modifications, rather than using statically hosted files.

    4. User will download these modified web app javascript files via the AGAT CDN hosted by AWS to ensure sign in is not delayed. This functionality can be disabled if required.

  4. Access Control

    1. The username is checked to make sure that the user is permitted to use the proxy. E.g. On a managed workstation they may only sign in using their corporate credentials and not private Microsoft credentials.

    2. If users are prohibited from accessing other Teams tenants as guests, this is also enforced when switching tenant from within the app.

    3. Users can also be blocked from accessing meetings anonymously.

  5. Chat

    1. Chat messages sent are proxied and scanned by DLP/EW ({region}.ng.msg.teams.microsoft.com)

    2. The sender will be notified inline visually if their message is blocked or modified.

    3. Messages received are also checked and users are notified where relevant ({region}.notifications.teams.microsoft.com).

  6. Files

    1. When a user sends files, Teams usually uploads them to Sharepoint and then offers the user to share them with recipients. This is done behind the scenes and the user often doesn’t realize that SharePoint is used here.

    2. SphereShield can be configured to DLP scan files in real time or totally block file sending using fine grained EW policies. In these scenarios files are blocked before they reach the Microsoft Teams servers.

    3. SphereShield can also be configured to scan messages at the time of sharing, which ensures that if files have been modified since being uploaded to SharePoint then the latest version is scanned before being shared.

    4. The built in SphereShield regex based DLP engine or the customer’s existing third party DLP engine can be used. In the latter case latency between the SphereShield proxy and the DLP engine should be considered.

  7. Meetings

    1. Audio/Video/Screen Sharing
      When a user initiates or receives audio, video or any form of data collaboration such as screen sharing, these actions are checked for conformance with EW policies.
      It these actions are permitted the client sends or receives this real time data directly, not via the proxy.
      If an action is blocked, the client is instructed to show a notification that the action was blocked, the EW policy responsible as well as an incident ID.

 

Direct, non proxied Traffic

Proxied Traffic

Direct, non proxied Traffic

Proxied Traffic

Sign in

Most static web app files

Real time media (audio/video/screen share)

Web socket signaling traffic

Some modified web app files (via CDN not forward proxy)

Chat, meeting and Team/Channel messages

Contact data

Sharepoint file data

Inline Images

User notifications

Presence

Content/Contact Search

Guest Access to other Teams tenants

Direct, non proxied traffic hosts

These aren’t usually specified explicitly, they are just excluded from the PAC file because they are not specified in the whitelist.

login.microsoftonline.com
*.officeapps.live.com
*.agatcloud.com
officeclient.microsoft.com
*.events.data.microsoft.com
*.asm.skype.com
*.pipe.aria.microsoft.com
*.delve.office.com
*.userstore.skype.com
*.cdn.office.net
*.teams.cdn.office.net
*.myanalytics.cdn.office.net
*.azureedge.net
*.onenote.com
*.vortex.data.microsoft.com