Get best of the week

Eine Einführung in TLS für Patrik Patrick (Teil 1)

Wie Sie vielleicht bereits wissen, ist dies Patrick. Er ist ein Seestern, was bedeutet, dass man ohne Beleidigung sagen kann, dass seine Hände von einem Ort aus wachsen. Patrick ist auch sehr praktisch und vergisst sofort alles, was er nicht braucht - aber wenn er etwas braucht, will er es wissen (weil er es braucht!). Spoiler: Hier versucht Patrick einen TLS Handshake zu machen.



Dieser Artikel ist für Patrick und Leute wie ihn geschrieben. Sie wurde aus einer Präsentation geboren, die erstmals auf unserem internen Plesk TechTalk gezeigt wurde, wo Mitarbeiter in zugänglicher Form Informationen über interessante Technologien, Prozesse und Lösungen miteinander austauschen. Daher sehen die Bilder in diesem Artikel wie Folien aus :) Der Autor des Originaltextes des Berichts ist Programmmanager Plesk Ruslan Kosolapov .

In der Regel deckt das gesamte TLS-Material einen kleinen Aspekt ab, nicht jedoch das Gesamtbild. Das ist nicht sehr praktisch und Patrick hat Kopfschmerzen. Hier wird alles anders sein: kurz, anwendbar „im Alltag“ und so umfassend wie möglich.

Was ist TLS und warum ist es für Patrick?


TLS (Transport Layer Security) ist ein Transportschicht-Schutzprotokoll. Es wird benötigt, damit niemand auf Sie "hören" und wichtige Informationen herausfinden kann (meistens Passwörter, wenn wir über die Arbeit im Netzwerk sprechen). Und auch, um sich während der Übertragung vor Fälschungen und Verkehrsänderungen zu schützen. In diesen beiden Dingen liegt der Zweck von TLS.

Betrachten wir aus Gründen der Klarheit den TLS-Handshake als einen Anruf bei Patrick SpongeBob. Während eines Anrufs kann jemand das Gespräch belauschen (neben Patrick stehen oder sich in der Mitte der Leitung einschalten), und im Allgemeinen befindet sich der SpongeBob möglicherweise nicht am anderen Ende - all diese Probleme sind relevant. Und um sie zu lösen, möchte Patrick TLS verwenden.

Kurz gesagt, der Handshake der obersten Ebene sieht folgendermaßen aus:

Patrick: Ich möchte TLS verwenden, die Chiffrierversionen sind so und so.
SpongeBob: Ok, lass uns solche und solche Chiffrierversionen verwenden.

Danach sendet SpongeBob das Zertifikat, Patrick überprüft es und sagt, dass alles in Ordnung ist. Der Sitzungsschlüssel ist fertig (es gibt tatsächlich zwei davon, aber das spielt keine Rolle). Warum einen Sitzungsschlüssel anstelle einer asymmetrischen Verschlüsselung verwenden - weil er schneller ist? Danach beginnen sie eine Sprache zu sprechen, die für die Entschlüsselung unverständlich ist. Somit ist alles geschützt.

Alles scheint einfach zu sein. Wie es auf Hardware funktioniert, ist für uns nicht so wichtig. Aber wenn Sie anfangen zu denken - und Patrick beginnt zu denken! - das wirft die Frage auf, wie man allgemein zustimmt, dass wir TLS verwenden werden? Immerhin gab es einmal kein TLS, aber nur gewöhnliche Protokolle - SMTP, HTTP. Wie kann man sagen, was auf TLS benötigt wird? Und hier in unserer Branche ist alles wie gewohnt - es gibt viele Möglichkeiten!

Zuerst wollten sie einen bestimmten Port verwenden, was die Verwendung von TLS implizieren würde. Was sind die Nachteile davon? Und warum erschien dann die explizite (explizite) Methode zum Starten einer TLS-Sitzung? Es gibt verschiedene Gründe:

  1. Sie benötigen viele Ports - und Ports sind so etwas, das Sie nicht ausgeben möchten. Denn je mehr es gibt, desto schwieriger ist es, die Firewall zu konfigurieren.
  2. Der Server kann dies ignorieren - er hat eine Verbindung zu Port 443 hergestellt und es gibt dort kein TLS, nur HTTP ohne HTTPS.
  3. Bevor die Verbindung hergestellt wird, können Sie nicht herausfinden, ob der TLS-Server unterstützt wird oder nicht.

