5
Popfetcher pullution.net 1.2 .NetFramework TLS 1.2 Server 2019 Fehler Gegenseite hat Transportstream geschlossen
Moinsen zusammen!
Habe gerade eine saublöde Problemstellung (eine echte "Buc-Situation"):
Ich verwende seit langer Zeit intern und bei Kunden den uralten Mailfetcher pullution.net in der Version 1.2 (Die 2.x fand ich für < 20 Postfächer immer übertrieben. (SQL-Datenbank etc.))
Dummerweise ist das eine von den Anwendungen, die immer rarer werden: Einfache Funktion. Kostenlos. Kein Schnickschnack, macht, was es soll und das mit einer unglaublichen Zuverlässigkeit.
Nun soll diese .Net-App, die unter Server 2008, (r2), SBS 2011, 2012 problemlos lief und läuft auf einen Server 2019 mit Exchange 2019 umziehen um diesen mit Mails zu füttern. Leider klappt das überhaupt nicht. Evtl. hat ja hier noch jemand ne Idee...
Hintergrund:
Fehlermeldung:
Das deutet z.B. nach
https://codeshare.co.uk/blog/how-to-fix-the-error-authentication-failed- ...
darauf hin, dass es eben ein Problem in der Auswahl des Verschlüsselungsalgorithmus gibt. Soweit, so gut.
Aber: Exakt denselben Fehler kenne ich bereits. Irgendwann hatte mal freenet zwingend auf TLS 1.2 umgestellt. Da ich eine alte private Freenet-Adresse über pullution 1.2 abgerufen habe, ging da erstmal nix mehr. Das habe ich aber lösen können, indem ich mit den Registrywerten für .Net auf Server 2008R2 TLS 1.2 aktiviert habe. Entgegen meinen Annahmen, dass die Kryptographie in der Anwendung hardkodiert ist, (wäre K.O. gewesen) konnte ich das Postfach wieder abrufen. Bedeutet: Pullution 1.2 nutzt die Systemeinstellungen.
Also definitiv: Pullution 1.2 kann TLS 1.2 wenn das vom OS ermöglicht (oder erzwungen?) wird.
Die Settings hierzu sind z.B:
Wie gesagt: Das läuft aktuell auf Server 2012 und auch auf einem 2008R2 problemlos. Nur der Server 2019 mag nicht.
Die Gegenseite (der Mailserver von dem abgeholt wird) bietet hier sogar noch TLS 1.0, TLS 1.1 und TLS 1.2 an. (Mit Nmap kann man das schön herausfinden)
Habe deren Support noch nicht angefragt, aber faktisch heisst das ja, dass mein Client nichtmal TLS 1.x anbietet. (Ich habe das getestet indem ich die Registrywerte durchprobiert habe)
Unverschlüsselt geht der Mailabruf... Aber das will man ja auch nicht...
Die Frage:
Wie geht das zusammen? Anwendung kann TLS 1.2 vom OS vorgegeben verwenden unter 2012 und 2008R2.
Anwendung kann offenbar gar kein TLS unter 2019? .Net 3.5 jeweils aktiviert und sonst auf 4.8. (2008R2 auf 3.5 only aber das ändert ja auch nix)
Diese Registry-Settings hab ich zig-mal kontrolliert und sogar manuell erneuert. (Copy/Paste neigt manchmal zu unauffälligen Leerzeichen...)
Es gibt natürlich auch noch die Schannel-Settings unter
Steht auf Enabled 1 und Disabled by Default 0.
Auch hier andere Protokolle testweise aktiviert und Reboot. No chance.
Die Frage ist also nicht: "Haben auch andere Mütter schöne Töchter" sondern: "Warum weigert sich eine .NetFramework 3.5 Anwendung auf Server 2019 TLS 1.2 (oder TLS überhaupt) zu verwenden. Und: Wie krieg ich das Zicklein dazu?
Von den Entwicklern ist da kein Support mehr zu erwarten und die mag ich auch mit sowas nicht mehr belästigen, auch wenn die sehr nett reagiert haben vor ein paar Jahren, als mal irgendwas anderes war.
Beim Mailprovider habe ich noch nicht angefragt. Wenn ich da nen guten Kollegen mit nem guten Tag erwische bekäme ich evtl. ja die Server-Logs, denn das pullution loggt mal gar nix ausser dem besagten Fehler.
Vileeicht hat ja auch hier jemand ne Idee oder es gibt gar noch nen Irren der pullution 1.2 auf Server 2019 am laufen hat???
Dank und Gruß
el buco
P.S.: OT: Im Psychologiestudium Grundkurs Behaviourismus gab es ein Beispiel von einem Indianer, der regelmässig an einen Fluss geht und Fische fängt. Die Frage ist: Wann wird er schneller aufgeben, wenn es keine Fische mehr gibt?
1.: Wenn er jeden Tag 5-10 Fische gefangen hat und diese nun ab Tag 30 ausbleiben? Oder
2.: Wenn er mal einen Fisch, mal keinen Fisch und mal 20 Fische gefangen hat und er nun ab Tag 30 keinen mehr fängt?
Ich bin seit 2 Tagen der Indianer in Beispiel 2.
Habe gerade eine saublöde Problemstellung (eine echte "Buc-Situation"):
Ich verwende seit langer Zeit intern und bei Kunden den uralten Mailfetcher pullution.net in der Version 1.2 (Die 2.x fand ich für < 20 Postfächer immer übertrieben. (SQL-Datenbank etc.))
Dummerweise ist das eine von den Anwendungen, die immer rarer werden: Einfache Funktion. Kostenlos. Kein Schnickschnack, macht, was es soll und das mit einer unglaublichen Zuverlässigkeit.
Nun soll diese .Net-App, die unter Server 2008, (r2), SBS 2011, 2012 problemlos lief und läuft auf einen Server 2019 mit Exchange 2019 umziehen um diesen mit Mails zu füttern. Leider klappt das überhaupt nicht. Evtl. hat ja hier noch jemand ne Idee...
Hintergrund:
Fehlermeldung:
Fehler beim Verbinden mit Pop3-Server: Fehler bei Authentifizierung, da die Gegenseite den Transportstream geschlossen hat.Das deutet z.B. nach
https://codeshare.co.uk/blog/how-to-fix-the-error-authentication-failed- ...
darauf hin, dass es eben ein Problem in der Auswahl des Verschlüsselungsalgorithmus gibt. Soweit, so gut.
Aber: Exakt denselben Fehler kenne ich bereits. Irgendwann hatte mal freenet zwingend auf TLS 1.2 umgestellt. Da ich eine alte private Freenet-Adresse über pullution 1.2 abgerufen habe, ging da erstmal nix mehr. Das habe ich aber lösen können, indem ich mit den Registrywerten für .Net auf Server 2008R2 TLS 1.2 aktiviert habe. Entgegen meinen Annahmen, dass die Kryptographie in der Anwendung hardkodiert ist, (wäre K.O. gewesen) konnte ich das Postfach wieder abrufen. Bedeutet: Pullution 1.2 nutzt die Systemeinstellungen.
Also definitiv: Pullution 1.2 kann TLS 1.2 wenn das vom OS ermöglicht (oder erzwungen?) wird.
Die Settings hierzu sind z.B:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001 Wie gesagt: Das läuft aktuell auf Server 2012 und auch auf einem 2008R2 problemlos. Nur der Server 2019 mag nicht.
Die Gegenseite (der Mailserver von dem abgeholt wird) bietet hier sogar noch TLS 1.0, TLS 1.1 und TLS 1.2 an. (Mit Nmap kann man das schön herausfinden)
Habe deren Support noch nicht angefragt, aber faktisch heisst das ja, dass mein Client nichtmal TLS 1.x anbietet. (Ich habe das getestet indem ich die Registrywerte durchprobiert habe)
Unverschlüsselt geht der Mailabruf... Aber das will man ja auch nicht...
Die Frage:
Wie geht das zusammen? Anwendung kann TLS 1.2 vom OS vorgegeben verwenden unter 2012 und 2008R2.
Anwendung kann offenbar gar kein TLS unter 2019? .Net 3.5 jeweils aktiviert und sonst auf 4.8. (2008R2 auf 3.5 only aber das ändert ja auch nix)
Diese Registry-Settings hab ich zig-mal kontrolliert und sogar manuell erneuert. (Copy/Paste neigt manchmal zu unauffälligen Leerzeichen...)
Es gibt natürlich auch noch die Schannel-Settings unter
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\ClientAuch hier andere Protokolle testweise aktiviert und Reboot. No chance.
Die Frage ist also nicht: "Haben auch andere Mütter schöne Töchter" sondern: "Warum weigert sich eine .NetFramework 3.5 Anwendung auf Server 2019 TLS 1.2 (oder TLS überhaupt) zu verwenden. Und: Wie krieg ich das Zicklein dazu?
Von den Entwicklern ist da kein Support mehr zu erwarten und die mag ich auch mit sowas nicht mehr belästigen, auch wenn die sehr nett reagiert haben vor ein paar Jahren, als mal irgendwas anderes war.
Beim Mailprovider habe ich noch nicht angefragt. Wenn ich da nen guten Kollegen mit nem guten Tag erwische bekäme ich evtl. ja die Server-Logs, denn das pullution loggt mal gar nix ausser dem besagten Fehler.
Vileeicht hat ja auch hier jemand ne Idee oder es gibt gar noch nen Irren der pullution 1.2 auf Server 2019 am laufen hat???
Dank und Gruß
el buco
P.S.: OT: Im Psychologiestudium Grundkurs Behaviourismus gab es ein Beispiel von einem Indianer, der regelmässig an einen Fluss geht und Fische fängt. Die Frage ist: Wann wird er schneller aufgeben, wenn es keine Fische mehr gibt?
1.: Wenn er jeden Tag 5-10 Fische gefangen hat und diese nun ab Tag 30 ausbleiben? Oder
2.: Wenn er mal einen Fisch, mal keinen Fisch und mal 20 Fische gefangen hat und er nun ab Tag 30 keinen mehr fängt?
Ich bin seit 2 Tagen der Indianer in Beispiel 2.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6327961397
Url: https://administrator.de/forum/popfetcher-pullution-net-1-2-netframework-tls-1-2-server-2019-fehler-gegenseite-hat-transportstream-6327961397.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
5 Kommentare
Neuester Kommentar
Ich würde auf blöd mal schauen, ob der Fetcher auch wirklich auf den richtigen Port versucht sich zu verbinden.
Ansonsten, auf Grund des Alters der Anwendung, nach Alternativen schauen.
POPCon ist recht günstig und braucht auch keine eigene Datenbank.
Ansonsten, auf Grund des Alters der Anwendung, nach Alternativen schauen.
POPCon ist recht günstig und braucht auch keine eigene Datenbank.
Moin,
Nur weil die Kisten TLS 1.2 können, heißt das nicht, daß überall auch die richtigen Cipher-Suites sind. Siehe z.B. https://learn.microsoft.com/de-de/power-platform/admin/server-cipher-tls ...
Schau mal welche Cipher-Suites jeweils unterstützt werden.
lks
Nur weil die Kisten TLS 1.2 können, heißt das nicht, daß überall auch die richtigen Cipher-Suites sind. Siehe z.B. https://learn.microsoft.com/de-de/power-platform/admin/server-cipher-tls ...
Schau mal welche Cipher-Suites jeweils unterstützt werden.
lks
Nö, die Ports habe ich natürlich auch gecheckt. Falscher Port führt zu anderem Fehler.
Ich denke, dass die Richtung mit den Cipher-Suites gut ist. Theoretisch müsste das mit dem Server 2019 passen, Danke für den Link, @lks
Die bei einer funktionierenden Verbindung ausgehandelte ist jedenfalls auch im Angebot des 2019er.
Habe nun testweise mal auf einem Win10 Client im Kundennetz installiert. Läuft auf Anhieb.
Einen Wireshark mag ich auf nem produktiven Kundenserver nicht installieren...
Mal sehen was der Anbietersupport sagt. Habe die mal um das Serverlog gebeten.
Das muss ja irgendwie lösbar sein.
Und wieder ein Wochenende rum...
Buc
Ich denke, dass die Richtung mit den Cipher-Suites gut ist. Theoretisch müsste das mit dem Server 2019 passen, Danke für den Link, @lks
Die bei einer funktionierenden Verbindung ausgehandelte ist jedenfalls auch im Angebot des 2019er.
Habe nun testweise mal auf einem Win10 Client im Kundennetz installiert. Läuft auf Anhieb.
Einen Wireshark mag ich auf nem produktiven Kundenserver nicht installieren...
Mal sehen was der Anbietersupport sagt. Habe die mal um das Serverlog gebeten.
Das muss ja irgendwie lösbar sein.
Und wieder ein Wochenende rum...
Buc
Moin,
Gruß,
Dani
Die bei einer funktionierenden Verbindung ausgehandelte ist jedenfalls auch im Angebot des 2019er.
Wie hast du das festgestellt? Welche TLS Version und Cipher Suite wird genutzt?Habe nun testweise mal auf einem Win10 Client im Kundennetz installiert.
andere .NET Versionen? Welche TLS Version und Cipher Suite wird hier genutzt?Einen Wireshark mag ich auf nem produktiven Kundenserver nicht installieren...
Aus welchen Gründen? Wir haben auf jeden Server Wireshark und Fiddler inzwischen standardmäßig drauf. Weil ohne beide Tools bist du beim Troubleshooting inzwischen aufgeworfen.Und wieder ein Wochenende rum...
Ja, gut. Da bist du ein Stück weit auch selbst schuld, oder?!Gruß,
Dani
So. Gelöst. @lks hatte mich auf den richtigen Weg gebracht und @Dani hat die nötigen Fragen gestellt auch wenn ich's erst nach der Lösung gesehen hatte.
Schritte:
1.: Abklären welche CipherSuites der Mailserver anbietet. (Habe ich mit nmap gemacht)
2.: Nachsehen welche CipherSuites auf dem (Client-)Server wirklich aktiv sind. (Und nicht auf das MS Dokument verlassen, welche standardmässig aktiviert sein sollen)
https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suit ...
Die aktiven CipherSuites befinden sich im folgenden Regitry Schlüssel:
Da ergab sich dann, dass viele Algorithmen aus unbekannten Gründen auf diesem Server nicht aktiviert waren. Die Liste war sehr überschaubar...
3.: Manuell mit PS die fehlenden CipherSuites aktivieren. z.B.
Anleitung hier: https://learn.microsoft.com/en-us/powershell/module/tls/enable-tlscipher ...
4.: Registry Settings für .Net , Schanell und TLS wieder auf die empfohlenen sicheren Werte setzen, falls man damit vorher rumgespielt hat. (siehe oben)
5.: Kopschütteln, durchatmen, freuen und Mails abrufen.
Danke Kollegen!
Buc
Schritte:
1.: Abklären welche CipherSuites der Mailserver anbietet. (Habe ich mit nmap gemacht)
2.: Nachsehen welche CipherSuites auf dem (Client-)Server wirklich aktiv sind. (Und nicht auf das MS Dokument verlassen, welche standardmässig aktiviert sein sollen)
https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suit ...
Die aktiven CipherSuites befinden sich im folgenden Regitry Schlüssel:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\FunctionsDa ergab sich dann, dass viele Algorithmen aus unbekannten Gründen auf diesem Server nicht aktiviert waren. Die Liste war sehr überschaubar...
3.: Manuell mit PS die fehlenden CipherSuites aktivieren. z.B.
PS C:\>Enable-TlsCipherSuite -Name "TLS_DHE_RSA_WITH_AES_256_CBC_SHA" Anleitung hier: https://learn.microsoft.com/en-us/powershell/module/tls/enable-tlscipher ...
4.: Registry Settings für .Net , Schanell und TLS wieder auf die empfohlenen sicheren Werte setzen, falls man damit vorher rumgespielt hat. (siehe oben)
5.: Kopschütteln, durchatmen, freuen und Mails abrufen.
Danke Kollegen!
Buc
