Was passiert genau?
Nach dem Update schlagen Anmeldeversuche an der NoSpamProxy Web App und über das PowerShell-Modul stillschweigend fehl. Im Windows-Sicherheitsereignisprotokoll erscheint Ereignis-ID 4625 mit dem Statuscode 0xC000035B – einem Hinweis auf einen sogenannten Channel-Binding-Token-Konflikt.
Betroffen sind alle Umgebungen, in denen eine Firewall, ein Proxy oder eine Endpoint-Protection-Lösung mit TLS-Inspektion zwischen Client und NoSpamProxy Server sitzt.
Konkret geht es um die folgenden kumulativen Updates:
- KB5078766 (Windows Server 2022)
- KB5073723 (Windows Server 2019)
- KB5075904 (Windows Server 2019)
Die Ursache: EPA wird verpflichtend
Microsoft hat mit den Januar-2026-Updates den erweiterten Schutz für die Authentifizierung (EPA) im Kernel-Treiber http.sys verpflichtend aktiviert. EPA ist eine legitime Sicherheitsfunktion, die Angriffe durch Weiterleitung von Anmeldedaten verhindert – sogenannte Relay-Angriffe.
Das Prinzip: Bei jeder HTTPS-Verbindung berechnet der Client einen kryptografischen Fingerabdruck (Hash) aus dem TLS-Zertifikat des Servers. Dieser Wert, der sogenannte Channel Binding Token (CBT), wird in die Authentifizierungsanfrage eingebettet. Der Server berechnet denselben Hash aus seinem eigenen Zertifikat und vergleicht beide Werte. Stimmen sie überein, gelingt die Anmeldung. Stimmen sie nicht überein, wird die Anfrage abgelehnt.
Warum TLS-Inspektion das Problem auslöst
TLS-Inspektion ist in Unternehmensnetzen weit verbreitet: Firewalls, Proxys und Endpoint-Protection-Lösungen brechen verschlüsselte Verbindungen auf, um den Datenverkehr auf Bedrohungen zu prüfen. Dabei präsentiert das jeweilige System dem Client sein eigenes Zertifikat, und nicht das des eigentlichen Servers.
Genau hier liegt das Problem: Client und Server berechnen ihren Channel Binding Token aus unterschiedlichen Zertifikaten. Die Werte können niemals übereinstimmen, und die Authentifizierung schlägt fehl.
Der Ablauf im Detail
Bei aktiver TLS-Inspektion passiert folgendes:
- Der Client erhält Zertifikat A (Firewall) und berechnet CBT = Hash (Zert. A).
- Die Firewall/der Proxy inspiziert den Verkehr und leitet die Anfrage weiter.
- NoSpamProxy Server verwendet eigenes Zertifikat B und berechnet CBT = Hash (Zert. B)
- Hash A und Hash B stimmen nicht überein. Die Authentifizierung wird abgelehnt, Status 0xC000035B
Vor den Januar-Updates wurde diese Prüfung von http.sys stillschweigend ignoriert. Das Update macht die Validierung verpflichtend. Die Möglichkeit, sie per Registrierungsschlüssel (EnableCBT = 0 unter HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters) zu deaktivieren, funktioniert nicht mehr.
Die Lösung: TLS-Inspektion für NoSpamProxy ausschließen
Die empfohlene und sichere Lösung ist, die URL von NoSpamProxy Server von der TLS-Inspektion auf der Firewall oder dem Proxy auszuschließen. Die Verbindung bleibt dabei weiterhin vollständig verschlüsselt, sie wird lediglich nicht mehr vom zwischengeschalteten System aufgebrochen.
Vollständiger Ausschluss:
https://nsp-server-fqdn:443/*
Mindestausschluss (nur Identity Service):
https://nsp-server-fqdn:443/api/identity-service/*
Ersetzen Sie nsp-server-fqdn durch den vollqualifizierten Domänennamen Ihres NoSpamProxy-Servers, z. B. nsp.example.com.
Häufig gestellte Fragen
Kann ich das Windows-Update stattdessen zurücksetzen?
Dies ist möglich, wird jedoch nicht empfohlen. Die kumulativen Updates enthalten wichtige Sicherheitskorrekturen. Das Ausschließen der NoSpamProxy-URL von der TLS-Inspektion ist die korrekte Lösung und reduziert Ihre Sicherheitslage nicht, da die Verbindung zwischen Client und Server weiterhin durchgehend verschlüsselt bleibt.
Sind alle NoSpamProxy-Komponenten betroffen?
Nur die Anmeldung an der NoSpamProxy Web App und die Verbindung über das PowerShell-Modul (Connect-Nsp) sind betroffen. E-Mail-Verarbeitung und Gateway-Funktionen verwenden keine Windows-Authentifizierung und sind nicht beeinträchtigt.
Sind domänenbeigetretene und eigenständige Server gleichermaßen betroffen?
Ja. Die Channel-Binding-Token-Validierung arbeitet auf der TLS-Transportschicht und ist unabhängig von der Active-Directory-Domänenmitgliedschaft.
Welche Alternativen gibt es?
Kunden können stattdessen OpenID zur Authentifizierung verwenden. OpenID Connect basiert weder auf NTLM noch auf Negotiate und ist daher von der Channel-Binding-Token-Validierung oder TLS-Inspektion nicht betroffen.
Wird das Problem dauerhaft behoben?
Ja. Ab NoSpamProxy 16.1 wird der Identity Service auf Basic Authentication über TLS umgestellt. Dieses Verfahren verwendet keine Channel Binding Tokens und ist daher dauerhaft immun gegenüber diesem Problem.