All dies führte zur Entstehung einer expliziten Methode - wenn wir eine Verbindung zu einem regulären Port herstellen und dann unsere Sitzung auf TLS aktualisieren. Für verschiedene Dienste verfügt das Protokoll über unterschiedliche Befehle. Für SMTP gibt es beispielsweise einen separaten Befehl auf der Ebene des SMTP-Protokolls - STARTTLS . HTTP hat auch einen solchen Witz, es heißt Upgrade: TLS / 1.0 . Auf Protokollebene ist es einfacher zu verstehen, ob ein TLS-Server unterstützt wird oder nicht.

Lassen Sie uns etwas näher auf die verschiedenen Arten von Verbindungen eingehen und wie die Dinge mit TLS für sie sind.

Verbinden: HTTP


Alles wäre einfach, wenn es wie immer keine Nuancen gäbe. Im Fall von HTTP bieten die wachsenden Sicherheitsanforderungen eine ständige Weiterentwicklung des Arbeitsprozesses mit TLS. Zuerst gab es eine Umleitung zu HTTPS, und dies wurde einfach im Header durchgeführt. Dies hinterließ eine Lücke für Sicherheitslücken, sodass Google-Kollegen HSTS (HTTP Strict Transport Security) entwickelten. Dies ist ein solcher Header in der HTTP-Antwort, der dem Browser mitteilt: "Bitte denken Sie daran, dass Sie, wenn Sie zu dieser Domain kommen, direkt zu HTTPS wechseln, auch wenn die Person Sie aufgefordert hat, zu HTTP zu wechseln." Somit gibt es keine Weiterleitung und alles geschieht viel sicherer. Darüber hinaus hat Google eine weitere Initiative: Sie können eine Anfrage hinterlassen, damit Ihre Website unabhängig von Überschriften zur Liste für Google Chrome "Immer HTTPS verwenden" hinzugefügt wird.

Kurz: HSTS behebt die Umleitung von HTTP- zu HTTPS-Schwachstellen, sodass fast alle Browser HSTS unterstützen, was gut ist.

Connect: exotisch (neue Versionen von HTTP und nicht nur)


In HTTP / 2 läuft TLS gut: Es wird immer verwendet (da jetzt Browser erstellt werden). Darüber hinaus muss TLS in HTTP / 2 frisch sein, dh Version 1.2+ haben.

Höchstwahrscheinlich wird Google sehr bald die weit verbreitete Verwendung von HTTP / 3 verkaufen, jetzt wird es vom IANA-Standard übernommen. Die Geschichte seines Auftretens und seiner Entwicklung ist ziemlich verwirrend; Die Hauptsache, an die man sich erinnern sollte Patrick:

  • HTTP / 3 ist immer TLS 1.3+.
  • HTTP / 3 basiert auf QUIC - es ist ein solches Protokoll über UDP, das laut Google besser ist als TCP. Bevor der Name HTTP / 3 endgültig genehmigt wurde, hieß das Protokoll HTTP-over-QUIC.

Es gibt noch ein interessantes SCTP-Protokoll, das hauptsächlich in der Telekommunikation verwendet wird. Darüber werden sowohl TLS als auch DTLS verwendet (dies ist ein solches TLS für UDP).

Kurz gesagt: In 2 Jahren wird QUIC (d. H. HTTP / 3) überall verwendet, aber jetzt sollte es bereits überall HTTP / 2 geben, aber in Wirklichkeit ist es nicht überall.

Verbinden: Mail


Viele Clients glauben, dass es TLS am 587. Port geben sollte, aber hier gibt es auch Nuancen: Jemand erwartet standardmäßig TLS und jemand erwartet eine explizite STARTTLS- Anforderung vom Client. Aus diesem Grund verursachen verschiedene Kombinationen von Mailserver und Mailclient manchmal unerwünschte Effekte. Beispielsweise tritt ein Client in Port 587 ein und erwartet, dass TLS vorhanden sein wird, während der Server darauf wartet, dass der Client STARTTLS explizit anfordert . Nachdem der Client nichts erhalten hat, kehrt er zu Port 25 zurück. Das Ergebnis ist ein stiller Wechsel zu einer unsicheren SMTP-Verbindung. Beim Testen und Entwickeln sollten Sie sich an solche Auswirkungen von Client-Server-Kombinationen erinnern. Autodiscaver bietet verschiedene Optionen zum Festlegen von TLS: wie es sein soll, was erwartet wird und was zu tun ist. Viele Mail-Clients verstehen diese Dinge.

