OHM #008 – Ohne Heftige Mängel

"Lac lake Balaton Hongrie Hungary Siofolk photo picture image" von SuperCar-RoadTrip.fr unter CC-BY

Wir haben ein Problem. Das Problem ist, dass wir glauben, dass wir verschlüsselt im Netz surfen, wenn im Browser die angegebene Adresse mit https:// beginnt. Das stimmt so nicht. Denn wie mit jeder Technologie, ist die Materie die hinter dieser Zeichenkette etwas komplizierter.

So kompliziert, dass ich in dieser achten Folge unserer herzallerliebsten Podcastreihe hart an meinem Erständnishorizont entlangsurfe, wenn mir Hannes (Github, Twitter) und erdgeist zu versuchen zu erklären, was daran alles kaputt ist und wie Hannes versucht hat, diese Technologie so neu zu implementieren, dass es diese Probleme nicht mehr gibt.

Sogar so kompliziert, dass diese Veröffentlichung dieser Aufnahme sich um ganze acht Monate verzögerte. Weil die Aufnahme nämlich auf seltsam-obskuren Datenträgern verschollen war.

Möglicherweise auch, weil ich die erste Aufnahme technisch verpeilt hatte und wir so lange gebraucht haben, um einen neuen Termin zu finden. So genau weiß man das nicht, aber das hier ist auf jeden Fall die sagenumwobene verschollene Folge.

Hören Sie also nun, was der Unterschied zwischen SSL und TLS ist, welche Probleme Implementationen haben und wieso es gut sein kann, ganz funktional zu programmieren. Die Geschichte beginnt – nach einer Einführung – am Strand von Marokko:

OHM ist eine Kollaborationsproduktion der Herren @erdgeist & @monoxyd. Bei Gefallen abonnieren (RSS, iTunes), kommentieren (Artikel, iTunes) und flatterieren (erdgeist, monoxyd) Sie bitte reichhaltig.

So eine Art Shownotes:

Die Details zum TLS-Projekt von Hannes:

Schlagwortverzeichnis in der Reihenfolge des Erscheinens:

  1. SSL
  2. TLS
  3. IETF / RFC
  4. SSH
  5. Registrare / Certificate Authorities
  6. Registrarhack bei Heise: SSL-GAU: Ein Angriff im Cyberwar?
  7. Implementationen: OpenSSL / S-Channel / Secure Transport / GnuTLS / NSS
  8. Verschlüsselungsalgorithmen: AES / Triple DES
  9. 20 Jahre Angriffe auf TLS (featuring: Heartbleed / Poodle / Freak)
  10. Warum “Heil Hitler!” die Enigma entschlüsselte
  11. Warum die OpenSSL-API schlimm ist
  12. ASN1
  13. OCaml
  14. GMP-Library / libtls / ReSSL
  15. MAC
  16. Mirage OS
  17. Xen-Hypervisor
  18. Chaosradio 209: Open Source Finanzierung. (Featuring: Das Problem der fehlenden Softwareauditierung)
  19. Fuzzing

Bild: “Lac lake Balaton Hongrie Hungary Siofolk photo picture image” von SuperCar-RoadTrip.fr unter CC-BY

0 0 0

11 Comments

Filed under [ohm], podcast

