MIT-Kurs "Computer Systems Security". Vorlesung 13: Netzwerkprotokolle, Teil 3

Massachusetts Institute of Technology. Vorlesung # 6.858. "Sicherheit von Computersystemen." Nikolai Zeldovich, James Mickens. 2014 Jahr

Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitstechniken, die auf jüngsten wissenschaftlichen Arbeiten basieren. Zu den Themen gehören Betriebssystemsicherheit, Funktionen, Informationsflussmanagement, Sprachsicherheit, Netzwerkprotokolle, Hardwaresicherheit und Sicherheit von Webanwendungen.

Vorlesung 1: „Einführung: Bedrohungsmodelle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 2: „Kontrolle von Hackerangriffen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 3: „Pufferüberläufe: Exploits und Schutz“ Teil 1 / Teil 2 / Teil 3
Vorlesung 4: „Trennung von Privilegien“ Teil 1 / Teil 2 / Teil 3
Vorlesung 5: „Woher kommen Sicherheitssysteme?“ Teil 1 / Teil 2
Vorlesung 6: „Chancen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 7: „Native Client Sandbox“ Teil 1 / Teil 2 / Teil 3
Vorlesung 8: „Netzwerksicherheitsmodell“ Teil 1 / Teil 2 / Teil 3
Vorlesung 9: „Sicherheit von Webanwendungen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 10: „Symbolische Ausführung“ Teil 1 / Teil 2 / Teil 3
Vorlesung 11: „Ur / Web-Programmiersprache“ Teil 1 / Teil 2 / Teil 3
Vorlesung 12: Netzwerksicherheit Teil 1 / Teil 2 / Teil 3
Vorlesung 13: „Netzwerkprotokolle“ Teil 1 / Teil 2 / Teil 3

Angenommen, ein Client gibt eine Anfrage zum Empfang einer bestimmten Nachricht aus, z. B. "Geben Sie mir die Nachricht Nr. 7", und verschlüsseln Sie diese Sache mit dem Schlüssel Kc, mail. Alles scheint wunderbar zu sein.
Der Mailserver verfügt über einen gemeinsam genutzten Schlüssel, der diese Nachricht entschlüsselt. Anschließend sendet der Server den Text dieser E-Mail-Nachricht, die ebenfalls mit Kc-Mail verschlüsselt ist, an den Client zurück. Betrachtet jemand dies als Problem? Warum kann das schlecht sein?



Student: Es besteht die Möglichkeit, dass ein Hacker eine Nachricht ersetzen oder fälschen kann.

Professor: Ja, das ist beunruhigend, weil ich Ihnen jede gewünschte E-Mail senden kann. Angenommen, ich möchte eine Nachricht in Ihrem Posteingang löschen, weil ich nicht möchte, dass Sie sie lesen. Angenommen, dieser Brief befindet sich unter Nummer 23.

Deshalb werde ich Ihnen einen Brief schicken, in dem steht: "Nr. 23 löschen", und Sie werden ihn lesen. Sie werden es erhalten, und die Antwort vom Mailserver mit dem Befehl "Löschen Nr. 23" wird mit diesem Schlüssel Kc, mail verschlüsselt. Und bisher wurde es nicht an den Mailserver gesendet.

Wenn ich das Netzwerk jedoch zum richtigen Zeitpunkt scanne und dieses Paket festschreibe, kann ich es an den Mailserver zurücksenden. Es sieht aus wie die Meldung "Nr. 23 löschen", die mit dem Schlüssel verschlüsselt wurde. In diesem Fall sagt der Mailserver: "Oh ja, natürlich möchten Sie diese Nachricht löschen, und ich werde es tun!"

Hier liegt also ein Problem vor, da wir dem Gegner erlauben, den Mailserver zu verwirren, ob unsere Nachricht von ihm generiert oder überhaupt an ihn gesendet wurde.

Dies wird in Kryptografie- und Protokollbeschreibungen häufig als „Reflexionsangriff“ bezeichnet. Haben Sie Vorschläge, wie Sie dieses Problem vermeiden können?

Student: Ist es möglich, einfach eine Nachrichtenüberschrift einzufügen, die von ihrem Ursprung spricht?

Professor: Ja, in der Regel möchten Sie eine eindeutige Möglichkeit haben, festzustellen, was passiert. Eine Möglichkeit besteht darin, in jeder Nachricht einen Header zu haben, der besagt: "von Client zu Server" oder "von Server zu Client". In der Praxis ist es sogar noch besser, zwei separate Schlüssel zu verwenden.