Kurz: Mit der TLS-Unterstützung in Mailservern und Mailclients ist im Allgemeinen alles in Ordnung. In besonderen Fällen kann es jedoch zu Problemen kommen, und TLS-Erweiterungen werden nicht sehr gut unterstützt.

Verbinden: FTP


Hier kann wenig gesagt werden. Das Hauptproblem ist SNI (dies ist, wenn sich verschiedene Domänen auf derselben IP befinden). Auf FTP-Ebene wird der Domainname nicht übertragen. In einer expliziten Version kann es nicht funktionieren, da es keinen Ort gibt, an dem es geschrieben werden kann. Es gibt verschiedene Lösungsoptionen - einige bieten an, andere bieten eine allgemeine Lösung an, es gibt noch keinen Standard.

Kurz gesagt: Es gibt eine Art TLS-Unterstützung für FTP (FTPS, SFTP - ein Analogon von FTP, das über SSH implementiert wird), aber einige Aspekte werden aufgrund der technischen Einschränkungen von FTP selbst nicht behandelt.

TLS Handshake


Jetzt wissen wir also, wie man die Kommunikation mit TLS in verschiedenen Verbindungen initiiert, und Patrick konnte SpongeBob seinen Wunsch mitteilen. Sobald sie vereinbart haben, TLS zu verwenden, wird TLS Handshake erstellt. Das Ergebnis sollte eine Vereinbarung zwischen Client und Server darüber sein, wie sie alles verschlüsseln. Darüber hinaus muss der Client sicherstellen, dass der Server derjenige ist, der benötigt wird. Manchmal überprüft der Server auch den Client (aber viel seltener).

Chiffren und Versionen


Wie bereits erwähnt, besteht der erste Schritt darin, auszuwählen, welche TLS-Version und welche Chiffren für die Verschlüsselung verwendet werden. In der Regel sieht die Verschlüsselung folgendermaßen aus:



Die Verschlüsselungssuite befindet sich in der IANA-Registrierung, und im TLS-Protokoll in binärer Form ist nur die ID angegeben. Wie Sie in der Abbildung sehen können, ist hier nicht nur (und nicht nur) die Chiffre, sondern auch deren Betriebsmodus und andere Details, die für den TLS-Handshake erforderlich sind. Patrick muss nicht auf Details eingehen. In diesem Stadium ist es nur wichtig, sich daran zu erinnern, dass diese Buchstaben gut (und der Rest schlecht) sind:

  • DHE
  • ECDhe
  • AES128
  • AES256
  • RSA
  • Ecdsa
  • Cbc
  • Gcm
  • SHA256
  • SHA383
  • CHACHA20
  • POLY1308

Bild zum Erinnern an gute Chiffren:



Wenn es schwer zu merken ist, gibt es gute Dienste, die Ihnen davon erzählen können, zum Beispiel einen Dienst von Mozilla ssl-config.mozilla.org .



Sie können sofort sehen, wo und wie es unterstützt wird - dem versuchen die Mozilla-Leute zu folgen.

Ein interessantes Detail: Der Client überträgt die Chiffren in der Reihenfolge ihrer Priorität gemäß ihren Präferenzen, aber der Server hat die Entscheidung - er wählt die Chiffre aus der Liste der unterstützten Clients aus, die am besten zu sein scheint.

Beide Seiten geben auch die maximal unterstützte Version des Protokolls an - in diesem Fall ist Patrick weiter fortgeschritten als SpongeBob.

Eigentlich Zertifikat


Zusammen mit der Antwort „Lass es uns so machen“ sendet der Server sein Zertifikat oder seine Zertifikate - es kann viele davon geben.

Was ist ein Zertifikat? Dies ist eine Beziehung zwischen Informationen (Betreff) - meistens der Name einer Domain oder Organisation - und einem öffentlichen Schlüssel (öffentlicher Schlüssel). Das heißt, auf dem Zertifikat steht: „Alter, mein öffentlicher Schlüssel ist so. Jetzt werden wir uns mit seiner Hilfe auf Sitzungsschlüssel einigen. “ Mit seiner Hilfe können Sie auch die Signatur von Zertifikaten oder etwas anderem überprüfen. Das heißt, es wäre grundsätzlich möglich, keine Zertifikate zu verwenden, sondern Register, in denen diese Beziehung angegeben ist. Tatsächlich werden die Schritte in diese Richtung fortgesetzt, da der Mechanismus der Zertifizierungsstelle als nicht sehr gut angesehen wird und es einfach nichts anderes gibt.

