REST Indy Server auf SSL Port 8443 / 4443 / 10443

[Supergr]

Hallo Zusammen,

ich habe einen Indy HTTP Server mit SSL für eine REST-Schnittstelle gebaut.
Leider kann ich im Firmennetzwerk den Port 443 nicht nehmen. Lokal oder Netzintern läuft der 443 perfekt.

Jetzt versuche ich das ganze mit einem Ausweichport zum machen. Also 8443, 4443 oder 10443.

Leider verweigert der Server damit die Arbeit. Die Ports sind im System ungenutzt!

Ich bekomme auch ein Connect / Disconnect Ereignis im Debugger hin aber zum Frecken kein OnCommand um die Daten zu verarbeiten.
Sobald ich wieder auf 443 Wechsel läuft es. Mag der Indy keine anderen SSL Ports?

Hat jemand sowas schon mal gehabt und eine Idee wie ich den Server zu laufen bekomme?
Sämliche KI's konnten mir keine Tips mehr geben...

Danke
Stevie

PS:Firewall ist temporär ausgeschaltet damit sie nicht dazwischenfunkt!

[shebang]

Hast du dir mit Wireshark schonmal angeschaut, ob es irgendwelche Auffälligkeiten auf Ebene der Pakete gibt?

[Kas Ob.]

Hi,

Zitat von Supergr:

Sobald ich wieder auf 443 Wechsel läuft es. Mag der Indy keine anderen SSL Ports?

Hat jemand sowas schon mal gehabt und eine Idee wie ich den Server zu laufen bekomme?
Sämliche KI's konnten mir keine Tips mehr geben...

Danke
Stevie

PS:Firewall ist temporär ausgeschaltet damit sie nicht dazwischenfunkt!

Indy has nothing to do with this.

Your problem is Windows Defender, it is evolving at increased pace and Microsoft adding features and activating them, without prior notice, may be they are testing, Windows Defender is tranforming into a beast, a stateless protection octopus-like creature, from stopping services from listening to socket to limit permissions and privileges, out of blue, requiring manual interaction from IT or administrator or even users to adjust policies.

If you look at the features included in EndPoint and XDR you might get a glimpse where Defender is going
https://learn.microsoft.com/en-us/de...es-by-platform

From "Attack Surface Reduction" to "Next-generation protection" to "Network Protection" to....
Almost all these feature runs as stateless with policies and may be entries to activate or may be tweak, but in general it will be activated by default in the future.

So :
1) it could be simple as missing code signing certificate
2) you set defender to some setting or Microsoft updated something, so out of its own shipped settings will block specific ports, and may be block specific traffic on specific ports.
3) ... i don't know how many things i can list here and all will be more guessing while logically correct for protection.

But i think if you found a specific place to exclude that binary or its directory it will work fine.

reason behind Defender going full berserk mode is the attacks is getting more dangerous, and none in the last few years was a real virus or trojan, these dangerous attack are zero-day or RCE, and guess what, there is no antivirus out there (including Windows Defender) will protect you from these, none !
these attack will break out from inside a fully trusted and signed and extensively checked applications, the only thing is left to do is to go in full protection on the slightest abnormal behavior like opening ports, or unsigned service installed to start and run with OS.... reading too much files .. a supposed visual/GUI application that doesn't create visual window, yet it tries to connect to Internet .. stuff like that.

After the discovery how Facebook and Yandex utilized open ports to deanonymize every user on Android in secret, things will get real ugly while yet there is no real vision on how to stop so many thread models, some of these are unthinkable.

[Bbommel]

Falls Kas Ob mit dem Rant doch nicht richtig liegt: damit ein Indy-Http-Server auf einem anderen Port als 443 eine SSL-Verbindung zulässt, musst du dem Ereignis "OnQuerySSLPort" eine Eventroutine zuweisen und dort dann "true" zurückgeben.

Siehe hier: https://www.indyproject.org/2018/05/...tidhttpserver/

[Supergr]

Zitat von Bbommel:

Falls Kas Ob mit dem Rant doch nicht richtig liegt: damit ein Indy-Http-Server auf einem anderen Port als 443 eine SSL-Verbindung zulässt, musst du dem Ereignis "OnQuerySSLPort" eine Eventroutine zuweisen und dort dann "true" zurückgeben.

Siehe hier: https://www.indyproject.org/2018/05/...tidhttpserver/

Super! Das war der hüpfende Punkt! Damit klappt es! Vielen Dank!