Möglicherweise möchten Sie einen langen Datenstrom haben, der möglicherweise keinen Platz für Header-Bits bietet. Daher handelt Kerberos 5 jedes Mal, wenn Sie eine Verbindung mit einem Dienst herstellen, die Verwendung von zwei Schlüsseln anstelle von einem aus. Der erste Schlüssel wird zum Verschlüsseln von Daten vom Client zum Server und der zweite zum Verschlüsseln von Daten vom Server zurück zum Client verwendet. Dies ist die optimalste Schutzmethode für den praktischen Gebrauch.

Lassen Sie uns jetzt darüber sprechen, was mit KDC passiert. Der Kerberos-Server ist für das System sehr wichtig. Was passiert jedoch, wenn dieses KDC abstürzt? Wie schlimm ist das für unser System? Wie wird sich der „Fall“ von KDC auf Ihr Leben auswirken, wenn Sie Athena verwenden?

Student: Sie können sich wahrscheinlich nicht anmelden?

Professor: Ja, das ist es. Zweitens können Sie auch keine Tickets für neue Anfragen erhalten. Aber das Coole ist, dass KDC so ziemlich außerhalb des kritischen Pfades für eine bestehende Verbindung liegt. Daher werden keine Daten durch das KDC geleitet. Und wenn Sie bereits ein Ticket für etwas haben, können Sie es weiterhin verwenden und den Zugang zu einigen Netzwerkdiensten behalten. Dies ist eigentlich ziemlich gut zwischengespeichert. Ich denke, das zweite gute, was sich die Entwickler vorgestellt haben, ist das Potenzial, KDC zu replizieren. Daher verfügt das System über einen Kerberos-Hauptserver, auf dem die erste Kopie der gesamten Datenbank gespeichert ist. Auf diese Weise können Sie nur Replikate lesen, die eine Kopie der ursprünglichen Datenbank enthalten. Es sind keine Aktualisierungen wie Benutzerregistrierung oder Schlüsselaktualisierungen zulässig, Sie können jedoch auf Anmelde- und TGS-Anforderungen antworten.

Mit dem "Klon" -Datensatz der Kerberos-Datenbank können Sie sich weiterhin anmelden und mit Diensten kommunizieren, auch wenn KDC fehlschlägt, bis er entfernt und seine volle Funktionalität wiederhergestellt wird.

Student: Wie schwierig ist es, den KDC-Server und das gesamte System zu gefährden?

Professor: KDC ist das Rückgrat jedes Systems, auf dem Kerberos ausgeführt wird. Wenn dieser Dienst gefährdet ist, erhält der Angreifer die vollständige Kontrolle über das System. Er kann Tickets für jeden gewünschten Service bekommen und gibt vor, der richtige Kunde zu sein, also ist es ziemlich schlecht. Wir wollen KDC wirklich schützen, aber es ist schwer. Obwohl ich keinen einzigen Fall kenne, in dem das KDC MIT seit etwa 20 Jahren wirklich kompromittiert worden wäre. Aber was es wirklich wert ist, sich Sorgen zu machen, ist die Software-Implementierung der Sicherheit der Dinge, die diese beiden Dienste austauschen, Kerberos und TGS. Denn wenn in ihnen ein Pufferüberlauf auftritt oder eine andere ähnliche Sicherheitsanfälligkeit auftritt, ist dies wirklich schlimm.



Wenn beispielsweise ein SSH-Server unter KDC Kerberos ausgeführt wird und jemand das Root-Passwort dieses SSH-Servers errät, meldet er sich einfach an und kopiert die Datenbank. Ich denke also, dass Sie die Angriffsfläche hier wirklich minimieren möchten. Seien Sie also sehr vorsichtig, wenn Sie KDC-Code schreiben. Lassen Sie niemanden direkt auf diesen Dienst zugreifen. Natürlich gibt es einige Orte, für die Sie in Bezug auf Sicherheit als paranoid gelten sollten, aber dies ist für Server nicht so wichtig. Natürlich speichern sie Daten, aber wenn jemand in einen Mailserver oder Druckserver einbricht, können sie wiederhergestellt werden.