Somit ist das Zertifikat die Struktur von 'Betreff: Öffentlicher Schlüssel' plus der Unterschrift des Ishyuers (Aussteller bei der Transliteration ins Russische sieht schrecklich aus, aber das engste Synonym hier ist im Zusammenhang mit dem "Aussteller" nicht sehr nah), dass dieses Zertifikat ausgestellt wurde. Ishüyer hat auch ein Zertifikat und jemandes Verbindung zu etwas. Sie können das Zertifikat auf Richtigkeit überprüfen, indem Sie den öffentlichen Schlüssel des Ishyuere nehmen und die Signatur überprüfen. Infolgedessen kann hier nichts gefälscht werden.

Lassen Sie uns das Zertifikat durchgehen und sehen, welche Probleme es haben könnte.



Erstens impliziert die Seriennummer die Eindeutigkeit nur innerhalb der Grenzen des Ishyuere, obwohl einige Software der Ansicht ist, dass sie im gesamten Universum einzigartig ist. Glücklicherweise ist es meistens wirklich einzigartig.

Das Zertifikat gibt auch an, welche Algorithmen für die Verschlüsselung und Signatur verwendet werden: RSA oder ECDSA - dh welche Kryptografie für die Arbeit mit diesem öffentlichen Schlüssel verwendet werden soll. Der Hauptunterschied zwischen RSA und ECDSA besteht darin, dass das mathematische Prinzip von ECDSA auf elliptischen Kurven basiert und RSA einfach aus natürlichen Zahlen besteht. Daher ist es langsamer und es werden große Schlüssel (3-4 Tausend) verwendet, um zu verhindern, dass es Risse bekommt. . Und für ECDSA reicht ein 300-Bit-Schlüssel aus und es funktioniert schneller. Daher wechseln viele zu ECDSA - der Handschlag selbst ist schwer und ich möchte ihn reduzieren. ECDSA kann bei der Ausstellung eines Zertifikats angefordert werden. Wenn der Prospektor es unterstützt, wird er es für Sie tun. Die Signatur des Zertifikats hängt jedoch davon ab, welchen privaten Schlüssel ishuiur derzeit hat und nicht davon, ob Sie nach ECDSA oder RSA gefragt haben.Daher können Browser anzeigen, dass sich einer in der Signatur und der andere im öffentlichen Schlüssel befindet, und es besteht kein Grund zur Angst, wenn die Signatur nicht ECDSA ist.

Wie bekomme ich ein Zertifikat?


Kurz gesagt:

Patrick sagt der Zertifizierungsstelle: Ich brauche ein Zertifikat. Diese Person (oder Organisation) prüft, ob es Patrick ist. Schecks können sehr unterschiedlich sein. Natürlich hat Patrick als Client möglicherweise kein Zertifikat, aber wenn der Server kein Zertifikat hat, gibt es kein TLS. Es wird geprüft, ob im Zertifikatantrag alles korrekt angegeben ist, ob Patrick wirklich den Betreff besitzt, für den er ein Zertifikat anfordert. Dies wird von höheren Zertifizierungsstellen durchgeführt - von bedingten Personen, an die jeder glaubt. Um ein Zertifikat auszustellen, müssen Sie eine CSR (Certificate Signing Request, eine Anfrage für ein Zertifikat) erstellen.



Dies ist auch eine Struktur, mit der es ziemlich schwierig ist, zu arbeiten, da es nur wenige Dienste gibt, mit denen Sie alles festlegen, angeben, überprüfen und anzeigen können.

Insgesamt generieren wir ein Paar öffentlicher Schlüssel: private Schlüssel, aber wir geben nur die öffentlichen und verbergen die privaten. Anschließend generieren wir eine Zertifikatsignierungsanforderung und signieren sie mit unserem privaten Schlüssel. Wir senden dies alles an die Zertifizierungsstelle und sie startet die Überprüfung. Es kann anders sein, für besonders coole Zertifikate gibt es spezielle knifflige Verfahren, aber wir werden uns mit dem allgemeinen Fall befassen.

CAA RR