11 Responses to OHM #008 – Ohne Heftige Mängel

  1. Pingback: Firefox (und TLS) des tages | Schwerdtfegr (beta)

  2. Pingback: Die letzten und nächsten 24h, Donnerstag, 09.04.2015 | die Hörsuppe

  3. peter

    hallo, ich würde gerne euren podcast in meinem podcast client abonnieren, doch ich finde keinen feed~link dafür ~ nur txt-feed, oder habe ich den irgendwie/wo übersehen? itunes nutze ich nicht.
    vielen dank und liebe grüße

  4. rekjng

    Klasse Folge! Da Hannes am Ende nach neuen Protokollen zum Implementieren fragt, will ich einen Blick auf SQRL zum sicheren Webseiten-Login nahelegen:

    https://www.grc.com/sqrl/sqrl.htm

    Recht neu, aber konzeptionell wirklich gut durchdacht, wie ich finde. Passenderweise wurde das Prinzip auch zuerst in einem Podcast beschrieben. 🙂

    Da Hannes (oder war es David), wenn ich mich recht erinnere, am Ende seines Vortrages auf dem 31C3 sich auch an der Portierung von Mirage OS auf noch schlankere Hypervisoren interessiert zeigt, sei ferner ein Blick auf NOVA empfohlen, der derzeit wohl vor allem im Kontext von Genode fortentwickelt wird:

    http://hypervisor.org/
    http://genode.org/

  5. Hannes

    Hallo rekjng,

    sqrl sieht durchaus interessant aus, danke fuer den Hinweis.

    Neben Nova finde ich persoenlich ja L4 bzw verified L4 interessant. Bloss steht zumindest auf meinem Plan fuer 2015 nicht die Portierung auf neue Hypervisor 😉

  6. @peter: Der Link zum RSS-Feed: http://monoxyd.de/category/ohm/feed (Steht auch oben im Artikel. :D)

  7. DJ

    Hallo ihr zwei,

    zunächst einmal danke dafür, dass ihr Euch die regelmäßig die Zeit nehmt und dann auch noch die Folgen kostenlos ins Netz stellt. Ist nicht selbstverständlich und deshalb Daumen hoch!

    Diese Folge war in meiner Wahrnehmung die beste bisher, da sie technisch tief ging und nicht nur an der Oberfläche gekratzt wurde. Ich habe auch nach dem zweiten Mal hören nicht alles verstanden, aber das macht auch nichts. Das Thema war interessant, gut vorbereitet und Hannes war ein sehr sympathischer Gesprächspartner, dem man die Liebe zum Thema deutlich angehört hat.

    An dieser Stelle setzt auch mein einziger Kritikpunkt an: Hannes hatte für meinen Geschmack etwas zu wenige Anteile am Gespräch. Dies mag vornehmlich an seinem Charakter liegen, aber evtl. auch daran, dass Erdgeist recht schnell mit einer zusätzlichen Erläuterung dabei war und Hannes anschließend nicht mehr zum eigentlichen Punkt zurück kam.
    Manchmal etwas mehr Zurückhaltung wäre m.E. wünschenswert gewesen.

    Aber das ist “Jammern auf hohem Niveau”.

    Macht weiter so!!

  8. Christoph

    Eine schöne Folge, danke.

    Ein kleiner Seitenhieb auf die Vergangenheit muss dennoch sein: Wie kann es sein, dass PolarSSL auch Bug bei den State-Transitions hatte, wo uns Erdgeist erklärt hatte, das wäre alles verifiziert?

    Ich nehms eh nicht so krumm, aber ich fand den vermittelten Eindruck, dass Softwareverifikation mal eben so gemacht werden kann, doch sehr problematisch.

  9. Hannes

    @DJ ja.. daher schreibe ich lieber Texte 😉 Ich falle ungern anderen ins Wort.

    @Christoph “Verifikation” ist ein starkes Wort, und wird in unterschiedlichen Communities benutzt mit anderer Semantik. Was an PolarSSL “verifiziert” wurde (laut http://trust-in-soft.com/no-more-heartbleed/) ist CWE 119 to 127, 369, 415, 416, 457, 476, 562, 690: im grossen und ganzen temporal and spatial memory safety (was mensch beides umsonst bekommt in einer Sprache mit automatischer Speicherverwaltung!)

    Wenn wer ueber “Verifikation” spricht, sollte die erste Frage sein, was das Theorem ist, das bewiesen wurde, und an zweiter Stelle die Annahmen, die getroffen wurden. An dritter dann die Trusted Code Base. (Disclaimer: Ich habe 3 Jahre an Verifikation der funktionalen Korrektheit von object-orientierter Software geforscht http://www.itu.dk/research/tomeso/).

  10. Pingback: Warum man unbedingt javascript beschränken sollte… | Schwerdtfegr (beta)

  11. Pingback: OHM011 – Otto hört mit | monoxyd

Leave a Reply

Your email address will not be published. Required fields are marked *