Hier ist eine interessante Frage. Angenommen, jemand hat einen Mailserver gehackt. Was sollten Sie tun, um sich von diesem Angriff zu erholen? Wenn zum Beispiel jemand Ihre Mail gestohlen hat, ist dies schlecht. Aber was sollte getan werden, um zu verhindern, dass ein Angreifer in Zukunft Zugriff auf Ihre E-Mails erhält?

Kerberos verfügt nicht über einen Abbruchvorgang. Sie können jedoch einen neuen Schlüssel für den Mailserver generieren und in die KDC-Datenbank einfügen. Dann installieren Sie einen neuen Mailserver, geben ihm einen neuen Schlüssel, und ein Angreifer, der einen alten Schlüssel vom Mailserver hat, kann ihn in keiner Weise beeinflussen.

Angenommen, Sie ändern den Schlüssel des Mailservers Kmail nicht. Was wird es führen?



Student: Der Schlüssel passt nicht auf den neuen Server.

Professor: Angenommen, Sie installieren einen neuen Mailserver, um den vom Hacker verwendeten Fehler zu beheben. Aber er hat immer noch einen Kmail-Schlüssel. Möglicherweise dauerte die Serverwiederherstellung einen ganzen Tag, sodass alle Tickets abgelaufen waren. Kann dieser Hacker etwas Interessantes mit dem System machen? Wenn Sie dem neuen Mailserver altes Kmail zur Verfügung stellen - ist das schlecht?

Student: Ein Angreifer kann einen Mailserver infiltrieren, weil er das erste Ticket entschlüsseln kann.

Professor: Natürlich ist Kmail deshalb sehr wichtig. Sie sagen, dass Sie alles entschlüsseln können, was auf dem Mailserver passiert. Angenommen, der Client stellt nach dem Reparieren eine Verbindung zum Mailserver her, aber der Angreifer kennt Kmail weiterhin, das seit dem letzten Hacken des Systems erhalten geblieben ist. Daher kann er dieses Kmail-Ticket entschlüsseln, in das Ticket schauen und einen Sitzungsschlüssel erhalten. Damit kann er alle von Ihnen gesendeten Nachrichten, alle erhaltenen Antworten usw. entschlüsseln. Daher ist es nach dem Wiederherstellen des Mailservers sehr wichtig, dieses Kmail zu ändern.

In vielerlei Hinsicht ist dies sogar noch schlimmer als nur das Verfolgen des Datenverkehrs. Wenn ein Angreifer diesen Kmail-Schlüssel kennt, kann er neue Tickets für den Mailserver synthetisieren, ohne KDC zu kontaktieren. Angenommen, ich kenne Kmail und möchte E-Mails von einem Mailserver lesen. Ich werde nur dieses Ticket ausstellen, alle fünf Felder in der richtigen Reihenfolge sammeln, einen neuen Schlüssel generieren und ihn mit Kmail verschlüsseln. Es wird wie die reale Sache aussehen, die von KDC erzeugt wird.

Daher stelle ich nur eine Verbindung zum Mailserver her, der die Nachricht korrekt entschlüsselt und denkt, dass es sich um einen bestimmten Benutzer handelt, sodass Sie ihm E-Mails bereitstellen, einen freigegebenen Schlüssel für ihn freigeben können usw. Daher ist es wichtig, dass niemand den geheimen Schlüssel dieses Dienstes erkennt, da Sie sonst den Datenverkehr nicht nur entschlüsselbar und sichtbar machen, sondern auch jeden in diesem Dienst nachahmen können.

Student: Wenn der Mailserver nach einem Fehler wiederhergestellt wird, müssen Sie wahrscheinlich seinen Schlüssel in der Datenbank ändern?

Professor: Ja, nachdem Sie den Mailserver nach dem Fehler wiederhergestellt haben, müssen Sie den Mitarbeiter anrufen, der mit diesem KDC arbeitet, und sagen: "Unser Mailserver wurde gehackt. Löschen Sie also seinen alten Ks-Schlüssel aus der Datenbank und fügen Sie einen neuen ein!" Sie möchten also wahrscheinlich einen Mechanismus außerhalb der Datenbank haben, um zu beweisen, dass Sie wirklich ein Mailserver sind.

Denn wir werden gleich sehen, wie Sie Schlüssel ändern, beispielsweise mithilfe des Kennwortänderungsprotokolls. Sie können Kennwörter im Kerberos-Protokoll verwenden. Wenn Sie das alte Kennwort kennen, können Sie das Benutzerkennwort in KDC in das neue Kennwort ändern. Da der Hacker das per E-Mail gesendete Passwort abfangen kann, müssen Sie sich wahrscheinlich an das Kontoregistrierungsbüro wenden und ihn bitten, Ihr Passwort für den Mailserver zu ändern. Sie generieren einen neuen Schlüssel und geben ihn Ihnen, damit der Hacker ihn nicht erkennen kann.



