Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).
IT Sicherheit #14 - X.509-Zertifikate und Zertifizierungsstellen
Das Wichtigste aus dem Video
Tipp auf eine Zeit – das Video springt genau dorthin.
Transkriptautomatisch erstellt · 63 Zeilen
- Hey Leute und herzlich willkommen zurück zur IT-Sicherheit. Heute geht es noch mal ein bisschen um Kryptografie, aber sehr sehr praktische Kryptografie und zwar wie man digitale Signaturen,
- CAs und Zertifikate anwendet, beziehungsweise was ist überhaupt eine CA? Eine CA lässt sich ja nicht unbedingt anwenden in dem Sinne. Es ist also relativ komplex heute und wir wollen uns angucken, wie können wir denn jetzt diesen Schlüssel hier, den wir hier schon
- versucht haben zu übertragen, wie können wir den vor einem man-in-the-middle-angriff schützen? Das heißt, wie kriegen wir den zum Client und können sicherstellen, dass der Client auch wirklich unseren Schlüssel bekommt und nicht
- irgendeinen fremden Schlüssel, der von einem Angreifer zum Beispiel ist. So, das machen wir mit sogenannten Certificate Authorities,
- Zertifikaten, also Certificate Authorities, sorry,
- die stellen mir Zertifikate aus und diese Zertifikate können oder befähigen mich dann, digitale Signaturen zu erstellen.
- Also, was jetzt passiert ist folgendes, ich möchte diesen Schlüssel hier nicht nur übertragen, sondern ich möchte auch unterschreiben, dass das mein Schlüssel ist. Das heißt, ich versuche irgendwie eine Unterschrift darunter zu quetschen und das mache ich nicht mit diesen
- schwachen echten Unterschriften, also ich meine, eine Unterschrift im echten Leben kann ja so leicht gefälscht werden, wenn es mit digitalen möglich wäre, dann wären wir schon alle im Arsch.
- Und deswegen gibt es auch wirklich hier kryptographische Verfahren, zum Beispiel den Digital Signing Algorithm, DSA kurz genannt und nein, nicht an das schwarze Auge denken, sondern wirklich an den Algorithmus oder auch mit RSA.
- Das heißt, wir haben hier mehrere algorithmische Methoden, wie man das machen kann und der kleine aber feine Unterschied ist, wir benutzen jetzt hier den
- Private Key, also der dunkle Blau hier unten, zum unterschreiben, dass das auch wirklich mein Schlüssel ist und mit dem Public Key
- wird überprüft, ob die Unterschrift echt ist. Dann kann niemand außer mir Unterschriften erstellen, denn nur ich habe diesen Private Key hier, aber jeder kann überprüfen, ob das auch wirklich meine Unterschrift ist. Das heißt, wenn ich diese Unterschrift hier drunter hänge,
- dann kann nur noch ich diesen Schlüssel austauschen oder diese Unterschrift für diesen Schlüssel hier erstellen, denn niemand anders kann ja Unterschriften für mich erstellen. Also bin ich sozusagen sicher,
- okay, das ist die Unterschrift vom Server. Das Problem, was ich jetzt aber immer noch habe, ist, wie kriege ich den Public Key zum
- unterschreiben an den Client, der kann ja ausgetauscht werden. Das ist im Prinzip genau dasselbe wie bei Man in the Middle und das ist etwas schlecht. Und genau für solche Zwecke wurden CAs eingeführt, also
- Certificate Authorities. Ich meine, so übertragen vom Public Key, Private Key lässt sich ja ganz gut machen, auch ohne Unterschriften, auch ohne CA, wenn man aber wirklich sicherstellen kann, dass das Ganze nicht vollautomatisch ablauft. Sprich, ein Mensch guckt drauf und sieht, ah, okay,
- ja, das hatte ich ja mit ihm abgesprochen, fängt so und so an, hört so und so auf, kann man alles machen. Aber, wenn man sich jetzt zum Beispiel irgendwie auf eine Webseite einwählt, dann möchte man das nicht bei jeder Webseite wirklich
- manuell machen und dann mit dem Support telefonieren. Wie lautet denn euer Public Key? Wie lautet euer Public Key? Das wäre, ja, wäre umständlich. Und deswegen sagt man hier, okay, ich möchte zwar unterschreiben,
- aber ich benutze eine sogenannte CA, eine Certificate Authority, um meinen eigenen Public Key einzutragen. Das ist nochmal kurz die Animation dazu, ich habe es verpeilt, sorry.
- Und zwar, ich unterschreibe diesen Schlüssel, also ich schicke den Schlüssel und unterschreibe, dass er von mir ist, mit meinem Private Key unterschrieben und verifiziert wird das Ganze mit dem Public Key hier, also mit dem hier unten. So,
- das hier ist der Public Key, mit dem nachher verschlüsselt wird, das ist der Public Key, mit dem Unterschriften von mir überprüft werden. Okay, jetzt, wie kriege ich den Public Key für meine Unterschriften zum Client? Das mache ich ganz einfach, ich trage den in eine sogenannte Certificate Authority
- ein und ich gebe denen meinen Schlüssel und die stellen mir ein sogenanntes X.509-Zertifikat oder X.509-Zertifikat aus.
- Und dieses X.509-Zertifikat kann ich jetzt an den Client übertragen und der kann dieses Zertifikat überprüfen. Warum kann er dieses Zertifikat überprüfen? Naja, was bei diesen Zertifikaten passiert, ist folgendes,
- da wird erstens mal der Schlüssel hier eingetragen, also mein öffentlicher Schlüssel und dann wird das komplette Zertifikat unterschrieben von der Certificate Authority, das heißt, die haben auch ihren Public Key und ihren Private Key
- und der Public Key von der CA, der ist überall eingetragen, auf dem Client-Rechner, auf dem Server-Rechner, auf allen Rechnern ist der eingetragen. So die Theorie. Wir kommen nachher zu der Praxis.
- Was jetzt also passiert ist, das Ding hier wird unterschrieben, dass es auch wirklich meiner ist. Das heißt, hier muss wirklich eine Überprüfung stattfinden, ob dieser Server auch wirklich der Server ist, für den er sich ausgibt. Ich kann jetzt nicht einfach ein
- Zertifikat eintragen für google.com zum Beispiel, weil mir eben diese Webseite nicht gehört. Und wenn ich dieses Zertifikat habe, dann kann ich es einfach rüber schicken, dann wird zuerst die Unterschrift von der CA überprüft.
- Die ist ja leicht überprüfbar, weil der Public Key hängt ja überall rum, also den kennt jeder. Das heißt, ich weiß, okay, das ist auch wirklich dieser Public Key vom Server und das wurde von der CA unterschrieben. So, jetzt kann ich mit diesem Public Key die
- Unterschrift auf diesem Public Key hier überprüfen und
- also der Client kann das, nicht ich. Und dadurch bin ich mir sicher, dass dieser Public Key zum Verschlüsseln nicht ausgetauscht wurde.
- So, das ist jetzt ein relativ harter Prozess, es wird aber noch härter. Und zwar, es gibt nicht nur eine CA, logischerweise. Es gibt ja sehr, sehr viele Unternehmen und wen sollte man als Root CA,
- so heißt das Ganze, wen sollte man als einzige CA benutzen, ohne irgendwie Vertrauen oder sowas geht da gar nichts. Und welches Land, welchem Land wird denn bitte von allen Ländern vertraut? Ich meine,
- Russland und USA, es ist sowieso immer so ein bisschen schwierig. Das heißt, die beiden fallen schon mal raus. Deutschland, naja, hat auch nicht überall nur Freunde.
- Also, es wird schwierig und was man sich deswegen gedacht hat, ist, okay, es gibt mehrere sogenannte Root CAs, also Root Certificate Authorities und die wiederum können
- Zertifikate ausstellen für CAs und die CAs wiederum können Zertifikate für weitere Unter-CAs ausstellen und die wiederum stellen dann auch wirklich Zertifikate für Server aus.
- Ihr seht, das Ganze ist ein langer, langer Prozess und wirklich nicht einfach. Und wir schauen uns das Ganze mal in der Praxis an.
- Ich wechsel mal dazu ganz kurz auf meine Website und ich weiß immer noch nicht, warum das Ding hier so verpixelt ist. Wir wählen mal hier dieses Bild. So, wir sehen hier oben
- HTTPS, sehr gut. Das heißt, das Ding ist sicher verschlüsselt und so soll es natürlich auch sein. Aber wie kann ich jetzt das Zertifikat von meiner Webseite angucken? Dazu einfach rechtsklick, untersuchen und dann öffnet sich hier dieses wunderbare Ding. Wenn das Ding bei euch etwas kleiner ist,
- zum Beispiel so, dann wundert euch nicht. Einfach breiter ziehen und ihr seid dabei. So. Und was jetzt passiert, ist folgendes. Wir wählen hier unter den ganzen Elementen hier oben nichts aus. Also, das hier könnte wahrscheinlich dem Webdeveloper unter euch
- bekannt vorkommen, aber das muss tatsächlich jetzt gerade nicht sein. Wir gehen unter Security. Unter Security finden wir Valid HTTPS. So, und hier finden wir auch die ganzen Informationen, zum Beispiel, dass mit TLS 1.2
- verschlüsselt wird, was die aktuelle Version ist. Was anderes wie TLS 1.2 sollte nicht verwendet werden. Wir sehen hier, dass das Ganze mit RSA
- ausgetauscht wurde und dass wir jetzt insgesamt, dazu komme ich aber im nächsten Video erst, mit AES 128 verschlüsseln, weil die ganze Zeit asymmetrisch zu verschlüsseln ist zu ineffizient. Das heißt, es braucht zu viel Leistung.
- Aber dazu, wie gesagt, später mehr. So, wir gucken uns jetzt das Zertifikat an. Und hier sehen wir, es ist ein SSL Server Zertifikat
- und das ist sozusagen der Verwendungszweck. Es darf nur als solches benutzt werden. Ja, und ich muss mal wieder was machen, deswegen gerade dieser Wecker. Sorry.
- So, wir sehen hier Organisationen habe ich keine eingetragen. Organisationen Einheit habe ich auch keine eingetragen.
- Und jetzt hier, wer hat mir das Zertifikat ausgestellt? Das ist die Let's Encrypt Authority X3. Die gehört zur Organisation von Let's Encrypt. Das kennt ihr wahrscheinlich, habe ich ein Tutorial dazu gemacht.
- Und das Zertifikat ist gültig vom 30. Mai 2017, da habe ich es erneuert, bis zum 28. August 2017, da muss ich es als nächstes wieder erneuern und zwar immer fünf Minuten vor Mitternacht. So, hier haben wir noch den
- sozusagen den Fingerabdruck jeweils von diesem Ding und zwar zwei verschiedene, damit es besonders aufwendig ist. Nee, Shade 1 ist einfach nicht mehr aktuell. Wir gehen jetzt aber hier unter Details und zwar sehen wir hier, themorphoes.de
- hat ein Zertifikat von der Let's Encrypt Authority X3 bekommen und die wiederum haben natürlich auch ein Zertifikat. Das heißt hier irgendwo steht ihr Public Key.
- Also hier der Algorithmus zum Beispiel und der öffentliche Schlüssel des Public Keys. Wir sehen das Auftragsteller,
- Antragstellers und das ist in dem Fall jetzt der Public Key von der CA, also von Let's Encrypt. Und dann geht es noch eins weiter nach oben und zwar zur DSC Root CA.
- Und die wiederum haben auch einen Public Key hier und die dürfen ihre eigenen Schlüssel selber unterschreiben. Das heißt, die Unterschrift ist auch wieder von denen, aber die kennen so viele Leute,
- deswegen kann man denen so vertrauen. Und ganz unten bin natürlich ich, wir können hier aber trotzdem ganz gerne durch das komplette Zertifikat durchgehen. Wir sehen Version 3, Seriennummer ist die hier, sagt uns nicht wirklich viel.
- Algorithmus, so der sagt euch jetzt vielleicht was und zwar ist das Full Domain Hash RSA Verschlüsselung oder RSA, ja im Endeffekt gewesen und zwar wird da erstmal die komplette Nachricht in Anführungsstrichen
- gehashed mit Shade 256 und danach RSA verschlüsselt. Da könnt ihr gerne noch ein bisschen genauer bei mir nachgucken in der Kryptografie Playlist, da stelle ich auch diesen PKCS 1 vor.
- So, Aussteller steht hier dabei, das heißt hier muss auch wirklich überprüft werden, ist es auch wirklich von Let's Encrypt und da muss natürlich genau den richtigen Pfad zur nächsten CA gegangen werden. Ich kann jetzt hier nicht irgendwie für
- CA XY überprüfen, sondern ich muss natürlich mit dem Public Key von der Let's Encrypt Authority überprüfen, deswegen muss der hier natürlich auch drin stehen.
- Hier steht die Gültigkeit drin, damit die nicht unendlich gültig sind. Antragsteller bin ich und da steht noch mal genau der Algorithmus drin und hier ist unser öffentlicher Schlüssel dann drin, der eigentlich nicht wirklich viel sagt, außer dass es
- 2048 Bit sind. Ja, okay und hier unten gibt es noch sehr sehr viele verschiedene Erweiterungen. Diese Erweiterungen, die kann man eintragen, muss man aber nicht.
- Da gibt es zum Beispiel auch sogenannte Extended Zertifikate, die werden normalerweise von Banken benutzt, da muss man dann aber wirklich, um so ein Zertifikat zu bekommen, vor Ort sein, muss dort eine Telefonnummer eintragen, muss sich mit Ausweis ausweisen, dass man auch wirklich derjenige ist, um so ein
- Zertifikat zu bekommen. Das musste ich jetzt für meins hier nicht, aber ich musste natürlich das Zertifikat auf meinem Server erstellen, damit man auch wirklich sicherstellen kann, dass ist auch wirklich the-morpheus.de und nicht irgendwas anderes.
- Ja, das ist eigentlich alles, was ihr zu Zertifikaten erstmal wissen müsst. Damit kann jetzt dann natürlich der Public Key ausgetauscht werden und dann kann angefangen werden,
- asymmetrisch zu verschlüsseln, ohne dass es einen man in the middle Angriff gibt und das ist schon wirklich enormer Aufwand, was man da betreibt, aber es lohnt sich. Gut, das war's von meiner Seite, ich hoffe es hat euch gefallen und wir hören uns beim nächsten Mal. Bis dann, ciao!
Zum Nachlesen
Digitales ZertifikatEin digitales Zertifikat (auch Sicherheitszertifikat) ist eine Datenstruktur, die die Zuordnung eines öffentlichen Schlüssels zu einer Identität oder …
Hypertext Transfer Protocol SecureHypertext Transfer Protocol Secure (HTTPS; englisch für „sicheres Hypertext-Übertragungsprotokoll“) ist ein Netzwerkprotokoll im World Wide Web, …
Public-Key-InfrastrukturBestandteile einer PKI · Digitale Zertifikate: Digital signierte elektronische Daten, die sich zum Nachweis der Echtheit von Objekten verwenden lassen.
Zertifizierungsstelle (Digitale Zertifikate)Ein digitales Zertifikat dient dazu, einen bestimmten öffentlichen Schlüssel ... Ein Extended-Validation-Zertifikat (EV-Zertifikat) entspricht den …