Es gibt ein solches Problem, dass Menschen, von denen jeder glaubt, dass sie manchmal nicht sehr gut sind. Einer der Gründe, warum Symantec Teil von DigiCert geworden ist, ist, dass Symantec Zertifikate ausgestellt hat, ohne die Domaininhaber zu fragen. Sie können dies nicht tun, es war eine Beleidigung für alle, vor allem aber für Symantec selbst, weil Sie Ihr Unternehmen verkaufen mussten. Um den Server weniger abhängig von solchen skrupellosen Kameraden zu machen, gibt es so etwas wie CAA RR - einen Eintrag in DNS, der angibt, wer der Eigentümer zulässt, Zertifikate für seine Domain auszustellen. Diese Funktion ist auch in Plesk verfügbar. Sie wird bisher nur wenig verwendet, ungefähr wie DNSSec, aber dennoch. Alle Zertifizierungsstellen haben zugestimmt, diesen Eintrag zu überprüfen. Wenn angegeben wird, dass diese Zertifizierungsstelle nicht ausgestellt werden kann, heißt es: "Sie haben die Validierung nicht bestanden, sie ist in CAA RR geschrieben."dass ich kein Zertifikat für Sie ausschreiben kann “- und es nicht ausschreiben wird. Wenn es keinen Eintrag gibt, können Sie. Jetzt drängt Google auf die Initiative, damit Kunden das erhaltene Zertifikat auf Übereinstimmung mit CAA RR-Datensätzen überprüfen. Die Debatte dauert noch an.

Außerdem wurde CAA RR von dem Moment an, als wir die Unterstützung in Plesk vorgenommen haben, erweitert, indem Validierungsmethoden (dh Sie können hier auch angeben, mit welcher Methode Sie überprüfen, ob diese Domain Ihnen gehört) und Konto-URI (Uniform Resource Identifier) ​​angegeben wurden. Beliebt bei Benutzern Plesk Let's Encrypt unterstützt dies bereits (gut gemacht!).

All dies funktioniert für jede Art von Zertifikat, und da wir später über die Unterschiede sprechen werden, ist es Zeit, die Typen genauer zu besprechen.

Zertifikatstypen


Es gibt drei davon:

Domain-Validierung


Das Thema ist eine Domain, das heißt, hier überprüfen wir nur es. Früher, als es keine automatischen Validatoren gab, erfolgte die Validierung hauptsächlich per E-Mail über den Whois-Dienst. Dies wurde als ausreichender Grund für die Annahme angesehen, dass Sie der Eigentümer dieser Domain sind. Dann haben sie sich überlegt, ob sie über DNS nachsehen sollen - sie haben Ihnen per E-Mail geschrieben: „und so und so einen Eintrag zu DNS hinzufügen“. Später erschienen automatische Methoden (wir werden etwas weiter über ACME sprechen).

Organisationsvalidierung


Im Feld "Betreff" wird neben dem Domainnamen auch der Name der Organisation angegeben. Die Prüfung besteht darin, zu überprüfen, ob die Domain zu dieser Organisation gehört und ob die Person, die das Zertifikat erhalten hat, dort arbeitet. Wie das gemacht wird: Sie suchen nach Organisationen in den Registern, rufen an, fordern etwas zu tun (das Telefon hat sich als richtig herausgestellt, die richtige Person hat geantwortet, was bedeutet, dass höchstwahrscheinlich alles in Ordnung ist).

Erweiterte Validierung


Wie OV, nur kühler. Hier ist alles sehr geregelt - ein 40-seitiges Dokument im Sinne von "in Absatz 5.6.8 sollte wie folgt lauten: ..." usw. Viele Dinge werden überprüft - das Land, die Abteilung (falls im Antrag angegeben) und manchmal geht sogar eine besondere Person, um mit den Augen zu sehen. Was ist der praktische Unterschied? Fast alle Browser haben aufgehört, zwischen OV und DV zu unterscheiden, und dies ist schlecht, da in diesem Fall der Name der Organisation nicht angezeigt wird. Infolgedessen stört es niemanden, eine Domain aliepxress.ru zu erstellen, dieselbe Seite zu zeichnen und Kreditkarten zu stehlen. Und es ist absolut legitim, eine solche Domain zu erstellen und ein DV-Zertifikat darauf zu erhalten.

Beispiel mit EV - der Name der Organisation ist hier sichtbar. Wenn also jemand etwas stiehlt, weiß der Benutzer, dass es sich um eine Valve Corp-Gesellschaft handelt, und die Registrierung der Organisation ist etwas schwieriger als die Domain (mehr Überprüfungen).



Alles geht jedoch bis zu dem Punkt, an dem EV nicht mehr anders ist. Auf Mobilgeräten ist es nicht mehr sichtbar und Sie müssen eine separate Taste drücken, und dies auch in Safari. Google Chrome hält noch (UPD - nicht mehr! Ich musste einen Bildschirm aus dem IE erstellen). Die Argumentation derer, die nicht zeigen: "Wenn Sie besorgt sind, klicken und schauen", aber niemand drückt natürlich.

