[BUG] lsproxy 3.0.4.19 mid-request TLS renegotiation on decrypted connections returns empty response bodies to Microsoft OneAuth clients — breaks Microsoft Teams sign-in fleet-wide
S
Steven Reiche
Environment:
Lightspeed Filter Smart Agent, lsproxy.exe 3.0.4.19
Windows 11, build 10.0.26200.8457
Microsoft Teams 26163.405.4842.717, WebView2 Runtime 150.0.4078.48
Agent configured with machine-wide PAC (http://relay.lsaccess.me:6544/local.pac)
Symptom:
Clicking Sign in in Microsoft Teams opens the sign-in popup, which remains permanently white/blank. Affects all managed devices running the Filter Agent. No block pages are shown and no connections appear blocked (all TCP traffic to the local proxy succeeds), which made this very difficult to diagnose.
Root cause identified:
Before displaying the sign-in page, Teams' auth library (OneAuth) performs federation provider discovery against https://odc.officeapps.live.com/odc/emailhrd/getfederationprovider?domain=<tenant-domain>. When lsproxy SSL-decrypts this connection, it performs a TLS renegotiation mid-request (after the GET is sent, before the response is delivered). Browser clients and curl tolerate the renegotiation and receive the correct body; OneAuth's client does not, and receives a zero-byte response body. OneAuth then fails with:
ServerTemporarilyUnavailable {"ErrorCode":"102","Message":"Federation provider discovery returned an invalid result.","Tag":"76lb9"}
(from the MSTeams client log). With discovery failed, Teams never navigates the sign-in WebView2 to any URL, producing the blank window.
Reproduction (curl through lsproxy):
curl -v --proxy http://127.0.0.1:62312 "https://odc.officeapps.live.com/odc/emailhrd/getfederationprovider?domain=dcboces.org"
Output:
< Via: mitm/20230626, lsproxy.exe 3.0.4.19 [2025-07-30-1542UTC go1.24.4] windows
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
confirming the domain is being MITMed and renegotiated. Process Monitor captures of ms-teams.exe show the corresponding WinINET cache entries for federationprovider and hrd written with EndOfFile: 0 (empty bodies) on every attempt.
Workaround:
Adding officeapps.live.com to both the allow list and the SSL decryption bypass list resolves the issue immediately.
Request:
Fix lsproxy's TLS handling so decrypted connections do not use mid-stream renegotiation (or otherwise deliver intact response bodies to non-browser TLS clients such as Microsoft OneAuth/WinINET). This affects any OneAuth-based Microsoft sign-in flow (Teams, Office activation, OneDrive) on any decrypted endpoint, so per-domain bypasses are only a partial mitigation.
Confirm whether a newer Smart Agent release addresses this.
Consider adding Microsoft identity/discovery endpoints (including odc.officeapps.live.com) to the default decryption bypass set.
Matthew Burg
Thanks for taking the time to write this up — the level of detail (versions, repro steps, and the OneAuth/WinINET behavior) is incredibly helpful. We’ll share this with our Filter/Smart Agent team to review the TLS renegotiation behavior in lsproxy 3.0.4.19 and the impact on Microsoft sign-in flows.
To help us narrow this down quickly:
- Does this happen only when SSL decryption is enabled for that traffic, and does it go away 100% when you bypass decryption (as you noted with officeapps.live.com)?
- Are you seeing the same empty-body behavior with other OneAuth endpoints/apps (e.g., Office activation, OneDrive), or only the odc.officeapps.live.com federation provider discovery call?
- Can you confirm whether this is occurring on all affected devices with the same PAC setup (machine-wide PAC to relay.lsaccess.me), or have you reproduced it with a direct proxy setting to 127.0.0.1:62312 as well?
Also, if you’re open to it, a snippet of the relevant Teams log lines around the 102 error (with any tenant-specific info redacted) would be useful context for the team.
Appreciate you calling out the idea of expanding the default Microsoft-related SSL bypass set too — we’ll pass that along as part of the request.