QUIC und Microsoft 365

QUIC ist nicht nur ein Protokoll für Amazon, Google, Facebook und Co. Auch Microsoft 365 nutzt direkt und Indirekt schon QUIC, was sich manchmal auf das Verhalten der Clients niederschlägt. Wenn ein Client vom Server "QUIC" angeboten bekommt aber die Verbindung dann nicht oder gestört zustande kommt, kann dies einen negativen Einfluss auf die Funktion des Clients haben.

Exchange Online

Der erste Cloud-Dienst, den Microsoft offizielle für QUIC aktiviert hat, war Exchange Online. In der Liste der Microsoft 365 IP-Ranges erschien irgendwann "443/UDP" in der Liste der "erforderlichen Ports"

Das hat mich natürlich interessiert und entsprechende habe ich mich mit meinem Exchange Online Postfach sowohl mit Edge als auch Outlook verbunden und der Kommunikation auf die Finger geschaut.

Outlook im Browser

Im Edge-Browser kann ich über den Debugger sehr schnell die URLs, Domains und das verwendete Protokoll sehen:

Microsoft nutzt für folgende Domain tatsächlich schon QUIC:

                outlook.office.com
              substrate.office.com
                res.cdn.office.net
res.public.onecdn.static.microsoft

Outlook Classic

Bei "Outlook Classic" kommt im September 2024 aber noch kein QUICK zum Einsatz. Ich konnte keine Zugriffe über Wireshark, Procmon u.a. Tools

Modern Outlook

Das "neue" Outlook ist keine EXE mehr, sondern ist eine "Modern App" mit JavaScript, CSS, HTML und nutzt MSWebView:

Damit kommuniziert die Software natürlich auch nicht mehr nativ per TCP oder WINHTTP, sondern bedient sich des Chromium-Unterbaus. Ich habe daher alle Programme, z.B. Teams, beendet, die ebenfalls MSWebView2 nutzen und dann das neue Outlook mit aktiviertem Wireshark neu gestartet. Es waren einige TCP aber auch UDP-Ports zu sehen.

Auch Wireshark liefert einige Verbindungen zur fraglichen Zeit

Die meisten UDP-Pakete sind zum Subnetz 52.98.179.0 gegangen, welches eindeutig zu Microsoft zugeordnet werden kann.

Diese Adressen sind zwar nicht per ReverseDNS auf einen Server aufzulösen, aber die ebenfalls im Wireshark protokollierten DNS-Anfragen zeigen, dass eine Anfrage auf "outlook.office.com" auf eben diese Adressen aufgelöst wurde und der Bereich ist auch bei Microsoft für Exchange Online geführt


https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide

Wir können also festhalten, dass das "modern Outlook" sehr wohl schon QUIC nutzt.

Microsoft Teams

Bei Microsoft Teams habe ich mit auf den Aufruf per Browser beschränkt. Die installierte Desktop-Version ist im wesentlichen der gleiche Code nutzt ebenfalls Chromium als Unterbau. Im Tage habe ich zu dem Zeitpunkt keine "h3"-Zugriffe auf die Domain "teams.microsoft.com" gesehen. Allerdings gab es QUIC-Zugriff auf folgende URLs

            res.cdn.office.net
          res-1.cdn.office.net
           substrate.ofice.com

Microsoft nutzt hier QUIC für die Verteilung von Teams Programmteilen vom Content Delivery Network

SharePoint Online

Der Zugriff auf SharePoint über einen Browser kann ich sehr einfach wieder im Chromium Debugger analysieren. Sehr schnell wird auch hier klar dass im Sep 2024 erst einmal die statischen Inhalte aus dem Content Delivery Network über QUIC ausgeliefert werden.

CDN

Microsoft betreibt zwar ein sehr großes eigenes Netzwerk und sollte auch ganz viel Bandbreite, lokale Standorte und Server haben, aber dennoch bedient sich Microsoft bei den "Content Delivery Networks" von anderen Firmen. Sie erkennen dies, dass die Zugriffe auf IP-Bereiche gehen, die nicht im primären Microsoft Dokument aufgeführt sind. Dort gibt es aber auch den Hinweis auf die CDNs.