Wenn der Angreifer diesen Kmail-Schlüssel kennt, kann der Mailserver den Angreifer nicht vom richtigen Client unterscheiden. In Wirklichkeit hat der Angreifer wahrscheinlich den Schlüssel geändert, sodass er jetzt die neuen Parameter kennt und Sie nicht da sind, als wären Sie nicht mehr auf dem Mailserver. Sie benötigen also externe Protokolle für die Grundsätze der Erstregistrierung in der Datenbank und zum Ändern von Schlüsseln, wenn Sie Ihr Passwort vergessen haben oder jemand Ihr Passwort geändert hat, sodass Sie den Zugriff verloren haben.

Daher gibt es am MIT eine Gruppe von Personen, die Benutzern helfen, Konten zu registrieren und ihre Passwörter zu ändern. Dazu legen Sie ihnen Ihre MIT-ID vor, und egal was passiert, sie können den Schlüssel für Sie ändern.

Daher ist es sehr wichtig, es richtig zu machen. Denn wenn die Person, mit der Sie das Passwort zurücksetzen können, beim Überprüfen Ihrer MIT-ID einen Fehler macht, können Sie das System gefährden, oder? Diese Mitarbeiter bei Kerberos sind also Teil einer vertrauenswürdigen Computerbasis.

Schauen wir uns eine weitere interessante Verwendung von Kerberos an. Mit Kerberos können Sie sich über SSH bei einem Remotecomputer anmelden. Die Funktionsweise ist der Arbeit mit einem Mailserver sehr ähnlich. Sie erhalten ein Ticket für den SSH-Server und senden das Ticket zusammen mit Ihrer SSH-Verbindung. Aber was ist, wenn Sie eine Verbindung zu Athena.dial-up herstellen und keinen Kerberos-Client auf Ihrem Computer haben? Sie möchten sich nur mit Ihrem regulären Passwort bei Athena.dial-up anmelden.

Wie authentifiziert Sie die Athena-Einwahl, wenn Sie nur mit einem Kennwort eine Verbindung zu diesem Computer herstellen? Sie haben kein Passwort für Athena.dial-up, es ist ein Passwort für den Kerberos-Server. Was sollte ein DFÜ-Computer tun, wenn Sie sich mit einem Kennwort anmelden?

Einwahl Die Einwahl funktioniert mit demselben Protokoll wie die Anmeldung. Also wird er eine Anfrage vom Client an den Kerberos-Server senden, mit der Bitte, ein Ticket zu geben, zum Beispiel an den Benutzernamen "Alice". Und zurück erhält der Client eine Antwort, die mit Alices Passwort verschlüsselt ist. Dann wird er versuchen, das Passwort anzuwenden und zu sehen, ob er richtig entschlüsselt. Wenn es korrekt entschlüsselt wird, können Sie sich beim System anmelden.

Student: Sie müssen Ihren Schlüssel nicht einmal an den SSH-Server senden, da in dieser Verbindung der KDS-Server den Kc-Benutzer über die SSH-Verbindung zurücksenden kann.

Professor: Es ist möglich, dass ja, aber es erfordert eine gewisse Vorstellungskraft des SSH-Clients, was möglicherweise nicht der Fall ist. Aber im Prinzip ist das wahr. Wenn Sie dies korrekt ausführen möchten, möchten Sie wahrscheinlich einen Kerberos-Client auf Ihrem Computer haben und selbst ein Ticket erhalten oder einen SSH-Server für die Weiterleitung verwenden, ohne dass der SSH-Server über Ihren Schlüssel verfügt.

Dies ist wahrscheinlich ein guter Plan. Es stellt sich jedoch heraus, dass dies eine ziemlich gefährliche Sache ist, die es jedem ermöglicht, sich beim SSH-Server anzumelden. Früher haben wir über einen Client gesprochen, der versucht, sich anzumelden. Dieser Client wusste, dass er durch die Angabe eines legalen Passworts eine Antwort vom richtigen Kerberos-Server erhalten hat. Wenn er die Antwort entschlüsseln kann, funktioniert das Passwort wahrscheinlich korrekt.

