• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[Technik] TLS 1.3 offizieller IETF-Standard

security-2168233_960_720.jpg

Die IETF (Internet Engineering Task Force) hat TLS 1.3 als RFC (Request for Change) 8446 (https://tools.ietf.org/html/rfc8446) offiziell standardisiert.

Wer sich noch nicht mit der IETF beschäftigt hat: die Standardisierung dauert normalerweise immer etwas, es gibt mehrere Drafts, die iterativ verbessert werden, bis dann ein Standard daraus wird - oder der Draft ausläuft und nicht erneuert wird. Bei den IETF-Meetings, in den Working Groups und Mailinglisten beteiligen sich verschiedene Forscher und Firmen, wodurch es auch Interessenskonflikte geben kann.

Dies war bei TLS 1.3 der Fall. Verschiedene Unternehmen versuchten aktiv den Standard zu schwächen, was die Standardisierung verzögerte. Durch die Art der Kommunikation ist es für Banken unmöglich TLS-Verbindungen zu entschlüsseln und zu monitoren. Der Vorsitzende der TLS-Arbeitsgruppe, Sean Turner, hat den 24. Draft zur Veröffentlichung als Standard eingereicht. Nachdem alle Kommentare eingearbeitet wurden und der Standard durch weitere Gremien lief, wird nun TLS 1.3 als RFC geführt.

TLS 1.2 wurde vor etwa acht Jahren als RFC 5246 standardisiert. TLS 1.3 beschleunigt den Aufbau einer verschlüsselten Verbindung mit Features wie TLS false start und Zero Round Trip Time (0.RTT). Im Vergleich: TLS 1.2 braucht zwei Round-Trips, um den TLS Handshake durchzuführen, TLS 1.3 nur einen. Der Client gibt an, auf was er zugreifen möchte; der Server stellt den Schlüssel für die Verschlüsselung zur Verfügung; der Client stellt den Session Key zur Verfügung und dann steht die Verbindung, grob gesagt. Nachdem der Server automatisch Schlüssel bereitstellt, sollen Downgrade Angriffe vermieden werden.

0-RTT entspricht einem kleinen "Gedächtnis": An Seiten, die bereits besucht wurden, können Daten passend zur ersten Nachricht zum Server geschickt werden. dies ist zugleich kontrovers, da durch die Verwendung alter Schlüssel für zukünftige Verbindungen auch Verbindungen gespooft und damit ausgenutzt werden können. Dafür ist jedoch physischer Zugriff auf die Maschine notwendig.

TLS 1.3 entfernt obsolete und unsichere Features, wie SHA-1, RC4, DES, 3DES, AES-CBS, MD5, Arbitrary Diffie-Hellman groups und EXPORT-strength ciphers (verantwortlich für die Downgrade-Angriffe FREAK und LogJam). Die Hoffnung ist, dass TLS 1.3 leichter richtig und sicher konfiguriert werden kann durch Admins.

Firefox, Chrome, Google und Cloudflare testen TLS 1.3 bereits produktiv, auch in OpenSSL ist TLS 1.3 theoretisch enthalten.
 

Pleitgengeier

offizielles GEZ-Haustier

Registriert
14 Juli 2013
Beiträge
7.369
Ort
127.0.0.1
Dies war bei TLS 1.3 der Fall. Verschiedene Unternehmen versuchten aktiv den Standard zu schwächen, was die Standardisierung verzögerte. Durch die Art der Kommunikation ist es für Banken unmöglich TLS-Verbindungen zu entschlüsseln und zu monitoren.

Was steckt hinter diesem Satz? Stört nicht eher andere Unternehmen und Organisationen, dass sie den Datenverkehr der Banken nicht mitlesen können?
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Ist evtl. eine Anspielung hierauf: https://www.ietf.org/mail-archive/web/tls/current/msg21275.html
Like many enterprises, financial institutions depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation. Unlike some other businesses, financial institutions also rely upon TLS traffic decryption to implement fraud monitoring and surveillance of supervised employees. The products which support these capabilities will need to be replaced or substantially redesigned at significant cost and loss of scalability to continue to support the functionality financial institutions and their regulators require.

Die Anfrage wurde recht deutlich abgekanzelt. Viel zu spät käme der Einwurf und überhaupt würde man nicht schwache Technologien bei TLS1.3 erlauben nur damit im Enterprise Bereich genau das gemacht werden kann, was TLS eigentlich verhindern soll.
 

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.079
Ort
hello world
  • Thread Starter Thread Starter
  • #5
Nun hat das "Technical Committee CYBER" des Europäischen Instituts für Telekommunikationsnormen (ETSI) eine abgeschwächte Variante des neuen Protokolls TLS 1.3 standardisiert. Enterprise TLS oder kurz eTLS erlaubt es Nachschlüssel vorzuhalten, damit Dritte die verschlüsselt übertragenen Daten entschlüsseln können.

Gleich am Anfang des Dokuments [1] fällt mir dies auf:

eTLS therefore uses longer-lived static Diffie-Hellman keys that are re-used across multiple sessions; keys could be rotated daily or weekly. This ensures that the keys can be distributed to real-time decryption middleboxes in advance, and it greatly reduces the number of keys to be stored and correlated with packet storage systems.

TLS 1.3 erzwingt den Schlüsselaustausch mit Diffie Hellman Keys, die nach jeder Sitzung verworfen werden, vgl. Ephemeral Diffie Hellman (DHE). Dies garantiert Forward Secrecy, also dass verschlüsselt aufgezeichnete Daten zu einem späteren Zeitpunkt nicht mehr entschlüsselt werden können. Zudem ist die kontinuierliche Aufzeichnung schwieriger, weil die Schlüssel ständig wechseln. eTLS weicht praktisch den neuen TLS-Standard auf.

eTLS ist laut Standard nur innerhalb von Rechenzentren vorgesehen, die beide Endpunkte sowie Monitoring unter der eigenen Hoheit haben. Nach außen wird wiederum mit TLS kommuniziert. eTLS mit Enterprise Servern bricht TLS durch die Firewall (4.2.1 in [1]), so dass die Pakete untersucht werden können. Nach TLS kann intern eTLS verwendet werden. Auch bei eTLS mit Enterpise Clients existiert eine Middlebox.

Dass diese Middlebox nicht nur in einem Rechenzentrum eingesetzt werden könnte, wurde wohl nicht weiter beachtet. Entsprechend passt auch der folgende Satz zu eTLS:

eTLS does not provide all of the security guarantees provided by TLS 1.3.
Ich bin gespannt, wer eTLS einsetzen wird.


[1] https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf
 

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.079
Ort
hello world
  • Thread Starter Thread Starter
  • #6
In der neuen Empfehlung des BSIs werden TLS 1.2 mit Forward Secrecy und TLS 1.3 empfohlen. eTLS wird nicht erwähnt.

NIST will Einsatz von TLS 1.3 verpflichtend einführend, während ETSI eTLS forciert.
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
In den Kommentaren zu dem Artikel (heise? golem? vergessen :unknown:) entspinnt sich eine Diskussion darüber, ob komplette Seiten verschlüsselt übertragen werden sollten, oder nur nicht-öffentliche Bereiche. Auslöser war die Bemerkung eines Nutzers dort, dass die Seite des BSI selbst weiterhin unverschlüsselt übertragen wird. Die Argumentation war dann, dass die Integrität und Authentizität einer Seite nur durch eine verschlüsselte Übertragung gewährleistet sei. Entsprechend wäre es natürlich etwas unvorsichtig, gerade solch eine Seite unverschlüsselt anzubieten, weil die übertragenen Daten (und zum Beispiel Empfehlungen!) von außen verändert werden könnten.

Wie seht ihr das?
 

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.079
Ort
hello world
  • Thread Starter Thread Starter
  • #8
Beim BSI bin ich allgemein vorsichtig :D Es gibt durchaus gute Guides, wie Cloud Security, aber manchmal erweckt das BSI den Eindruck einer großen, schwerfälligen Behörde, die mit ihren Sicherheitskatalogen nicht mehr hinterher kommt
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
Die Frage meinte aber eher: Würdet ihr auch sagen, dass generell alle Websites, unabhängig vom Inhalt und von der Brisanz der Daten, aus Gründen der Integrität und Authentizität verschlüsselt übertragen werden sollten.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Klar, alles verschlüsseln. Die Auswirkung auf den Prozessor sind nahezu nichtexistent (weil es da spezielle hardwarenahe Subroutinen für AES gibt), und wenn man so die Geheimdienste totrüsten kann - auf gehts!
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
Für mich spricht da gar nix dagegen. Ich wollte nur wissen, ob ihr das auch für notwendig oder zumindest sinnvoll haltet. Kann sowas halt (noch) nicht so einschätzen ;)
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Kenobi van Gin: TLS ermöglicht dir, sowohl die Authentizität des Gegenübers zu überprüfen (sofern man den CAs und der DNS-Struktur vertrauen kann) als auch die von ihm empfangenen Daten als authentisch zu deklarieren. Letztendlich schützt es alle relevanten Teilnehmer:
- Serverbetreiber, weil sie Daten sicher mit den Clients austauschen können (Logins etc.)
- User, weil sie davon ausgehen können, dass die Daten auch tatsächlich vom richtigen Server kommen und damit die sind, welche sie haben wollen
- Politiker, weil sie nun vor sich selbst (und ihrer Gier nach Daten) geschützt werden

Wem es nicht nützt:
- Kriminellen, weil sie nun nichts mehr in den Datenstrom einschleusen können und sie damit die Server angreifen müssen, die meist schwerer gesichert sind
- Geheimdiensten, weil ihre Schnüffelei nun bis in 40-50 Jahren keinen Sinn macht, wenn sie dann nachträglich sehen können, wie Omas Lieblingsrezepte im Jahr 2019 von Chefkoch.de an Hilde Maier geschickt wurden

Es gewinnen und verlieren also jeweils die Richtigen. Man könnte auch sagen: Wer gegen Verschlüsselung ist, unterstützt Kriminelle und Terroristen.
 
Oben