Microsoft 365 URLs and IP address ranges - Related Topics
https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#related-topics 

Jeder dieser weiterführenden Links zeigt auf eine Seite, die wiederrum IP-Adressen, DNS-Namen oder Links zum eigentlichen Anbieter enthält.

Die Domainnamen der CDNs sind uns ja bekannt und ein einfacher Invoke-Webrequest liefert schon die ein oder andere Information:

Invoke-WebRequest https://res.cdn.office.net
$error[0].exception.response.headers

In dem Beispiel bin ich bei Verizon gelandet, die QUIC anbieten und "frc" könnte ein Hinweis auf Frankfurt sein. Der Zugriff auf "https://res-1.cdn.office.net" liefert von meinem Client als CDN-Anbieter die Firma "Akamai".

Invoke-WebRequest https://res-1.cdn.office.net
PS C:\> $error[0].exception.response.headers

Key Value
--- -----
x-ms-request-id               {d1a364f8-001e-001c-0aa5-14adf7000000}
Pragma                        {no-cache}
Date                          {Wed, 02 Oct 2024 08:29:51 GMT}
Alt-Svc                       {h3=":443"; ma=93600}
Connection                    {keep-alive}
Akamai-Request-BC             {[a=2.19.96.159,b=341464508,c=g,n=DE_NW_DUSSELDORF,o=20940],[c=c,n=DE_HE_FRANKFURT,o=20940],[a=20.38.118.13…
Report-To                     {{"group":"NelM365CDNUpload1","max_age":604800,"endpoints":[{"url":"https://M365CDN.nel.measure.office.net/…
NEL                           {{"report_to":"NelM365CDNUpload1","max_age":604800,"include_subdomains":true,"failure_fraction":1.0,"succes…
Server-Timing                 {clientrtt; dur=7, clienttt; dur=15, origin; dur=2 , cdntime; dur=13}
Akamai-Cache-Status           {NotCacheable from child}
Timing-Allow-Origin           {*}
Access-Control-Expose-Headers {date,Akamai-Request-BC,X-Cdn-Provider,X-Ms-Re…
Access-Control-Allow-Origin   {*}
Strict-Transport-Security     {max-age=31536000; includeSubDomains}
X-CDN-Provider                {Akamai}

Auch hier ist wieder der "Alt-Svc"-Header gesetzt. Das Feld "Akamai-Request-BC" enthält anscheinend auch Details zur Quelle.

PS C:\> $error[0].exception.response.headers.GetValues("Akamai-Request-BC").split("],")

[a=2.19.96.159,b=341464508,c=g,n=DE_NW_DUSSELDORF,o=20940
[c=c,n=DE_HE_FRANKFURT,o=20940
[a=20.38.118.132,c=o]

Zwischenstand

Anfang Oktober 2024 hat Microsoft erst einmal für Exchange Online auf den eigenen Servern aktiviert. Dass die meisten CDNs mittlerweile ebenfalls QUIC aktiviert haben, dürfte vielen Administratoren noch nicht aufgefallen sein. "Es tut doch alles" ist eine oft gehörte Aussage. Allerdings merken wohl die Firmen eine Verschlechterung, die QUIC in ihrem Netzwerk nur auf der Firewall unterbunden haben. Ein Client bekommt selbst bei aktivierter HTTPSProxy-Inspection durchaus den "Alt-Svc"-Header geliefert und versucht natürlich eine Verbindung per QUIC. Wenn die Firewall diese ausgehenden Pakete dann verwirft, wird der Client etwas ausgebremst. Er wartet nämlich einige Zeit, ehe er die Verbindung per QUC als "brocken" für diese Domain kennzeichnet und wieder auf TCP mit HTTP/2 oder sogar HTTP1.1 zurückschwenkt.

Ich bin gespannt, wie schnell Microsoft auch auf den eigenen Diensten die QUIC-Funktion aktiviert. Bei Exchange ist Sie ja schon aktiv

Weitere Links