Dieses Protokoll enthält jedoch nichts, was die Tatsache bestätigt, dass diese Antwort vom richtigen Kerberos-Server stammt. Wenn ich versuche, mich einfach durch Eingabe eines Kennworts am Computer anzumelden, sendet der Computer diese Anforderung an den Server. Anschließend wird die Antwort auf diese Anforderung zurückgegeben, die mit dem von mir eingegebenen Kennwort verschlüsselt zu sein scheint. Diese Antwort stammt jedoch möglicherweise auch nicht vom Kerberos-Server.

Angenommen, ich habe einen Computer, mit dem ich mich anmelden möchte. Ich gebe das Passwort X ein und dann sendet der Computer diese Anfrage von, s an den Kerberos-Server.



Bevor der Kerberos-Server die echte Antwort an den Client sendet, sende ich meine eigene Antwort, die wie die echte Antwort aussieht und mit meinem X-Passwort verschlüsselt ist. Anschließend versucht die Workstation, bei der ich mich anmelden möchte, oder der SSH-Server, diese Antwort mit meinem falschen Passwort zu entschlüsseln. Dies wird gut aussehen, da diese Antwort von mir anstelle des echten Kerberos-Servers generiert wurde. Daher kann ich mich anstelle von Ihnen anmelden. Warum passiert das?

Student: weil keine Authentifizierung vom Kerberos-Server erfolgt.

Professor: Ja, hier gibt es nichts, was dies mit einem echten Kerberos-Server verbinden könnte. Kerberos korrigiert diese Unannehmlichkeit für Remotecomputer wie Athena.dial-up, indem DFÜ-Computer selbst über eine Art geheimen Schlüssel verfügen, den sie mit KDC teilen. Um die Einwahl oder eine Workstation zu betreten, bei der es wirklich darum geht, zu überprüfen, ob Sie wirklich der richtige Benutzer sind, werden zwei Dinge getan.

Die erste Anmeldung bei Kerberos erfolgt wie in der Abbildung gezeigt. Aber er wird niemandem vertrauen, nur weil diese Antwort richtig entschlüsselt ist. Er wird versuchen, mit TGS ein Serviceticket für sich selbst zu bekommen, da dieser DFÜ-Computer über einen eigenen geheimen Schlüssel verfügt. In der ersten Phase registriert er Sie einfach und wendet sich dann an TGS. Er sagt: "Bitte geben Sie mir ein Serviceticket nach meinem eigenen Prinzip auf der Grundlage der Einwahl für diesen Kunden."

Dann erhält er eine Antwort und prüft, ob er sie korrekt entschlüsseln kann, da er den Einwahlschlüssel für diesen Ks kennt. Wenn es entschlüsselt wird, bedeutet dies, dass der Computer mit dem richtigen Kerberos-Server gesprochen hat. Weil nur der richtige Kerberos-Server in der zweiten Stufe mir ein Ticket senden kann, das mit meinem geheimen Kdial-up-Schlüssel verschlüsselt ist.

Das ist also eigentlich sehr wichtig. In der Regel führen Athena-Workstations diesen zusätzlichen Schritt nicht aus, da Athena-Workstations keinen geheimen Schlüssel haben, der auf ihnen gespeichert und mit KDC geteilt wird. Warum wird es für Athena-Workstations als normal angesehen, Ihnen die Möglichkeit zu geben, sich in der ersten Phase anzumelden, aber keine solche Möglichkeit zur Einwahl zu geben?

Student: Dies ist normal, wenn Sie keinen Zugriff auf Dienste haben, da der Angreifer kein Ticket fälschen konnte.

Professor: Ja, das stimmt, denn an der DFÜ-Workstation selbst ist nichts Interessantes. Selbst wenn Sie Root-Zugriff haben oder eine Workstation mit einem falschen Passwort eingeben, stört dies niemanden. Es ist nicht so, als könnten sie etwas anderes außerhalb ihrer Workstation tun. Bei der Einwahl ist alles viel interessanter. Möglicherweise haben Sie andere Prozesse, die von anderen Sitzungen auf der DFÜ-Workstation ausgeführt werden, und die Tatsache, dass Sie mit einer Unix-spezifischen UID angemeldet sind und wirklich sicherstellen möchten, dass Sie die richtige Entität sind, sind dort wichtig. . Aus diesem Grund führen sie einen solchen zweistufigen Prozess durch, um in die Maschine zu gelangen, die gleichzeitig von mehreren Benutzern verwendet wird.

