Posteo und die RC4-Cipher

Gestern erhielt ich zum Microblog-Beitrag »Nicht ganz nachvollziehbar: BSI zertifiziert Posteo« einige E-Mails von verunsicherten Lesern. Ich möchte meine persönliche Meinung, die diesem Artikel zugrunde liegt, gerne im vorliegenden Beitrag nochmals etwas konkretisieren.

Posteo erklärt die Verwendung des RC4-Ciphers auf seiner Webseite. Es werden auch zwei RFC’s genannt:

Ausschliesslich für diese Ausnahmefälle halten unsere Empfangs- und Versandserver (MX-Server) einige veraltete Ciphern wie RC4 übergangsweise vor:
Sonst könnte mit solchen veralteten Systemen nur unverschlüsselt kommuniziert werden, was um ein Vielfaches unsicherer wäre. Diese Vorgehensweise wird im RFC 7435 und im RFC 7525 der Internet Engineering Task Force (IETF) genauso empfohlen.

Jetzt öffnen wir mal den RFC 7525 und finden dort folgende Passage:

Implementations MUST NOT [dürfen nicht!] negotiate RC4 cipher suites.

Rationale: The RC4 stream cipher has a variety of cryptographic weaknesses, as documented in [RFC7465]. Note that DTLS specifically forbids the use of RC4 already.

Im gleichen RFC steht unter »Opportunistic Security« aber auch Folgendes:

There are several important scenarios in which the use of TLS is optional, i.e., the client decides dynamically („opportunistically“) whether to use TLS with a particular server or to connect in the clear. This practice, often called „opportunistic security“, is described at length in [RFC7435] and is often motivated by a desire for backward compatibility with legacy deployments.

In these scenarios, some of the recommendations in this document might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome than using TLS with an outdated protocol version or cipher suite.

Das erklärt nun zumindest die Verwendung von RC4 bei Posteo für die E-Mail-Server-zu-E-Mail-Server-Kommunikation mit schlecht gewarteten oder veralteten E-Mail Servern. Für eine Client-zu-Server-Kommunikation (bspw. beim Aufruf eurer E-Mails) verzichtet Posteo hingegen auf RC4. Und dennoch: Es ist kein Geheimnis, dass RC4 und auch MD5 bereits veraltet und unsicher sind. Mehr als eine »Scheinsicherheit« bietet RC4 nach meiner Auffassung nicht. Man muss sich daher die Frage stellen: Will ich wirklich eine Abwärtskompatibilität zu E-Mail-Servern gewährleisten, deren Administratoren offenbar im Tiefschlaf sind oder an einer sicheren E-Mail-Übermittlung gar kein Interesse haben? Wenn ein E-Mail-Server als »beste« Verschlüsselungsvariante Cipher-Suiten mit RC4 und MD5 anbietet, dann ist das nach meiner Ansicht nicht mehr zeitgemäß und dürfte auch nicht dem anerkannten Stand der Technik entsprechen. Mitbewerber wie bspw. mailbox.org verzichtet auf die Verwendung der als unsicher geltenden RC4-Cipher-Suite – was ich persönlich, für konsequent und richtig halte. Und das BSI sollte sich meiner Ansicht nach auch fragen, ob sie das Zertifikat »Sicherer E-Mail-Transport« tatsächlich vergeben sollten, wenn ein Anbieter noch RC4 einsetzt. Nach meiner Auffassung wäre es vielmehr wünschenswert, wenn sich das BSI in diesem Zusammenhang deutlicher zur Verwendung von RC4 bzw. veralteten Cipher-Suiten äußern bzw. positionieren würde.

Noch ein Hinweis: Das Privacy-Handbuch dokumentiert schon seit über einem halben Jahr diverse TLS-Konfigurationen von Posteo und bemängelt ähnliche Punkte.

Achtung: Das Privacy-Handbuch verfügt über kein Impressum. Ob es dieses aufgrund der nicht erkennbaren »Geschäftsmäßigkeit« des Services überhaupt braucht, will ich jetzt mal dahingestellt lassen (Vgl. § 5 TMG). (Information auf den Rat meines Anwalts Gerald Spyra hinzugefügt)

Hilf mit die Spendenziele zu erreichen! Mitmachen ➡