Verständnis TLS sowie SMINE
Hallo zusammen,
wir überlegen das wir unsere Emails per S/MINE verschlüsseln da wir oft personenbezogene Daten per Mail verschicken sowie empfangen.
Jetzt hat ein Systemhaus mir mitgeteilt das man S/MINE gar nicht braucht weil TLS 1.2 auch schon ausreicht, stimmt das so? Ich habe gedacht das bei TLS nur der weg verschlüsselt wird, jedoch nicht selbst die Email.
Ich will mich hier auf jeden Fall absichern, muss es nicht unbedingt haben das ich mal irgendwann ein Brief vom Anwalt bekomme weil wir personenbezogene Daten "unverschlüsselt" verschicken.
Vielen Dank für eure Hilfe.
wir überlegen das wir unsere Emails per S/MINE verschlüsseln da wir oft personenbezogene Daten per Mail verschicken sowie empfangen.
Jetzt hat ein Systemhaus mir mitgeteilt das man S/MINE gar nicht braucht weil TLS 1.2 auch schon ausreicht, stimmt das so? Ich habe gedacht das bei TLS nur der weg verschlüsselt wird, jedoch nicht selbst die Email.
Ich will mich hier auf jeden Fall absichern, muss es nicht unbedingt haben das ich mal irgendwann ein Brief vom Anwalt bekomme weil wir personenbezogene Daten "unverschlüsselt" verschicken.
Vielen Dank für eure Hilfe.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 374032
Url: https://administrator.de/forum/verstaendnis-tls-sowie-smine-374032.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
14 Kommentare
Neuester Kommentar
@Voiper hat Recht
Und das sollte man dringenst noch zu dem Thema lesen:
Experten raten vorerst von E-Mail-Verschlüsselung ab
EFail Lücke war seit November bekannt - Veröffentlichung war unüberlegt
S/MIME ist davon sogar noch stärker betroffen als PGP was S/MIME quasi unbrauchbar macht !!
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Experten raten vorerst von E-Mail-Verschlüsselung ab
EFail Lücke war seit November bekannt - Veröffentlichung war unüberlegt
S/MIME ist davon sogar noch stärker betroffen als PGP was S/MIME quasi unbrauchbar macht !!
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Beide Angriffe funktionieren aber nur, wenn der Mailclient nicht nur automatisch entschlüsselt sondern auch noch ungefragt externe Ressourcen aus E-Mails nachlädt.
Letzteres ist seit spätestens den letzten 15 Jahren in allen mir bekannten Mailclients standardmäßig abgeschaltet.
Wer das demnach absichtlich wieder einschaltet hat es nicht besser verdient.
Bei Kryptografie gilt zudem sowieso, dass das beste System nichts taugt, wenn nicht alle beteiligten mit Sinn und Verstand arbeiten...
Letzteres ist seit spätestens den letzten 15 Jahren in allen mir bekannten Mailclients standardmäßig abgeschaltet.
Wer das demnach absichtlich wieder einschaltet hat es nicht besser verdient.
Bei Kryptografie gilt zudem sowieso, dass das beste System nichts taugt, wenn nicht alle beteiligten mit Sinn und Verstand arbeiten...
Also TLS kannst du natürlich machen und wenn z.B. dein E-Mail Server die Mail direkt dem Mail Server des Empfängers zustellt wäre die Übermittlung auch sicher. Da du aber i.d.R. die E-Mail an einen Mailserver deines Anbieters weiter reichst und den Empfänger Mailserver gar nicht kennst kannst du nicht mit Sicherheit sagen wo diese Email wie übermittelt wird.
Was SMIME angeht so fand ich den Artikel auf Golem doch irgendwie besser:
https://www.golem.de/news/pgp-smime-angreifer-koennen-sich-entschluessel ...
Grundsätzlich bin ich skeptisch von SMIME abzuraten ohne eine ernstzunehmende Alternative anbieten zu können. Die Antwort kann nur sein einen sicheren Mailclient einzusetzen und auf eine Verbesserung des Standards oder einen besseren Standard zu warten aber eben nicht einfach zu verzichten.
Was SMIME angeht so fand ich den Artikel auf Golem doch irgendwie besser:
https://www.golem.de/news/pgp-smime-angreifer-koennen-sich-entschluessel ...
Grundsätzlich bin ich skeptisch von SMIME abzuraten ohne eine ernstzunehmende Alternative anbieten zu können. Die Antwort kann nur sein einen sicheren Mailclient einzusetzen und auf eine Verbesserung des Standards oder einen besseren Standard zu warten aber eben nicht einfach zu verzichten.
Zitat von @ukulele-7:
Die Antwort kann nur sein einen sicheren Mailclient einzusetzen und auf eine Verbesserung des Standards oder einen besseren Standard zu warten aber eben nicht einfach zu verzichten.
Dazu passend - vor allem weil hier schon heise verlinkt wurde - ein weiterer heise-Link: https://www.heise.de/newsticker/meldung/Kommentar-Efail-ist-ein-EFFail-4 ...Die Antwort kann nur sein einen sicheren Mailclient einzusetzen und auf eine Verbesserung des Standards oder einen besseren Standard zu warten aber eben nicht einfach zu verzichten.
Zitat von @ukulele-7:
Grundsätzlich bin ich skeptisch von SMIME abzuraten ohne eine ernstzunehmende Alternative anbieten zu können.
Grundsätzlich bin ich skeptisch von SMIME abzuraten ohne eine ernstzunehmende Alternative anbieten zu können.
Da stimme ich zu und finde es persönlich höchst fahrlässig und auch unqualifiziert. Das ist wie den Airbag zu deaktivieren, weil er in manchen Fällen nicht richtig funktioniert. Ja, wenn das so ist, dann schalte ich das Ding eben ganz ab...
Hinzu kommt, dass es mittlerweile genug Gateways auf dem Markt gibt, die das ver- und entschlüsseln für den Client zentral übernehmen. Aber jetzt kommen sicher die Spezialisten und sagen: "Dann ist es aber keine echte Ende-zu-Ende Verschlüsselung mehr!"...moment ich such fix meinen Aluhut.
Hi,
Wer nur eine Sekunde länger nachdenkt, kommt sicher auch zu dem Schluss, dass es beim Verschlüsseln von Mails primär darauf ankommt, dass nur der vorgesehene Empfänger, bzw. derjenige, welcher den Schlüssel hat, die Mail lesen kann. Dazu gehören dann auch solche Szenarien, wenn Stellvertreter oder Einbrecher auf ein Postfach zugreifen und dann eben nicht in der Lage sein sollen, für den Postfachinhaber verschlüsselte Mails lesen zu können, es sei denn, sie haben den Schlüssel. Die Transportverschlüsselung leistet genau das aber nicht. Sie kann maximal sicherstellen, dass die Mail unverfälscht ankommt bzw. dass Dritte gar nicht mitbekommen, dass eine Mail an einen bestimmten Empfänger unterwegs ist. Insofern ist die Gegenüberstellung von TLS und S/MIME vollkommen fehl am Platz. Das Postfach ist das Bankschließfach. TLS ist der gepanzerte Transporter. Und S/MIME ist der verschlüsselte Brief, welcher im Bankschließfach abgeliefert und gelagert wird.
E.
moment ich such fix meinen Aluhut.
Das hat damit eigentlich überhaupt nichts zu tun, aber auch rein gar nichts!Wer nur eine Sekunde länger nachdenkt, kommt sicher auch zu dem Schluss, dass es beim Verschlüsseln von Mails primär darauf ankommt, dass nur der vorgesehene Empfänger, bzw. derjenige, welcher den Schlüssel hat, die Mail lesen kann. Dazu gehören dann auch solche Szenarien, wenn Stellvertreter oder Einbrecher auf ein Postfach zugreifen und dann eben nicht in der Lage sein sollen, für den Postfachinhaber verschlüsselte Mails lesen zu können, es sei denn, sie haben den Schlüssel. Die Transportverschlüsselung leistet genau das aber nicht. Sie kann maximal sicherstellen, dass die Mail unverfälscht ankommt bzw. dass Dritte gar nicht mitbekommen, dass eine Mail an einen bestimmten Empfänger unterwegs ist. Insofern ist die Gegenüberstellung von TLS und S/MIME vollkommen fehl am Platz. Das Postfach ist das Bankschließfach. TLS ist der gepanzerte Transporter. Und S/MIME ist der verschlüsselte Brief, welcher im Bankschließfach abgeliefert und gelagert wird.
E.
Zitat von @emeriks:
Das hat damit eigentlich überhaupt nichts zu tun, aber auch rein gar nichts!
Wer nur eine Sekunde länger nachdenkt...
Das hat damit eigentlich überhaupt nichts zu tun, aber auch rein gar nichts!
Wer nur eine Sekunde länger nachdenkt...
Bitte vielleicht meinen Post für ein bis zwei Sekunden länger lesen...
Die Transportverschlüsselung leistet genau das aber nicht.
Ich denke du hast meine Aussage missverstanden. Es ging in meinem Post nicht um dieTransportverschlüsselung, sondern um ein Verschlüsselungs-Gateway welches die ver- und entschlüsselung via S/MIME oder PGP für den Client übernimmt (z.B. NoSpamProxy). Und da das ganze eben nicht im Mailclient vorgenommen wird, haben wir zum einen keine "echte" Ende-zu-Ende Verschlüsselung und zum anderen trifft efail in so einem Fall nicht zu.
Also mein Aluhut ging an die Personen, welches das oben beschriebene nicht als "echte" Ende-zu-Ende Verschlüsselung bezeichnen. Kann aber jeder halten wie er möchte... Fakt ist aber, nicht zu verschlüsseln ist wohl keine Alternative
Gruss,
Java
Zitat von @java667:
Also mein Aluhut ging an die Personen, welches das oben beschriebene nicht als "echte" Ende-zu-Ende Verschlüsselung bezeichnen.
Also mein Aluhut ging an die Personen, welches das oben beschriebene nicht als "echte" Ende-zu-Ende Verschlüsselung bezeichnen.
Hier liegt der Hase begraben...Niemand hat das behauptet ;)
Na dann denke ich, dass ich Dich richtig verstanden hatte.
Das mit dem "Aluhut" ist m.E. eine Verharmlosung eines ernsten Themas. Der TO schreibt von personenbezogenen Daten!
Diese Verschlüsselung über solche Gateways kenne ich. Allerdings auch nur als Sender-Gateway. Denn auch hier findet doch die Entschlüsselung erst beim Empfänger (Mailclient) statt? Wenn es da auch Empfänger-Gateways gibt, welche die Mails entschlüsseln und dann intern unverschlüsselt weiterleiten, dann ist das m.E. eine Verarschung des Senders, wenn dieser nicht explizit darüber in Kenntnis gesetzt wird, dass die Mail unverschlüsselt beim Empfänger ankommt.
Das mit dem "Aluhut" ist m.E. eine Verharmlosung eines ernsten Themas. Der TO schreibt von personenbezogenen Daten!
Diese Verschlüsselung über solche Gateways kenne ich. Allerdings auch nur als Sender-Gateway. Denn auch hier findet doch die Entschlüsselung erst beim Empfänger (Mailclient) statt? Wenn es da auch Empfänger-Gateways gibt, welche die Mails entschlüsseln und dann intern unverschlüsselt weiterleiten, dann ist das m.E. eine Verarschung des Senders, wenn dieser nicht explizit darüber in Kenntnis gesetzt wird, dass die Mail unverschlüsselt beim Empfänger ankommt.
Bei SMIME per Gateway ist das durchaus so das das Gateway die Entschlüsselung übernimmt. Bei uns ist das auch so gewollt denn SMIME soll tatsächlich nur den Transport absichern und nicht wie bei TLS bis zum Mailserver sondern darüber hinaus bis zum Netzwerk des Empfängers. Das geht halt mit TLS nicht wenn dazwischen "unbekannte" Server liegen.
Natürlich ist die E-Mail dann im Sende und im Empfänger Netz unverschlüsselt. Diesen kann man aber vielleicht mehr vertrauen. Wenn der Empfänger seinem Mail Admin nicht traut oder den Inhalt in seinem Archiv verschlüsselt liegen haben will würde ich eher zur PDF greifen. Wir möchten es aber definitiv unverschlüsselt auf dem Mailserver haben. Der Zugriff auf Fremede Postfächer ist dabei natürlich klar geregelt.
Ich würde aber nicht sagen das das aktuelle Angriffsszenario hier nicht greift. Das Gateway kann ja den Inhalt entschlüsseln und der Mailclient hat dann den entschlüsselten Inhalt, eingebettet in einen Link und kann diesen immernoch weiter leiten. Ich würde also nicht sagen das ein Gateway hier die Sicherheit erhöht.
Natürlich ist die E-Mail dann im Sende und im Empfänger Netz unverschlüsselt. Diesen kann man aber vielleicht mehr vertrauen. Wenn der Empfänger seinem Mail Admin nicht traut oder den Inhalt in seinem Archiv verschlüsselt liegen haben will würde ich eher zur PDF greifen. Wir möchten es aber definitiv unverschlüsselt auf dem Mailserver haben. Der Zugriff auf Fremede Postfächer ist dabei natürlich klar geregelt.
Ich würde aber nicht sagen das das aktuelle Angriffsszenario hier nicht greift. Das Gateway kann ja den Inhalt entschlüsseln und der Mailclient hat dann den entschlüsselten Inhalt, eingebettet in einen Link und kann diesen immernoch weiter leiten. Ich würde also nicht sagen das ein Gateway hier die Sicherheit erhöht.