Security

Ich habe in einem früheren Artikel darauf hingewiesen, dass Java (17) und Python (3.10) sich bei der Validierung von x509-Zertifikaten ein wenig unterscheiden. Einer der Unterschiede ist die Schwelle, ab der Schlüssel wegen zu geringer Länge als unsicher bewertet und die damit verbundenen Zertifikate abgelehnt werden.

Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern hat eine Erweiterung erfahren und verfügt über ein Partnerprojekt - beide sind nunmehr in der Version 1.0.0 freigegeben

Ich habe bereits über meinen nicht angenommenen Vortrag auf dem 37c3 berichtet. Diese Einreichung geschah nicht, um meinem Ego zu schmeicheln, oder nur um mal in einem Internetvideo aufzutreten. Ich verfolge die daraus entstandene Idee weiter, Möglichkeiten zu schaffen und anzubieten, um Implementierungen, die auf X509 Zertifikaten beruhen, verlässlich zu testen.

Ich habe auch vergangenes Jahr wieder einen Vortrag zum 37c3 eingereicht, der aber leider nicht angenommen wurde...

Neulich wurde ich auf eine Frage aufmerksam, die ich - sensibilisiert durch die hohe Anzahl von Vorträgen zum Thema "Validierung von Zertifikaten" auf der letzten DefCon - selber und näher untersuchen wollte: Werden elektronische Zertifikate programmiersprachen- und frameworkübergreifend identisch validiert oder existieren hier Unterschiede?

Ich wollte bereits seit einiger Zeit ein Beispiel veröffentlichen für die Kommunikation über mit Transport Layer Security (TLS) gesicherte Kanäle. Nun habe ich endlich die Zeit gefunden, dies in Angriff zu nehmen:

Ich habe mich ein wenig mit Attribut-Zertifikaten beschäftigt - Resultat sind einige Klassen zum leichteren Zugriff auf die enthaltenen Attribute...

Ich habe an dieser Stelle bereits früher über Möglichkeiten der Nutzung von Einmalpasswörtern entsprechend RFC RFC 6238 in Java-Anwendungen berichtet. Nun wollte ich untersuchen, ob sich 2-Faktor-Authentifizierung in das Framework Java Authentication and Authorization Service (JAAS) integrieren lasen würde.

Es gibt inzwischen einen von mir erstellten Fork des originalen Repository, in dem ich die Komponente zur Darstellung der Konsole gegen die ausgetauscht habe, die in der sQLshell in den Plugins MDIJavaEditor und MDISqlEditor zum Einsatz kommt - dadurch wird wenigstens durch das Syntax-Highlighting auf problematische Stellen im Code hingewiesen.

Mit Version 1.4.0 wurden die Gegenmaßnahmen gegen Trojan Source und Trojan SQL endlich in einer Release auf Repsy zur Verfügung gestellt.

Ältere Artikel

Hier geht es zum Archiv der Artikel, die vor dem 03.09.2023 verfasst wurden:

• Präsentation "Vergleich Analoger und Digitaler Identitäten"
• TLS einfach so im Klartext lesen
• ...