Zertifikat erhalten: Automatisierung


Lassen Sie uns nun über den automatisierten Empfang von DV-Zertifikaten sprechen. Lassen Sie uns der Klarheit halber sehen, wie unser Lieblings-Let's Encrypt das macht. Er hat im Allgemeinen eine gute Dokumentation, wenn jemand interessiert ist, und sogar in Russisch.

GIPFEL


ACME (Automatic Certificate Management Environment) ist ein Protokoll zur Automatisierung und Standardisierung des Prozesses zum Abrufen eines Zertifikats.

Wie beweist ACME, dass Sie Domaininhaber sind? Sie sagen: Ich möchte ein Zertifikat und geben die Art der automatischen Validierung an - zum Beispiel ACME HTTP-01. Let's Encrypt fordert Sie auf, die Daten in eine Datei einzufügen. Wenn Sie die Dateien in Ihre Domain einfügen könnten (und Let's Encrypt sie über HTTP von dort abholen könnte), sind Sie wahrscheinlich deren Eigentümer. Jetzt wird dieser Ansatz kritisiert, auch von Google, weil er nicht vor Phishing schützt. Das heißt, bei manueller Validierung wird die Domäne aliepxress.ru wahrscheinlich Verdacht erregen, aber Let's Encrypt selbst weiß bisher nicht, wie (oder kann es, aber schlecht).

DNS-Herausforderung


Neben ACME gibt es auch eine DNS-Herausforderung. Zum Beispiel sagen sie Ihnen: Geben Sie einen TXT-Eintrag in Ihre DNS-Zone ein und geben Sie die Daten ein. Es gibt andere Wege, aber nicht üblich, und einer wurde insgesamt abgesagt, weil er sich als verletzlich herausstellte. Was wir in Plesk haben: Platzhalterzertifikate (die nur mit der DNS-Herausforderung ausgeschrieben werden können) funktionieren für viele Menschen nicht, da Plesk die DNS-Zonen und die Erweiterung der Domain sehr oft nicht verwaltet. Let's Encrypt kann die Erstellung eines Eintrags in der DNS-Zone nicht automatisieren .

Noch zwei Worte zu Let's Encrypt


Ein wichtiger Aspekt bei der Arbeit mit Let's Encrypt-Zertifikaten sind Grenzwerte. Im Zweifelsfall (oder im Verdacht, dass sie erreicht wurden) folgen Sie am besten dem Link: letsencrypt.org/docs/rate-limits

Manchmal werden sie aktualisiert. Es gibt nicht offensichtliche Grenzen, die die Leute vergessen: Nach Supportanfragen sind sie meistens mit einer Grenze von 100 Domain-Namen im Zertifikat konfrontiert. Let's Encrypt verfügt auch über einen Staging-Server und es gibt weitere Einschränkungen. Solche Zertifikate gelten jedoch als nicht vertrauenswürdig und ähneln für den Browser selbstsignierten Zertifikaten. In der Praxis kommen sie mit einem Limit von 100 Namen selten zu uns (trotz der Tatsache, dass Websites auf Plesk insgesamt 1.300.000 Let's Encrypt-Zertifikate haben). Der Median liegt laut Statistik bei 20 Namen pro Zertifikat. Wenn also etwas nicht funktioniert, schauen Sie - vielleicht ist das Limit erreicht. Let's Encrypt hat eine gute Fehlerberichterstattung, und Sie können normalerweise verstehen, was passiert ist.

Was weiter?


Nachdem das Zertifikat empfangen wurde, überträgt der Server die Sitzungsschlüsseldaten - dies wird für die Verschlüsselung verwendet. Wenn der Server der Ansicht ist, dass eine Authentifizierung des Clients erforderlich ist (der Zugriff steht beispielsweise nur einem bestimmten Personenkreis offen), kann er fragen: Der Client, wer sind Sie? Und dann muss der Kunde sein Zertifikat senden. Nach dem Empfang der ServerHelloDone- Nachricht erkennt der Client, dass es Zeit ist, die Zertifikate zu überprüfen und mit den Schlüsseln zu arbeiten.

Alles, worüber wir gesprochen haben, bevor TLS 1.3 über einen offenen Kanal läuft, und jeder kann all diese Dinge sehen. Es gibt mehrere interessante Angriffe, die Sie über sich selbst lesen können.
In der zweiten Reihe des Artikels erfahren Sie, wie der Client das Zertifikat überprüft.

More articles:


All Articles