Ist teams.microsoft.com in den USA?

Die Microsoft Netzwerk-Empfehlungen fordern idealerweise einen lokalen Breakout mit lokaler Namensauflösung und bitte keine Proxy-Server oder gar Cloud Server. Ausführliche Informationen habe ich dazu auf mehreren Seiten unter Cloud Verbindung bereits beschrieben. Ein Kunde hat diese Vorgaben umgesetzt und mit der Netzwerküberwachung die verschiedenen Verbindungen protokolliert. Dabei ist aufgefallen, dass "teams.microsoft.com" auf eine IP-Adresse in den USA auflöst. Gehen die Verbindungen und damit auch die Daten von europäischen Nutzern tatsächlich über die USA?

Wo ist "teams.microsoft.com"?

Ich habe die Analysen mal nachvollzogen und der Kunde hat mir folgenden Auszug aus seiner Verkehrsstatistik geliefert:

Hier ist gut zu sehen, dass auf dem Internet-Breakout schon noch viel mehr Verkehr unterwegs ist und der Teams-TCP-Traffic pro Connection nur 0,13-0,17% belegt. Wobei dies natürlich nur ein Ausschnitt ist. sie 100 Clients mit so einer Verbindung haben, dann sind es doch 13-17% der Bandbreite.

Wer selbst solche Daten ermitteln will, kann seine Netzwerkfirewall oder Windows Firewall Logs fragen, moderne Router/Switches per NetFlow/sFlow/IPFix/cFlow auslesen oder Probes z.B.: mit Packetbeat und einem Reporting Backend Influx/Grafana nutzen.

Es gibt im Internet nun verschiedene Dienste, die zu einer IP-Adresse den vermutlichen Ort auf der Welt ermitteln. Solche Datenbanken funktionieren recht gut für Endanwender zuhause, da Inhaltsanbieter z.B. Angebote auf das jeweilige Land anpassen müssen, z.B. "Cookie-Banner" für europäische Anwender oder Besucher kompletten blockieren. Also gebe ich das Beispiel der 52.113.194.132 dort ein

Bei all den Werten stimmt sicherlich, dass das Subnetz aus dem autonomen Netzwerk (BGP) AS8075 zu Microsoft gehört. Aber bedeutet das auch, dass meine Daten in die USA gehen?

Ortsbestimmung

Wo ein Endpunkt ist, lässt sich viel einfacher per PING und anderen Tools ermitteln. Auf der Seite Latenzzeiten und 200ms habe ich das Thema Latenzzeit beschrieben und zitiere hier nur die Landkarte mit den durchschnittlichen Werten.

Wenn ich recht sicher prüfen möchte, wie weit ein Host entfernt ist, dann kann ich das per PING und Traceroute versuchen. Bei mir in Hövelhof erhalte ich dabei folgendes Bild

C:\> ping teams.microsoft.com -4

Ping wird ausgeführt für s-0005.s-msedge.net [52.113.194.132] mit 32 Bytes Daten:
Antwort von 52.113.194.132: Bytes=32 Zeit=19ms TTL=115
Antwort von 52.113.194.132: Bytes=32 Zeit=18ms TTL=115
Antwort von 52.113.194.132: Bytes=32 Zeit=14ms TTL=115
Antwort von 52.113.194.132: Bytes=32 Zeit=18ms TTL=115

Ping-Statistik für 52.113.194.132:     Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:     Minimum = 14ms, Maximum = 19ms, Mittelwert = 17ms

Die Aussage ist ein sehr deutliches Zeichen, dass zumindest die Gegenstelle zu schnell antwortet, um jenseits des Atlantiks zu sein.

Alarmiert wäre ich nur, wenn die Latenzzeit >100ms ist

Aus meinen End2End-HTTP-Tests habe ich auch schätzen gelernt, mal auf den Header einer HTTO-Anfrage zu schauen und auch diese Zeit zu messen. Das geht per PowerShell auch recht einfach.

