Hallo. Am 18.04.2016 um 19:07 schrieb Paul Hänsch: > - SSL ist keine Email-Verschlüsselung! > - Auch nicht ein ganz kleines bisschen > - Auch nicht "besser als gar nichts", die Mailserver in der > Kette sind die hauptsächlichen Angriffspunkte, und gerade > diese werden nicht abgedeckt > - Irgendwo in der Kette irgendwie was mit Verschlüsselung zu haben > ist weit entfernt von sicherer Kommunikation
Transportverschlüsselung ist keine Content-Verschlüsselung, soweit klar. Aber wenn du schon auf Überwachung durch übermächtige Dritte annimmst, dann mach dir klar wo diese Überwachung stattfindet. Wenn ich von meinem Server an dich auf dem FSFE-Server zustelle, dann geht diese Information, dass *ich* für *dich* eine Mail habe, nur unsere beiden Mailserver etwas an. Wer im DeCIX lauscht, der braucht das nicht zu erfahren. Da ist schon genug der Information, dass mein Server für deinen Server eine oder mehrere Mails hat. Dass der übermächtige Gegner meinen Server kompromittiert ist nicht ganz wahrscheinlich und dass dieser den FSFE-Server kompromittiert ist auch eher unwahrscheinlich. Also hilft Transportverschlüsselung eben grade für diesen Fall wirklich, weil man die realistischen Angriffsvektoren ausschaltet. Nicht um besonders geheime Daten zu schützen sondern um Privatsphäre zu erzeugen. Klar dass ich meinem Admin vertrauen muss und auch klar, dass ich dem Admin des Gegenüber vertrauen muss. Deshalb versende ich auch so ungern an Gmx- und Gmail-User. Aber im "normalen" Umfeld der Kommunikation zwischen vergleichsweise kleineren Providern und self-hosted-Services, da ist TLS genau das was wir brauchen. Und es wird auch wirklich von anderen Mailservern benutzt, ganz ehrlich. > - *Falls* du den Server zur Submission verwenden willst, gibt es dennoch > Authentifizierungsverfahren die das Auslesen von Passwörtern auf > Plaintext-Kanälen verhindern (z.B. CRAM) Wo da jetzt der Vorteil sein soll, erschließt sich mir ganz und gar nicht. Viele Implementierungen brauchen für CRAM das Passwort im Plaintext in der Datenbank. Das ist dann wirklich zu viel verlangt an Vertrauen in den Server-Admin. > Um nochmal zum Anfang zurückzukommen: SSL wurde entworfen und ist > geeignet um Kleinkriminelle davon abzuhalten, deine Kreditkartennummer > von der Leitung zu sniffen. In dem Bereich ist es vollkommen richtig > platziert. Spätestend mit den Five-Eyes-Leaks sollte sich unser > Verständnis von Computersicherheit aber dahingehend gewandelt haben, > dass wir eine andere Größenordnung von Gegener annehmen müssen. > Ausgerechnet SSL stellt in diesem Fall keinen Gewinn da. "Die Kosten der > Überwachung" deckst du dann beim Erwerb deines Zertifikates gleich mit > ab. Was steigt sind vor allem deine eigenen Kosten. Ein TLS-Zertifikat kostet schon lange nichts mehr. Es war bisher noch mit jährlicher Überwindung für das Javascript-lastige StartSSL-Webinterface verbunden, seit Dezember 2015 ist das aber vorbei. Kosten für TLS sind für einfache Websites nicht mehr vorhanden. > SSL ist eine schlechte Ausrede um sich mit PGP nicht auseinandersetzen > zu müssen. PGP schützt sensible Inhalte aber nicht die Privatsphäre. > Admins jetzt dazu zu nötigen irgendwelche Profaninhalte > hinter SSL-Seiten zu stellen ist Ressourcenverschwendung. Das trainiert > Internetnutzer dazu Warnungen weg zu klicken Welche Warnungen und welche Ressourcen? Kann es sein, dass du noch im TLS von vor 10 Jahren festhängst? HTTP/2 ist TLS-only und mit Verschlüsselung immer noch effizienter als HTTP/1.1 plain. Zitate passend zu deinem FUD: | "On our production frontend machines, SSL/TLS accounts for less than | 1% of the CPU load, less than 10 KB of memory per connection and less | than 2% of network overhead. Many people believe that SSL/TLS takes a | lot of CPU time and we hope the preceding numbers will help to dispel | that." - Adam Langley, Google | "We have deployed TLS at a large scale using both hardware and | software load balancers. We have found that modern software-based TLS | implementations running on commodity CPUs are fast enough to handle | heavy HTTPS traffic load without needing to resort to dedicated | cryptographic hardware." - Doug Beaver, Facebook Zudem bewertet Google Seiten besser, wenn sie mit TLS ausgeliefert werden. (https://security.googleblog.com/2014/08/https-as-ranking-signal_6.html) In ein paar Jahren werden fast alle Transportkanäle im Internet verschlüsselt ablaufen, Gründe dafür gibt es genug, dagegen mittlerweile keine mehr. Gruß, Bernd
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fsfe-de mailing list fsfe-de@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/fsfe-de