Wieso können sie das nicht machen, ohne den Standard zu beeinflussen?

[__destruct()]

Der Schlüssel wird doch jedes mal vom Server gewählt, nicht von anderen. Dann schreiben die ihre Software eben so, dass er jedes mal den gleichen Schlüssel wählt. Wo ist das Problem?

[wiesi200]

Der Schlüssel wird von der SSL Library generiert. Die Diskutieren wie die Librarys funktionieren soll. Und wenn man definiert das der Schlüssel immer gleich bleibt dann hast du eine Potentielle Sicherheitslücke in der Software. So einfach ist das.

[__destruct()]

Die diskutieren doch über den Standard, nicht über die Implementierung, oder?

[Anonymer Nutzer]

offensichtlich nicht. es wird wohl tatsächlich darüber diskutiert, ob man tls 1.3 richtig oder falsch implementieren soll. komische situation. die sache mit rsa ist allerdings tatsächlich eine frage des protokolls. was google und co in ihren rechnenzentren machen, muss uns sowieso egal sein.

[__destruct()]

Nein, es geht um den Standard, nicht um die Implementierung. Die IETF macht Standards. TLS 1.3 ist noch nicht standardisiert und das ist der aktuelle working Draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-21 Er ist vom 3. Juli, also noch keine 3 Wochen alt. Es wird aktuell diskutiert, wie (aufbauend auf den working Draft) der Standard aussehen soll.

[Anonymer Nutzer]

ob ich immer die gleichen dh-parameter verwende oder zufällige, bleibt aber schon der implementierung überlassen.

[Nocta]

Nein, immer die gleichen DH Parameter zu verwenden widerspricht dem Standard. Es könnte als Implementierungsfehler gewertet werden, aber sicher nicht als Spielraum um die Spezifikation zu erfüllen.

Hindern kann dich letztlich keiner daran, sofern die Gegenseite das nicht explizit überprüft. Es ist in der Hinsicht konform zum Standard, dass es nicht zum Abbruch des Protokolls führen wird, aber nicht in der hinsicht, dass es wie vom Standard gefordert umgesetzt ist.

[Anonymer Nutzer]

naja, tut es das? ich seh den standard erfüllt, sobald zwei unterschiedliche implementierungen miteinander erfolgreich kommunizieren können. alles anderes kann maximal eine empfehlung in zusammenhang des standards sein, aber mehr nicht. und ich glaub, dass die ietf darüber gar nicht diskutieren sollte. im standard steht, es wird aus sicherheitsgründen empfohlen, pro session neue parameter zu generieren. wenn cisco und co das ignorieren sollen, sollen sie. prüfen wird man es wohl eher schwer können, außer man baut standardmäßig als client mehrer verbindungen auf und schaut, ob die parameter gleich sind. anhand einer einzelnen verbindung ist das nicht zu erkennen, was wiederum ein indiz dafür ist, dass sowas eben nur eine empfehlung in zusammenhang mit dem standard sein sollte. deshalb finde ich die diskussion sinnlos.

[Nocta]

Vermutlich hast du Recht und vielleicht steht sogar sowas wie "SHOULD" dabei, dass neue Keys erstellt werden *sollten* und nicht *müssen*.

Ich denke, die Diskussion führt uns nicht weiter, man müsste da wirklich konkret den Standard lesen und die Argumente haben vielleicht auch mehr Facetten, als im Artikel dargestellt.

> ich seh den standard erfüllt, sobald zwei unterschiedliche implementierungen miteinander erfolgreich kommunizieren können.

Das will ich allerdings nicht so stehenlassen. Es gibt oft Implementierungen, bei denen andere Implementierungen Workarounds finden müssen, damit alles kompatibel ist. Oder wo nur bestimmte Szenarien wirklich funktionieren. Nicht speziell auf TLS bezogen, aber da gibt es auch einige nicht-standardkonforme Implementierungen, bei denen man aber trotzdem erfolgreiche Kommunikationen mit anderen Implementierungen erreichen kann. Das kann sogar so weit gehen, dass in einer Aktualisierung des Standards berücksichtigt werden muss, dass es nicht-standardkonforme Clients gibt und dass sie nicht richtig auf die Änderung reagieren würden, man daher Workarounds finden muss. Daher reicht eine erfolgreiche Kommunikation nicht wirklich aus, wenn es nur durch Workarounds oder nur mit Einschränkungen geht. Auch kann man den Sinn eines Standards Ad Absurdum führen, ohne die Kommunikation zweier Teilnehmer zu beeinträchtigen. Aber das wird jetzt ganz stark OT :)



2 mal bearbeitet, zuletzt am 22.07.17 16:52 durch Nocta.

[__destruct()]

"ich seh den standard erfüllt, sobald zwei unterschiedliche implementierungen miteinander erfolgreich kommunizieren können." Ist wohl wirklich etwas weit gefasst. Ich sehe einen Standard als erfüllt an, sofern die Implementierung mit allen Implementierungen des Standards in allen Situationen kommunizieren kann. Und das scheint hier gegeben zu sein.