Ich richte gerade "Scan-to-Email" auf meinem Drucker ein. Aber anders, als beim Mail-Client bei WIN10, habe ich bei der Verbindungsverschlüsselung mehrere Möglichkeiten, die ich manuell einstellen muss
Was ist vorzuziehen Port 465 + SSL oder Port 587 + TLS? (für Gmail)
Jahrelang wurde StartTLS in vielen Anwendungen als Standard definiert. Das hatte unter anderem den Grund da man für verschlüsselte und unverschlüsselte Kommunikation nur ein Port benötigte. Heute geht man davon wieder weg, da StartTLS eher sicherheitsanfällig ist und die Kommunikation sowieso grundsätzlich verschlüsselt sein soll. Deswegen würde ich Port 465 statt StartTLS 587 nehmen, beides läuft mit TLS als Protokoll.
Man darf sich nicht an dem Wort SSL aufhängen, damit ist heute nicht mehr das alte Protokoll gemeint.
Jahrelang wurde StartTLS in vielen Anwendungen als Standard definiert. Das hatte unter anderem den Grund da man für verschlüsselte und unverschlüsselte Kommunikation nur ein Port benötigte. Heute geht man davon wieder weg, da StartTLS eher sicherheitsanfällig ist und die Kommunikation sowieso grundsätzlich verschlüsselt sein soll. Deswegen würde ich Port 465 statt StartTLS 587 nehmen, beides läuft mit TLS als Protokoll.
Man darf sich nicht an dem Wort SSL aufhängen, damit ist heute nicht mehr das alte Protokoll gemeint.
Eingehende Port kann ich nirgendwo eingeben. Wäre aber auch nett, wenn mir jmd nen Scan schickt, den ich als Mail bekomme oder automatisch ausgedruckt wird
Eh, es ging nie um "nur einen Port", sondern darum, daß man über StartTLS Verbindungsparameter aushandeln kann (oder wegen mir auch "konnte"). Das geht (ging) mit dem dedizierten SSL-Port nicht.
Prinzipiell ist es egal, wenn die Server ordentlich eingerichtet sind. Ich persönlich bevorzuge trotzdem StartTLS. Steinigt mich. 🤯
StartTLS hat heute keine Daseinsberechtigung mehr und stammt noch aus einer Zeit wo standardmäßig fast alles unverschlüsselt übertragen wurde. Es hat nur Nachteile und keine Vorteile.
Dem Port ist es erst mal völlig egal was für Protokoll darüber läuft. Entscheidend ist wie der Server/Dienst dahinter konfiguriert ist. Da wird schon lange kein SSL mehr verwendet. Es heißt nur noch so, da es zu dieser Zeit SSL gab. Deswegen benennt man das so langsam in den Konfigurationen um, beim Prosody XMPP Server heißt dieser Dienst jetzt nicht mehr "legacy_ssl_ports" sondern "c2s_direct_tls_ports". Bei beiden Einstellungen wird TLS verwendet und sie machen auch exakt das gleiche.
Danke erstmal für den Artikel... aber der ist von 2021, also "hat heute keine Berechtigung mehr" trifft es auch nicht so ganz
Faszinierenderweise gabs auch irgendwo einen Artikel, bei Heise bilde ich mir ein, wo genau das Gegenteil drin stand. Man möge doch auf die "gesicherten" Ports verzichten und solle StartTLS nutzen.
Die Argumentation war da halt, daß wenn man erst einmal eine Verbindung über SSL/TLS aufgebaut hat, diese auch halten muß. Egal wie sicher sie war. Und wenn es eine NULL Verschlüsselung war, die Parameter seien statisch und im Rahmen der Verbindung nicht mehr zu ändern.
Einfach die Verschlüsselungsmodalitäten komplett umgehen zu können bringt es aber natürlich auch nicht, das liegt wohl auf der Hand. 🤦♀️
Die Sicherheitsparameter fallen aber ohnehin viel zu tief unter den Tisch im Moment. Wenn man da ran will muß man im Moment noch viel zu "nerdig" sein und Standardverhalten per Auslieferung ist teilweise immer noch irgendwo zwischen RC4 und MD5.
Da ist es dann auch egal ob StartTLS oder nicht, Müll ist es in allen Fällen.
Ergänzung ()
Snoopy69 schrieb:
Aber ist zusätzliches "Serverzertifikat prüfen" nicht sicherer?
Wo um alles in der Welt ist das denn eine zusätzliche OPTION? 🤔
Ich beschreibe es mal so.
1. Du sitzt im Zug.
2. Der Schaffner kommt, "Fahrkarten bitte".
3. Du sagst "ja ich hab eine".
4. Der Schaffner antwortet "OK" und geht weiter.
Meinte damit nur das bei beiden das TLS Protokoll genutzt wird auch wenn mit SSL bezeichnet. Das was im Spoiler steht war bei "legacy_ssl_ports" auch schon so. Zwischen "legacy_ssl_ports" und "c2s_direct_tls_ports" gibt es keinen Unterschied, es wurde nur die Bezeichnung angepasst.
Bob.Dig schrieb:
Solltest Du den jetzt zufällig durch ha-proxy am laufen haben, sag doch mal Bescheid. 😉
Wo um alles in der Welt ist das denn eine zusätzliche OPTION? 🤔
Ich beschreibe es mal so.
1. Du sitzt im Zug.
2. Der Schaffner kommt, "Fahrkarten bitte".
3. Du sagst "ja ich hab eine".
4. Der Schaffner antwortet "OK" und geht weiter.
Na klar!
Aber auch das ging schon mit Prosody 0.11.x und "legacy_ssl_ports" (HAProxy Verbindungstyp TCP).
Ich breche die Verbindung auf damit der HAProxy reinschauen kann ob die Verbindungen auch wirklich was mit XMPP zu tun haben (sonst wird die gleich verworfen). Das kann man per ACL Regel und entsprechenden payload steuern. Danach werden die Daten wieder verschlüsselt und an den Prosody Server geschickt.
Faszinierenderweise gabs auch irgendwo einen Artikel, bei Heise bilde ich mir ein, wo genau das Gegenteil drin stand. Man möge doch auf die "gesicherten" Ports verzichten und solle StartTLS nutzen.
Ich hatte ja bis jetzt keinen echten Anwendungsfall bei mir für ha proxy. Nun aber wäre das offloading für prosody einer, weil ich das mal komplett neu aufsetzen will, ohne certbot etc. installieren zu müssen, weil mich das nervt und ich ungeübt darin bin.
Dann werd' ich mich mal dran machen und weiß ja, wenn ich mit ha proxy auf pfSense nerven kann.
Diesmal wirklich.
Das wird nicht gehen, den ACME Client benötigst du trotzdem. Für StartTLS ist es ja klar und Direct TLS nimmt auch keine unverschlüsselten Verbindungen entgegen. Ich glaub nur ejabberd bietet so eine Option an.
Bei mir läuft certbot auf der Sense und auf dem Prosody Server. Die werden auch von Lets Encrypt doppelt ausgestellt. Auf der Sense benötigt man das Zertifikat sowieso wenn man einen Webclient (ConverseJS) in Verbindung mit dem HAProxy laufen hat.
Bei mir läuft certbot auf der Sense und auf dem Prosody Server. Die werden auch von Lets Encrypt doppelt ausgestellt. Auf der Sense benötigt man das Zertifikat sowieso wenn man einen Webclient (ConverseJS) in Verbindung mit dem HAProxy laufen hat.
Siehste und das ist denke ich neu, dass du nun auch offloaden kannst. Jetzt muss man es nur noch einrichten. Hab auch kein Problem, wenn auf dem Server ein selbstsigniertes Zertifikat laufen würde, Hauptsache nach außen LE.