Das Letzte, worüber ich sprechen möchte, ist, wie wir Schlüssel ersetzen. Wir haben die Idee vertreten, dass Sie den Mailserverschlüssel gefährden können. Aber als Benutzer möchten Sie wahrscheinlich auch das Passwort ändern. Sie dachten beispielsweise, Ihr Passwort sei nicht sicher genug, Sie haben es auf ein Blatt Papier geschrieben, und jemand hat es möglicherweise ausspioniert. Jetzt möchten Sie es ändern.

In gewisser Hinsicht ist es ganz einfach. Zusätzlich zu den Kerberos- und TGS-Diensten verfügt die Kerberos-Serverschnittstelle über einen zusätzlichen Dienst namens Kpassword, mit dem Sie Ihr Kennwort ändern können.



Sie erhalten ein Ticket für die Nutzung dieses Dienstes wie ein Ticket für einen Mailserver oder einen anderen Server. Danach senden Sie Ihr neues Passwort an diesen Kpassword-Dienst, verschlüsselt mit Ihrem Sitzungsschlüssel. Wenn dann alle Prüfungen bestanden sind, wird Ihr Schlüssel in der Datenbank mit einem neuen Schlüssel aktualisiert.

Wenn Sie sich erinnern, hatten wir ein Ziel: Wenn jemand Ihr Ticket stiehlt, sollte er nicht gut genug sein, um die Möglichkeit zu geben, Ihr Konto vollständig zu erfassen. Aus diesem Grund akzeptiert der Kpassword-Dienst kein Ticket, sondern nur das Ticket, das Sie ursprünglich vom Kerberos-Dienst mit Ihrem Kc-Schlüssel erhalten. : , , , , – Kerberos TGS – . : Kerberos, , TGS, .
Kpassword, , , : «, Kerberos, . TGS, , , , - , . ».

, Kpassword , , , Kerberos. , Kpassword , Kerberos Kpassword.

Kpassword, - . , , Kerberos. Kerberos, ID , Kpassword.



Kerberos , Kpassword, Kpass, Kc,kpass Kpassword, Kc.

, – Kpassword, Tc,kpass, Kpass, , new pass Kc,pass, .

, , , , . - Athena, , , , . , , Gmail, , . , Kerberos TGS , - , .

, - Athena , , , . , . , . Tc,kpass, Kpassword, TGS, . , Kerberos Kc.

: , ?

: K . Kerberos , . , K. - K, .

: , ?

: , - , , . .

, , , , , , .

: , , .

: , , . , , Kerberos , , . , . . , , .

: K, ?

: , K – 56- DES, , , 56 , , 7 , . .

, , . , , , , . Kerberos?



: …

: , , , , , , . ?

: .

: , .

: - , , , , …

: , , Kerberos , , , . . , , , «» - , ! : „, Kc,pass, K. Kc,pass , Kpassword». , , KDC. , .
, , - , - . .

: , Kerberos ?

: , . « -», , , . , .

, Kerberos 5. , , , . , . , X, Kpassword - Y. , , . , g X , g Y.



gy X, gxy, gx Y gxy. gxy , . , , gxy. , , - gxy, . , .

: - G.

:ja natürlich. G ist ein Parameter, den Sie zu Beginn des Protokolls oder im Voraus senden können, um ihn in Kerberos zu platzieren. Dies ist nicht allzu wichtig. Wenn Sie das Diffie-Hellman-Austauschverschlüsselungsprotokoll verwenden, macht Kerberos 5 es auf jeden Fall richtig. Sie müssen jedoch über die Existenz dieses Protokolls Bescheid wissen, wenn Sie ein eigenes neues Protokoll entwickeln. Das ist alles, was ich über Kerberos sprechen wollte, und am Montag wollen wir über SSL sprechen.


Die Vollversion des Kurses finden Sie hier .

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden empfehlen, einen Rabatt von 30% für Habr-Benutzer auf ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s von $ 20 oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s bis Dezember kostenlos, wenn Sie für einen Zeitraum von sechs Monaten bezahlen, können Sie hier bestellen.

Dell R730xd 2 mal günstiger? Nur wir haben 2 x Intel Dodeca-Core Xeon E5-2650v4 128 GB DDR4 6 x 480 GB SSD 1 Gbit / s 100 TV von 249 US-Dollar in den Niederlanden und den USA! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?