PS C:\> (Invoke-WebRequest https://teams.microsoft.com -Method head).headers."X-MSEdge-Ref"
Ref A: A961D8A6D97F4A10A7A7F140DA97DF54 Ref B: AM3EDGE0607 Ref C: 2022-03-03T23:21:14Z

Ich wusste natürlich schon, dass der Webserver hinter "teams.microsoft.com" einen Header "X-MSEdge-Ref" liefert. Ich sehe hier drei Referenzen, von denen "Ref B:" vermutlich den Namen des Teams Edge-Servers liefert. Anhand des IATA-Codes für Flughäfen dürfte hier der Server in der Nähe von Amsterdam (AMS) stehen. Analog zu meinen Tests mit den Teams TURN-Server auf worldaz.tr.teams.microsoft.com (Siehe Teams Transport Relay) habe ich natürlich auch hier eine kleine Testserie gemacht:

1..1000 `
| % {Write-host "$($_)"; `
       (Invoke-WebRequest `
          -URI https://teams.microsoft.com `
          -Method HEAD `
       ).headers."X-MSEdge-Ref".split(" ")[5] `
    }

Die Liste der Servernamen kann ich mit "Group" zusammenfassen und habe am 4. März 2022 von 380 unterschiedlichen Servern eine Antwort erhalten. Die Verteilung zeigte, dass mir einige Server recht häufig geantwortet haben aber auch sehr viele Server nur einmal sichtbar waren. Hier nur ein Auszug:

Count Name
----- ----
   17 AM3EDGE0307
   12 AM3EDGE0122
   11 AM3EDGE0919
   10 AM3EDGE0609
    9 AM3EDGE0918
    9 AM3EDGE0508
    8 AM3EDGE1009
    8 AM3EDGE1007
    7 AM3EDGE0819
    7 AM3EDGE0716
    7 AM3EDGE0910
    7 AM3EDGE0708
    7 AM3EDGE0816
    7 AM3EDGE0512
    7 AM3EDGE1015
    7 AM3EDGE1016
    7 AM3EDGE1018
    6 AM3EDGE0220
    6 AM3EDGE0617
    6 AM3EDGE0607
    6 AM3EDGE0319
    6 AM3EDGE0815
    6 AM3EDGE0720
    6 AM3EDGE0817
    6 AM3EDGE0906
    6 AM3EDGE0911
    6 AM3EDGE0114
    6 AMS04EDGE3215
    5 AMS04EDGE3318
    5 AMS04EDGE3418
    5 AM3EDGE0513
    5 AMS04EDGE3011
    5 AM3EDGE0914
    5 AM3EDGE0611
    5 AM3EDGE0614
    5 AM3EDGE0422
    5 AMS04EDGE3211
...

Wenn ich dann weiter nur die ersten drei Buchstaben auswerte um den vermutlichen Standort zu sehen, dann scheinen alle Server in AMS und AM3 zu stehen.

Count Name                      Group
----- ----                      -----
  140 AM3                       {AM3, AM3, AM3, AM3…}
  240 AMS

Da ich parallel per Wireshark mitgeschnitten haben, konnte ich gut ein "Recycling" der TCP-Verbindung sehen. Mein Client nutzte immer den gleichen Sourceport und mit dem gleichen Zielport.

Ich würde das so interpretieren, dass ein Loadbalancer vor den Edge-Servern die HTTP-Requests ohne jegliche Affinität an die unterschiedlichen Frontend-Server weiter gibt.

Ich habe den Tests dann natürlich noch an einem anderen Standort wiederholt und hier hatte ich nur einen Server aus Frankfurt.:

FRA31EDGE0619
FRA31EDGE0619
FRA31EDGE0619
FRA31EDGE0619
FRA31EDGE0619
FRA31EDGE0619
FRA31EDGE0619
FRA31EDGE0619
...

Das ist aber irreführend, denn hier hat der lokale DNS-Server (Cache) und ProxyServer die Messung verfälscht. Wenn ich die Anfragen mit etwas Abstand wiederhole, dann bekomme ich sehr wohl auch hier unterschiedliche Server, die aber alle aus Frankfurt sind.

Da scheint also ein Loadbalancer davor zu stehen, denn die IP-Adresse ist immer gleich. Ich vermute nicht, dass Microsoft ihre Server mit Network Load Balancing (NLB) betreibt.

Auch eine Zeitmessung ist möglich, wobei hier der Parameter "-Method HEAD" dafür sorgt, dass nur der kleine Header geladen wird und nicht die ca. 200kByte "Startseite" von Teams, was die Zeit doch arg verlangsamen würde

PS C:\> (measure-command {invoke-WebRequest https://teams.microsoft.com }).totalmilliseconds
148,0558

Die 164ms bedeuten nicht, dass die Daten aus den USA kommen. beim HTTPS findet ein TCP-Handshake (Siehe TCP SYN ACK RES) und ein TLS-Handshake (Siehe TLS Handshake mit NetMon) statt. Das sind also durchaus einige Pakete mehr, die hier sequentiell übertragen werden. Sie können gerne mit Wireshark dem System auf die Finger schauen.

Interessant ist hier auch die "Relative Time" am Anfang, die eine sehr schnelle und kurze Latenzzeit anzeigt. Wireshark kann sogar die Latenzzeiten selbst grafisch aufzeigen, was bei so wenige Paketen aber keine sinnvollen Bilder erzeugt.

Wir können damit aber schon sicher sein, dass zumindest die Verbindung vom Client auch bei einem Server in Amsterdam landet.

Ob der Edge-Server dann den Request nicht doch in die USA weiter gibt, kann ich so noch nicht prüfen, Dazu müsste ich eine echte Datenverbindung des Clients mitschneiden und die Antwortzeit der Zugriffe interpretieren, denn Sie setzen sich aus der Netzwerklatenzzeit und der eigentlichen Serviceantwortzeit zusammen.

Anycast IP

Microsoft nutzt für Teams das "Anycast-IP"-Verfahren (Siehe Anycast-Routing) , bei der alle Teams Server in der weiten Welt die gleiche IP-Adresse haben. Google macht es auch mit 8.8.8.8(8.8.4.4 und auch 9.9.9.9 ist so in der Welt verteilt. Sie können das einfach verifizieren indem Sie verschiedene DNS-Server im Internet nach "teams.microsoft.com" fragen. Eine nette Liste von im Internet frei erreichbaren DNS-Servern finden Sie z.B. auf https://www.ungefiltert-surfen.de/. Suchen Sie sich einfach ein paar Server in de Welt aus und fragen Sie diese per NSLOOKUP oder Resolve-DNS name

REM Namensauflösung gegen einen bestimmten DNS-Server
REM Bitte statt x.x.x.x die IP-Adresse oder den Namen eines erreichbaren DNS-Servers eingeben
nslookup teams.microsoft.com x.x.x.x

Per PowerShell geht das natürlich auch:

# Bitte x.x.x.x durch einen DNS-Server ersetzen
Resolve-DnsName teams.microsoft.com -Server x.x.x.x

Es ist kein Problem wenn viele Server weltweit die gleiche Public-IP-Adresse haben, solange Sie alle die gleichen Informationen liefern und natürlich nicht nebeneinander im gleichen Subnetz stehen. Danke BGP-Routing finden die Router immer den besten Weg und auch Störungen und Verbindungsunterbrechungen werden sehr schnell überbrückt. Natürlich terminiert Microsoft diese IP-Adresse vermutlich auf einem Loadbalancer, der dann die Pakete an einen verfügbaren Server weiterreicht.

Daten über teams.microsoft.com

Jegliche Verbindung zu teams.microsoft.com erfolgt per HTTPS und verschlüsselt. Ich habe zu diesem Endpunkt keine andere Kommunikation feststellen können. Sie können natürlich nicht per Wireshark in die Daten schauen, das Sie nicht den Private-Key der Gegenseite kennen. Aber sie können lokal mit einem ProxyServer wie z.B. Fiddler natürlich etwas mehr unter die Haube schauen. Dabei stellen Sie fest, dass im Wesentlichen folgende Dienst über diesen Endpunkt laufen.

  • Download von Teams, JavaScript, Apps
    Schon vor der ersten Nutzung von Teams greifen Sie auf teams.microsoft.com zu, um Teams als App oder im Browser herunter zu laden und zu starten. Über den Weg bekommen Sie auch Updates für Teams.
  • Anmeldung
    Auch wenn die eigentlichen Authentifizierung über das AzureAD erfolgt, senden Sie ihr OAUTH-Token dann zum Teams-Service, der die Berechtigungen prüft
  • Provisioning
    Nach der Anmeldung bekommen Sie über den Endpunkt auch alle Informationen zur Steuerung ihrer lokalen Teams-Installation, z.B. ob Sie einen Kalender oder ein Dialpad bekommen. Auch die Teams Richtlinien kommen über teams.microsoft.com, sofern Sie den Client betreffen.
  • Presence und StatusUpdates
    Der Teams Client spricht mit teams.microsoft.com um den eigenen Status zu setzen aber auch den Status der anderen Personen abzufragen
  • 1:1 Chat und Chat in Kanälen
    Wenn Sie Nachrichten Lesen oder schreiben, erfolgt dies auch über teams.microsoft.com
  • Signalisierung für VoIP/Meeting
    Die Verbindungen für Audio/Video/Desktopsharing benötigen eine Steuerungskanal, der ebenfalls über teams.microsoft.com läuft.

teams.microsoft.com ist daher schon eine zentrale Komponente im Teams Ökosystem. Allerdings werden nicht alle Informationen über diese eine URL übertragen. Teams selbst ist nämlich selbst kein Datenspeicher. Ihre persönlichen Chat-Nachrichten landen in ihrem Exchange Postfach und die Chats in Kanälen in der Microsoft 365 Group. Wenn Sie Anlagen bereitstellen, dann landen diese in der Teams-Bibliothek im SharePoint oder bei einem 1:1 Chat im persönlichen OneDrive. Auf diese Informationen greift der Teams Client und natürlich auch die Office Apps direkt zu. Das geht nicht über "teams.microsoft.com". Auch die komplette Audio/Video-Komunikation geht an teams.microsoft.com vorbei

Wenn Sie hier mehr analysieren wollen, dann ist Fiddler oder der Chromium-Debugger der erste Einstiegspunkt. Ich habe dazu auch einige Informationen auf den weiteren Seiten veröffentlicht

Einschätzung

Es werden immer wieder Falschmeldungen zu Microsoft und Cloud-Diensten lanciert und ich hoffe, dass diese Seite zumindest für Teams genug Informationen liefert, um mehr Transparenz zu schaffen. Die Cloud nutzt geografisch verteilte Frontend-Server, die von den Clients möglichst schnell und ohne Umwege erreicht werden. Latenzzeit ist das größte Problem bei Cloud-Diensten, denn das "Warten" auf Pakete beschränkt die maximalen Durchsätze und damit die Reaktionsgeschwindigkeit auf Aktionen des Anwenders. Latenzzeiten lassen sich aufgrund physikalischer Gegebenheiten wie Entfernung, Lichtgeschwindigkeit, Elektronengeschwindigkeit, Schaltzeiten von Transistoren nicht endlos minimieren, so dass ein guter Cloud-Anbieter immer versuchen wird, die Daten und deren Verarbeitung "nahe am Anwender" zu platzieren. Auch Bandbreite ist nicht endlos zu rentablen Preisen erweiterbar, so dass auch hier eine "Datenablage in der Nähe" zu erwarten ist.

Es gibt aber natürlich regulatorische, programmatische und juristische Grenzen. Wer einen Tenant in Deutschland nutzt und auf Dienstreise in den USA oder Asien ist, wird mit längeren Laufzeiten leben müssen. Microsoft zieht mit dem Postfach nicht dem Benutzer hinterher. Das geht nur manuell in einem "Multi Geo Tenant". Und selbst dann haben wir gelernt, dass die Konferenz-MCU in Teams immer in der Nähe des ersten Teilnehmers gehostet wird.

Ich habe mich hier aber nur auf die "Teams-Netzwerkverbindungen" und z.B. nicht auf Telemetrie konzentriert. Auch wenn ihr Tenant in Europa liegt und alle Anwender in Europa arbeiten, ist es technisch sicherlich möglich, dass Microsoft aus den USA beim Vorliegen entsprechender Beschlüsse auch aus den USA auf Informationen in Europa oder anderen Ländern zugreifen kann. Ob dies tatsächlich erfolgt, wird für den Kunden nur schwer nachzuweisen sein. Ich bin aber sicher, dass Microsoft intern entsprechende Auditlogs führt und damit damit immer das Risiko besteht, dass ein Whistleblower solche Logs ausleitet. Die Folgen für das Geschäftsmodell sind nicht abzuschätzen und das mag auch ein Grund sein, warum Microsoft sich juristisch gegen solche Beschlüsse wehrt. Eine Sicherheit ist es nicht.

Genaugenommen vertrauen wir ja aber auch unserem Telefon-Carrier und seinen Mitarbeitern, dass hier keiner unberechtigt "mithört" und die Informationen verkauft. Hierfür gibt es noch viel mehr Beispiele. Ich bin zumindest "technisch" sicher, dass bei einer korrekten Konfiguration ihres Internetzugangs, VPN-Systeme, DNS-Auflösung u.a. ihr Client mit dem geografisch nahestehenden Teams Frontend Server kommuniziert.

Weitere Link