Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › MTA-STS: Neuer Standard sichert…

Gehts nur mir so...

  1. Thema

Neues Thema Ansicht wechseln


  1. Gehts nur mir so...

    Autor: ITsMe 28.09.18 - 13:53

    ... oder ist dieser Standard komplett realitätsfern und löst das problem genauso wenig wie DANE noch einen Schritt komplizierter?

    Irgendwie hab ich das Gefühl das http und in folge https so ein hipes Protokoll ist und deswegen versucht wird jedes Problem damit zu lösen.

    DoH kann ich noch irgendwie nachvollziehen weil es genügend unfähige oder paranoide Systemadmins gibt die entweder zufaul sind ihre Firewallregeln der Realität anzupassen und alles sperren und kein DNS durch lassen.

    Aber warum sollte man diese Abfrage über https machen wenn das gleiche schon alles im DNS Eintrag stehen könnte, genauer gesagt es steht schon alles drinnen außer type=enforce. Alles andere steht im TXT record inkl. expire Zeitpunkt.

    Gut dann kommt die argumentation der DNS Eintrag könnte manipuliert werden weil die Admins nicht in der Lage sind DNSSEC einzurichten (wobei hier das größte Problem die selbst organisation ist). Aber ja könnte ich noch verstehen aber warum sollte das bei dem MTA-STS Standard anders sein?
    Diese benötigt (außer ich hab was im Artikel übersehen) genauso einen DNS Eintrag der manipuliert sein könnte. Eigentlich noch besser er benötigt sogar 2, weil den mta-sts subdomain benötigt er auch noch. Auf deutsch 2 DNS abfragen die beide unterdrückt werden könnten ohne DNSSEC. Also genau kein Gewinn gegen über DANE.

    Dann kommen wir zum nächsten Angriffspunkt. Den Webserver, der muss wohl mit https ausgestattet sein, aber ist er deswegen sicher? Bei unserem glück werden Mailserver implementiert die nur TLS 1.0 unterstützen und du den Webserver nie wieder auf eine zum Zeitpunkt X sichere Verschlüsselung umstellen kannst weil sonst keine mails mehr ankommen.

    Sorry aber der Standard ist in meinen Augen vollkommen sinnlos ohne DNSSEC genauso wie DANE nur das er tolles http verwendet.

  2. Re: Gehts nur mir so...

    Autor: RipClaw 28.09.18 - 14:37

    ITsMe schrieb:
    --------------------------------------------------------------------------------
    > ... oder ist dieser Standard komplett realitätsfern und löst das problem
    > genauso wenig wie DANE noch einen Schritt komplizierter?

    Vermutlich wollten sie die DNS Einstellungen nicht so kompliziert gestalten aber mit der Policy Datei genug Spielraum für eine umfangreiche Konfiguration lassen.

    Generell nervt es mich aber auch das man jetzt als Admin die Firewall von einem Mailserver so weit öffnen muss der er HTTP und HTTPS Verbindungen erlaubt.

    Und ich sehe auch ein Potential für Angriffe da die Datei vom Webserver durch einen Parser durch muss. Bin gespannt wie sie das Problem angehen. Vor allem bei Mailservern wie exim, bei denen alles unter einem Prozess läuft, ist die Angriffsfläche unter Umständen recht groß.



    1 mal bearbeitet, zuletzt am 28.09.18 14:38 durch RipClaw.

  3. Re: Gehts nur mir so...

    Autor: OlafLostViking 28.09.18 - 14:58

    Nein, ich schließe mich da an. Es ist eine Unart alles auf HTTP zu legen.

    Ich bin eigentlich ein großer Fan von Systemdaten im DNS - auch und vor allem alles, was mit Sicherheit zu tun hat. Selbst auf CAs könnte man dann bei DV Zeritifkaten problemlos verzichten.

    Das Problem, das viele mit DNSSEC haben, kann ich (leider?) nicht ganz nachvollziehen. Bei mir läuft es wunderbar und ohne großen Aufwand. Richtig, es ist kaum verbreitet, aber das ist ein menschliches Problem, welches auch mit diesem Ansatz nicht gelöst wird (eher noch verschärft).

    @RipClaw: Der Webserver muss ja nicht die gleiche Maschine sein, wie der Mailserver. Aber klar, jetzt muss ich nicht nur den Mailserver und den DNS-Server (die ich beide ja sowieso habe), sondern auch noch einen Webserver betreiben und absichern.



    1 mal bearbeitet, zuletzt am 28.09.18 14:59 durch OlafLostViking.

  4. Re: Gehts nur mir so...

    Autor: Gonzales 28.09.18 - 15:15

    OlafLostViking schrieb:
    --------------------------------------------------------------------------------
    > Nein, ich schließe mich da an. Es ist eine Unart alles auf HTTP zu legen.

    +1

    > Ich bin eigentlich ein großer Fan von Systemdaten im DNS - auch und vor
    > allem alles, was mit Sicherheit zu tun hat. Selbst auf CAs könnte man dann
    > bei DV Zeritifkaten problemlos verzichten.

    +1

    > Das Problem, das viele mit DNSSEC haben, kann ich (leider?) nicht ganz
    > nachvollziehen.

    +1

    > @RipClaw: Der Webserver muss ja nicht die gleiche Maschine sein, wie der
    > Mailserver. Aber klar, jetzt muss ich nicht nur den Mailserver und den
    > DNS-Server (die ich beide ja sowieso habe), sondern auch noch einen
    > Webserver betreiben und absichern.

    Ich glaub, @RipClaw ging's darum, daß der Mailserver zur Überprüfung der Policy des Empfängers eine ausgehende http(s)-Verbindung aufbauen muß.

  5. Re: Gehts nur mir so...

    Autor: RipClaw 28.09.18 - 15:20

    Gonzales schrieb:
    --------------------------------------------------------------------------------

    > Ich glaub, @RipClaw ging's darum, daß der Mailserver zur Überprüfung der
    > Policy des Empfängers eine ausgehende http(s)-Verbindung aufbauen muß.

    Ja das meinte ich.

  6. Re: Gehts nur mir so...

    Autor: OlafLostViking 28.09.18 - 16:05

    RipClaw schrieb:
    --------------------------------------------------------------------------------
    > Ja das meinte ich.

    Ah, das verstand ich falsch - zu schnell gelesen oder zu viel aufgeregt ;-). Vielen Dank an @Gonzales für's Klarstellen.

    Ja, da gebe ich @RipClaw völlig recht. Meine Firewallregeln sind recht streng, so dass nur bestimmte userids je nach ihrer Aufgabe zu ganz bestimmten IP/Port-Kombinationen Verbindung aufnehmen dürfen. Dieser neue Ansatz erfordert den Mailserver-Benutzer (jetzt verstehe ich auch, was Du mit dem Exim-Beispiel sagen wolltest) nicht nur auf alle Port 25, sondern auch noch alle Port 443 rauslassen muss. Das schreit nach völlig unnötigen Sicherheitsproblemen (gerade bei einem Server, dessen Hauptaufgabe ist Daten, die ihm aus dem bösen, weiten Netz geschickt werden, zu parsen, scannen, analysieren, ...).

  7. Re: Gehts nur mir so...

    Autor: tsp 30.09.18 - 08:25

    Muss mich hier ebenfalls absolut anschließen, finde es auch ungut alles mit HTTP(S) lösen zu wollen - die nötigen Informationen kann man bereits jetzt im DNS unterbringen was an sich nicht schwierig ist, robust und solide funktioniert und mit Hilfe von DNSSEC auch ordentlich absicherbar ist - und DNS bietet da meiner Meinung nach gegenüber einem Webserver gleich mehrere Vorteile und ist schlichtweg simpler. Einen Mailserver der via HTTP(S) kommunizieren möchte hätte ich nur sehr ungern in meinem Netzwerk.

    Ich denke diesen Trend alles via HTTP zusammenbasteln zu wollen gibt's in dem Bereich deshalb, weil es einen Haufen an "billigen" Registraren für Domains gibt die zugleich den Betrieb der Zone übernehmen die wiederum keine API für Änderungen an der Zone unterstützen oder z.B. nur A/AAAA/MX und CNAME Records über ihre Interfaces unterstützen - da sehe ich das Problem allerdings nicht bei DNS sondern bei diesen Betreibern.

    Und selbst wenn es ein Problem mit der Transportverschlüsselung von E-Mails gäbe gibt's meiner Meinung nach noch immer funktionierende sichere End-to-end Verfahren für E-Mails (OpenPGP oder S/MIME wobei ich persönlich erstere bevorzuge) um die Inhalte zu sichern - da kann dann der Transport meiner Meinung nach gerne unsicher sein (ja ich weiß - Metadaten werden dadurch nicht geschützt)

  8. Re: Gehts nur mir so...

    Autor: ikhaya 30.09.18 - 09:47

    Ob man nun HTTPS über Port 443 spricht oder 1023, ob es Submission oder SMTP über Port 443 oder 999 ist, macht das einen Unterschied? Verschlüsselt und uneinsehbar sind beide.

    Es gibt hier kein Entweder Transportverschlüsselung Oder Ende-zu-Ende Verschlüsselung des Inhalts.

    Beide müssen zusammen eingesetzt werden damit sowohl der Inhalt der E-Mail als auch die Metadaten soweit wie möglich geschützt werden.

  9. Re: Gehts nur mir so...

    Autor: tsp 30.09.18 - 14:00

    ikhaya schrieb:
    --------------------------------------------------------------------------------
    > Ob man nun HTTPS über Port 443 spricht oder 1023, ob es Submission oder
    > SMTP über Port 443 oder 999 ist, macht das einen Unterschied? Verschlüsselt
    > und uneinsehbar sind beide.

    Es macht in so fern einen Unterschied, als Mailserver ja bereits SMTP (optional über TLS) und DNS sprechen. Jetzt soll noch ein weiteres Protokoll (HTTP) mit zugehörigem Parser und ein Parser für Policy Dateien dazu kommen. Das fügt schon einiges an unnötiger Komplexität hinzu, vor Allem da die bestehenden Protokolle ja bereits die nötigen Informationen liefern können (eben z.B. DNS - mit DNSSEC auch entsprechend abgesichert wobei die Verifikation von DNSSEC Signaturen dann auch noch in den DNS Resolver oder Client ausgelagert wird und die Komplexität des Mailclients nicht erhöht).

  10. Re: Gehts nur mir so...

    Autor: ikhaya 30.09.18 - 17:51

    Auch DANE braucht Code im Mailserver oder im Client oder im Browser der die Records auswertet.

  11. Re: Gehts nur mir so...

    Autor: tsp 01.10.18 - 12:11

    Der ist allerdings signifikant simpler als ein kompletter HTTP Stack (+ Parser für das "neue" Policy Format) ...

  12. Re: Gehts nur mir so...

    Autor: Niels_Dettenbach 06.02.19 - 08:26

    Das ist nicht ganz falsch. Phil von Exim.org hat gestern auf der exim mailing liste recht gut dargelegt, warum STS keine pauschale Lösung ist.

    Das Problem ist auch nicht HTTPS sondern die Strategie / Struktur von x509 - genauer: dem zentralistischen Ansatz der "SSL" CAs / Vertrauensstellungen. Nur weil sehr viele Anwender heute glauben, eine Verbindung ihres Browsers sei "sicher" (vertrauenswürdig), nur weil "das Schloß zu" oder "Browserzeile grün" ist. Tatsächlich lässt sich heute in den AGBs fast jeder Bank zum Online Banking nachlesen, warum das nicht so ist. Es waren und sind CAs und Browserhersteller (siehe Browser Alliance u.ä.) die von dieser Fehlinformation profitierten, was auch nahelegt, woher diese Story stammt. Es gibt sogar Produkte, die die Aushebelung von SSL als MitM mit Hilfe dieses verbreiteten Fehlwissens realisieren.

    Es gibt eben kein "ist sicher bzw. nicht sicher" im Kontext von "vertrauenswürdig oder nicht", sondern immer nur bedingte, abgestufte Varianten davon. Diese aber bilden weder die meisten Anwender ab - noch könnte dies ein Mailprovider pauschal übernehmen.

  13. Re: Gehts nur mir so...

    Autor: ikhaya 06.02.19 - 13:12

    Es geht immer darum die Latte so hoch wie möglich zu legen. Wenn etwas sicherer ist als vorher ist auch etwas gewonnen um die Masse der Leute zu schützen.

    Hast du nen Link zu dem Beitrag da?

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. CBM Christoffel-Blindenmission Deutschland e.V., Bensheim
  2. Arburg GmbH & Co. KG, Loßburg
  3. Dataport, verschiedene Einsatzorte (Home-Office möglich)
  4. Ecologic Institut gemeinnützige GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Aorus Pro für 219,90€, Aorus Pro WiFi für 229,90€, Aorus Elite für 189,90€)
  2. (u. a. beide Spiele zu Ryzen 9 3000 oder 7 3800X Series, eines davon zu Ryzen 7 3700X/5 3600X/7...
  3. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Jira, Trello, Asana, Zendesk: Welches Teamarbeitstool taugt wofür?
Jira, Trello, Asana, Zendesk
Welches Teamarbeitstool taugt wofür?

Die gute Organisation eines Teams ist das A und O in der Projektplanung. Tools wie Jira, Trello, Asana und Zendesk versuchen, das Werkzeug der Wahl zu sein. Wir machen den Vergleich und zeigen, wo ihre Stärken und Schwächen liegen und wie sie Firmen helfen, die DSGVO-Konformität zu wahren.
Von Sascha Lewandowski

  1. Anzeige Wie ALDI SÜD seine IT personell neu aufstellt
  2. Projektmanagement An der falschen Stelle automatisiert

Star Wars Jedi Fallen Order: Mächtige und nicht so mächtige Besonderheiten
Star Wars Jedi Fallen Order
Mächtige und nicht so mächtige Besonderheiten

Ein Roboter mit Schublade im Kopf, das Lichtschwert als Multifunktionswerkzeug und ein sehr spezielles System zum Wiederbeleben: Golem.de stellt zehn ungewöhnliche Elemente von Star Wars Jedi Fallen Order vor.


    Rabbids Coding angespielt: Hasenprogrammierung für Einsteiger
    Rabbids Coding angespielt
    Hasenprogrammierung für Einsteiger

    Erst ein paar einfache Anweisungen, dann folgen Optimierungen: Mit dem kostenlos erhältlichen PC-Lernspiel Rabbids Coding von Ubisoft können Jugendliche und Erwachsene ein bisschen über Programmierung lernen und viel Spaß haben.
    Von Peter Steinlechner

    1. Transport Fever 2 angespielt Wachstum ist doch nicht alles
    2. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
    3. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle

    1. Kongress-Anhörung: Zuckerberg will Zustimmung der USA zu Libra abwarten
      Kongress-Anhörung
      Zuckerberg will Zustimmung der USA zu Libra abwarten

      Mark Zuckerberg muss den US-Abgeordneten Rede und Antwort zur Digitalwährung Libra stehen. Der Facebook-Chef warnt vor einem Bedeutungsverlust der US-Finanzwirtschaft bei einer Blockade des Projekts.

    2. Mikrowellen: Verizons 5G Netz kann kein Stadion ausleuchten
      Mikrowellen
      Verizons 5G Netz kann kein Stadion ausleuchten

      Verizon kündigt sein 5G Ultra Wideband für Stadien an. Doch nur ein Teil der Besucher kann das Netz auch nutzen, da der Betreiber ein Problem mit der Ausleuchtung hat.

    3. Bayern: Fernsehen über 5G funktioniert gut
      Bayern
      Fernsehen über 5G funktioniert gut

      Der Testlauf zur TV-Verbreitung über 5G war erfolgreich und geht wohl sogar nach dem offiziellen Ende weiter. Der mobile TV-Empfang war gut. Erreicht wurden eine hohe Videoqualität, niedrige Latenzzeiten und eine hohe Abdeckung.


    1. 19:16

    2. 19:01

    3. 17:59

    4. 17:45

    5. 17:20

    6. 16:55

    7. 16:10

    8. 15:15