TLS [was: Mailinglistenalternative zu Googlegroups]

[Bernd Wurst]

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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 836 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20160418/92179c44/attachment.sig>