MIT-Kurs "Computer Systems Security". Vorlesung 14: „SSL und HTTPS“, Teil 1

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
Vorlesung 14: „SSL und HTTPS“ Teil 1 / Teil 2 / Teil 3

Nun werden wir untersuchen, wie kryptografische Protokolle zum Schutz von Netzwerkverbindungen im Internet verwendet werden und wie sie im Allgemeinen mit Netzwerkfaktoren interagieren. Bevor wir ins Detail gehen, möchte ich Sie daran erinnern, dass es am Mittwoch einen Test geben wird, aber nicht in diesem Publikum, sondern in Walker im 3. Stock während einer regulären Vorlesungszeit.



Daher werden wir heute darüber sprechen, wie das Internet Kryptografie zum Schutz einer Netzwerkverbindung verwendet, und zwei eng verwandte Themen betrachten.

Das erste ist, wie Verbindungen in größerem Maßstab kryptografisch gesichert werden können, als das Kerberos-System, das wir in der letzten Vorlesung behandelt haben, schützt. Die zweite Möglichkeit besteht darin, diesen auf Netzwerkebene bereitgestellten kryptografischen Schutz in die gesamte Anwendung zu integrieren und die Verwendung des durch das kryptografische Protokoll bereitgestellten Schutzes durch den Webbrowser zu gewährleisten. Diese Themen sind eng miteinander verbunden, sodass sich herausstellt, dass der Schutz der Netzwerkkommunikation recht einfach ist, da die Kryptografie immer funktioniert. Die Integration in den Browser ist jedoch viel schwieriger als der Aufbau eines Systems rund um die Kryptografie.

Bevor wir auf diese Diskussion eingehen, möchte ich Sie an die grundlegenden Elemente der Kryptographie erinnern, die wir verwenden werden.

In unserem letzten Vortrag über Kerberos haben wir symmetrische Kryptographie verwendet, oder
Verschlüsselung und Entschlüsselung. Seine Bedeutung ist, dass Sie einen geheimen Schlüssel K und zwei Funktionen haben. Sie können also einige Daten nehmen, nennen wir es P, dies ist einfacher Text, auf den Sie die Verschlüsselungsfunktion anwenden können, und dies ist die Funktion eines Schlüssels K. Und wenn Sie diesen einfachen Text verschlüsseln, erhalten Sie den verschlüsselten Text C. Ebenso haben wir Es gibt eine Entschlüsselungsfunktion D, die denselben Schlüssel K verwendet, wodurch der verschlüsselte Text C in einfachen Text P umgewandelt wird. Dies ist das Grundelement, um das Kerberos erstellt wurde.



Es stellt sich jedoch heraus, dass es andere Grundelemente gibt, die für die heutige Diskussion nützlich sein werden und die als asymmetrische Ver- und Entschlüsselung bezeichnet werden. Die Idee hier ist, verschiedene Schlüssel für die Ver- und Entschlüsselung zu haben. Mal sehen, warum das so nützlich ist.

Hier gibt es eine Funktion E, die einen bestimmten Satz von Nachrichten P mit einem bestimmten öffentlichen Schlüssel pk verschlüsseln kann, um den verschlüsselten Text C zu erhalten. Um ihn mit der Funktion D zu entschlüsseln, müssen Sie nur den entsprechenden geheimen Schlüssel sk angeben und den Quelltext P erhalten.



Der Vorteil der asymmetrischen Verschlüsselung besteht darin, dass Sie einen öffentlichen Schlüssel im Internet veröffentlichen können und die Benutzer Nachrichten für Sie verschlüsseln können. Sie benötigen jedoch einen geheimen Schlüssel, um ihre Nachrichten zu entschlüsseln. Heute werden wir sehen, wie dies im Protokoll verwendet wird. In der Praxis verwenden Sie die Kryptografie mit öffentlichen Schlüsseln häufig auf etwas andere Weise. Anstatt beispielsweise Nachrichten zu verschlüsseln und zu entschlüsseln, müssen Sie möglicherweise Nachrichten signieren oder überprüfen.

Es stellt sich heraus, dass es sich auf Implementierungsebene um verwandte Vorgänge handelt, auf API-Anwendungsebene jedoch möglicherweise etwas anders. Zum Beispiel können Sie die Nachricht M mit Ihrem geheimen Schlüssel sk signieren und eine Signatur S erhalten. Anschließend können Sie diese Nachricht mit dem entsprechenden öffentlichen Schlüssel pk überprüfen und als Ergebnis ein logisches Flag erhalten, das angibt, ob die Signatur S für die Nachricht M korrekt ist.



Hier sind einige relativ intuitive Garantien, die diese Funktionen bieten. Wenn Sie beispielsweise diese Signatur erhalten haben und sie korrekt überprüft wurde, bedeutet dies, dass sie von jemandem mit dem richtigen geheimen Schlüssel generiert werden musste. Das ist klar?

Versuchen wir dann herauszufinden, wie Netzwerkverbindungen in größerem Umfang als Kerberos geschützt werden können. In Kerberos hatten wir ein ziemlich einfaches Modell, bei dem alle Benutzer und Server eine Verbindung mit dem KDC-Objekt verwendeten, das diese riesige Tabelle mit Benutzern, Diensten und ihren Schlüsseln enthielt. Wenn ein Benutzer mit einem Server sprechen möchte, muss er KDC bitten, das benötigte Ticket basierend auf diesem riesigen Tisch zu erstellen.



Das scheint also ein ziemlich einfaches Modell zu sein. Warum brauchen wir also noch etwas? Warum ist Kerberos nicht gut genug für die Arbeit mit Websites? Warum verwendet das Internet Kerberos nicht ausschließlich zum Sichern aller Verbindungen?

Sie haben richtig geantwortet - denn das einzige KDC sollte allen vertrauen, und das ist schlecht. Sie können Probleme haben, wenn Sie der Meinung sind, dass eine bestimmte Maschine absolut sicher ist.

Vielleicht sind die Leute am MIT bereit, jemandem im lokalen Netzwerk zu vertrauen, der von KDC verwaltet wird, aber nicht jedem im Internet.

Und die Antwort des zweiten Schülers ist ebenfalls richtig - es ist sehr schwierig, eine so große Anzahl von Schlüsseln zu verwalten. Tatsächlich kann es sehr schwierig sein, ein einziges KDC zu erstellen, das eine Milliarde Schlüssel oder zehn Milliarden Schlüssel für alle Menschen auf der Welt verwalten kann. Eine weitere Komplikation bei der Verwendung von Kerberos für das gesamte Internet besteht darin, dass alle Benutzer einen Schlüssel haben müssen oder KDC bekannt sein müssen. Sie können Kerberos in unserem Institut nicht einmal verwenden, um eine Verbindung zu einigen Servern herzustellen, wenn Sie kein Konto in der Kerberos-Datenbank haben. Während für das gesamte Internet zu erwarten ist, dass Sie beim Aufrufen des Computers überhaupt nicht wissen, wer Sie sind, können Sie jedoch die durch Kryptografie geschützte Amazon-Website aufrufen.



Huh?

Es gibt einige andere Dinge, die Sie von einem kryptografischen Protokoll erwarten, und wir werden untersuchen, wie sie in SSL angezeigt werden. Die Schlüsselidee ist jedoch, dass diese Lösung für Kerberos und für SSL oder TLS identisch ist. Sie haben Recht, wenn Sie erwähnen, dass die ursprünglichen Kerberos-Protokolle, über die wir in den Vorlesungsunterlagen gelesen haben, vor langer Zeit entwickelt wurden. Und wenn wir sie für das moderne Internet nutzen wollen, müssen sie etwas ändern. Welche anderen Gedanken haben Sie, warum sollten wir Kerberos nicht verwenden?

Richtig, es gibt ein Problem mit der Skalierung beim Wiederherstellen des Zugriffs und möglicherweise beim Registrieren neuer Benutzer, da Sie persönlich zu einem Kontobüro gehen und dort ein Konto einrichten müssen. Was sonst?

Student: Der Kerberos-Server muss immer online sein.

Professor: Ja, das ist ein weiteres Problem. Wir haben einige Verwaltungsprobleme aufgelistet, aber auf Protokollebene sollte KDC immer online sein, da es tatsächlich als Vermittler für Ihre Interaktionen mit Diensten dient. Dies bedeutet, dass Sie jedes Mal, wenn Sie eine neue Website besuchen, mit KDC sprechen müssen. Erstens wird es ein Engpass in Bezug auf die Leistung sein. Wie andere Arten der Skalierbarkeit führt dieses Prinzip zur Skalierbarkeit der Leistung, während die oben aufgeführten Prinzipien nur zur Skalierbarkeit des Managements führen.



Wie können wir dieses Problem mit diesen Prinzipien lösen? Die Idee ist, die Schlüsselverschlüsselung zu verwenden, um die Verwendung von KDC zu beenden.

Lassen Sie uns zunächst herausfinden, ob Sie eine sichere Verbindung herstellen können, wenn Sie nur einige der öffentlichen Schlüssel der anderen Seite kennen. Und dann werden wir sehen, wie wir die KDC-Version mit öffentlichem Schlüssel mit der Authentifizierung der Parteien in diesem Protokoll verbinden. Wenn Sie KDC nicht verwenden möchten, können Sie mit der Kryptografie mit öffentlichen Schlüsseln Folgendes tun: Finden Sie den öffentlichen Schlüssel des Partners auf der anderen Seite der Verbindung heraus. Wenn ich in Kerberos eine Verbindung zu einem Dateiserver herstellen möchte, kenne ich den öffentlichen Schlüssel des Dateiservers nur von irgendwoher. Als Neuling erhalte ich einen Ausdruck, der besagt, dass der öffentliche Schlüssel des Dateiservers so und so ist, und ich kann ihn zum Herstellen einer Verbindung verwenden.

Sie können die Nachricht einfach für den öffentlichen Schlüssel des Dateiservers verschlüsseln, zu dem Sie eine Verbindung herstellen möchten. Es stellt sich jedoch heraus, dass diese Operationen mit diesen öffentlichen Schlüsseln in der Praxis ziemlich langsam sind. Sie sind mehrere Größenordnungen langsamer als symmetrische Verschlüsselungsschlüssel. In der Praxis möchten Sie daher normalerweise immer auf die Verwendung der öffentlichen Verschlüsselung verzichten.

So könnte ein typisches Protokoll so aussehen. Sie haben A und B, sie möchten kommunizieren, und A kennt den öffentlichen Schlüssel B. Gleichzeitig generiert A eine Art Sitzungsschlüssel S und wählt einfach eine Zufallszahl dafür aus. Dann ist A dabei, S-Sitzungsschlüssel B zu senden, sodass es wie Kerberos aussieht. Wir werden den Sitzungsschlüssel S für B verschlüsseln.

Wenn Sie sich erinnern, brauchten wir in Kerberos ein KDC, weil A den Schlüssel für B nicht kannte oder er ihn nicht kennen durfte, weil es ein Geheimnis ist, das nur B kennen kann. Aber mit einem öffentlichen Schlüssel können Sie dies tun Verschlüsseln Sie sofort das Geheimnis mit diesem öffentlichen Bspk-Schlüssel und senden Sie die Nachricht B. Jetzt kann B diese Nachricht entschlüsseln und sagen: Ich muss diesen geheimen Schlüssel verwenden. Jetzt haben wir einen Kommunikationskanal, in dem alle Nachrichten einfach mit diesem geheimen Schlüssel S verschlüsselt werden.



Dieses Protokoll enthält also einige nützliche Funktionen. Erstens haben wir die Notwendigkeit beseitigt, KDC online zu haben und einen Sitzungsschlüssel für uns zu generieren. Wir könnten einfach die Vertraulichkeit der übertragenen Informationen sicherstellen, wenn eine der Parteien der Verbindung sie generiert und sie dann für die andere Seite verschlüsselt, ohne KDC zu verwenden.

Eine weitere gute Sache ist das Vertrauen, dass nur B von A nach B gesendete Nachrichten lesen kann, da nur B diese Nachricht entschlüsseln kann. Daher muss B den entsprechenden privaten Schlüssel S haben.

Student: Ist es wichtig, wer diesen Schlüssel gibt - Benutzer oder Server?

Professor: vielleicht. Ich denke, es hängt von den Eigenschaften ab, die Sie von diesem Protokoll erwarten. Was ist also, wenn A einen Fehler macht oder die falsche Zufälligkeit verwendet? Der Server, der die Daten zurücksendet, denkt: "Oh, jetzt sind dies die einzigen Daten, die A sehen wird." Dies ist möglicherweise nicht ganz richtig, daher sollten Sie darüber nachdenken. Es gibt mehrere andere Probleme mit diesem Protokoll.

Student: Kann ein Angreifer einen Schlüssel verwenden, um wiederholte Nachrichten zu senden?

Professor: Ja, das Problem kann sein, dass ich diese Nachrichten einfach erneut senden kann und es so aussieht, als wäre es wieder A, die Nachricht B sendet, und so weiter.

Daher besteht die Lösung für dieses Problem normalerweise darin, dass beide Seiten der Verbindung an der Erzeugung von S beteiligt sind, und dies stellt sicher, dass der von uns verwendete Schlüssel „frisch“ ist. Da hier in der Abbildung B tatsächlich nichts generiert, sehen diese Protokollnachrichten jedes Mal gleich aus.

Es kommt normalerweise vor, dass eine Seite eine Zufallszahl wie S wählt und die andere Seite, B, ebenfalls eine Zufallszahl wählt, die normalerweise als Nonce bezeichnet wird. Es gibt zwei Zahlen und einen Schlüssel, der nicht nur von einer Seite ausgewählt wird. Es ist ein Hash, den beide Seiten für die gemeinsame Interaktion ausgewählt haben. Zusätzlich zum Hash können Sie das Diffie-Hellman-Protokoll verwenden, das wir in der letzten Vorlesung untersucht haben. Dank dessen erhalten Sie zuerst Datenschutz. Dies ist komplizierter als das Hashing von zwei Zufallszahlen, die diese beiden Seiten ausgewählt haben. Aber dann erhalten Sie eine so gute Eigenschaft wie den ursprünglichen gemeinsamen geheimen Schlüssel, sodass der Entschlüsselungsschlüssel bei der Übertragung verschlüsselter Daten nicht mehr übertragen werden muss.

Somit können wiederholte Angriffe wie folgt vermieden werden. B erzeugt Nonce und setzt dann den realen geheimen Schlüssel S ', der verwendet wird, um den geheimen Schlüssel S mit dieser Nonce zu hashen. Und natürlich müsste B Nonce an A zurückschicken, um herauszufinden, was passiert, wenn beide sich auf den Schlüssel einigen.



Ein weiteres Problem ist, dass es keine echte Authentifizierung A gibt. A weiß, wer B ist oder zumindest, wer die Daten entschlüsseln kann. Aber B hat keine Ahnung, wer auf der anderen Seite ist, sei es eine Art Gegner, der sich als ein anderer ausgibt, oder jemand anderes. Wie kann dies in der Welt der öffentlichen Schlüssel behoben werden?

Es gibt verschiedene Möglichkeiten, dies zu tun. Eine Möglichkeit besteht darin, diese Nachricht zunächst zu unterschreiben, da wir dieses gute Zeichenprinzip haben. Also könnten wir dies vielleicht mit einem geheimen Schlüssel unterschreiben. Dieses Zeichen enthält lediglich eine Signatur, aber vermutlich weisen Sie sie zu, und Sie geben auch diese Nachricht an.

Dann muss B wissen, dass A ein öffentlicher Schlüssel ist, um die Signatur zu überprüfen. Wenn B jedoch weiß, dass A ein öffentlicher Schlüssel ist, ist B ziemlich sicher, dass A derjenige ist, der diese Nachricht gesendet hat.



Sie können auch auf die Verschlüsselung vertrauen. Vielleicht kann B Nonce zurück an A senden und es mit dem von A bereitgestellten öffentlichen Schlüssel verschlüsseln. Und dann kann nur A Nonce entschlüsseln und den endgültigen Sitzungsschlüssel S 'generieren. Es gibt also ein paar Tricks, die Sie machen könnten. So funktionieren Client-Zertifikate heute in Internetbrowsern.

Daher verfügt A über einen geheimen Schlüssel. Wenn Sie ein persönliches MIT-Zertifikat erhalten, erstellt Ihr Browser einen langlebigen geheimen Schlüssel und erhält ein Zertifikat dafür. Und jedes Mal, wenn Sie eine Anfrage an den Webserver senden, beweisen Sie, dass Sie den geheimen Schlüssel Ihres Benutzerzertifikats kennen, und legen dann den geheimen Schlüssel S für den Rest der Verbindung fest.

Dies sind Probleme, die auf Protokollebene recht einfach behoben werden können. Die Grundlage für all das ist jedoch, dass alle Parteien die öffentlichen Schlüssel des anderen kennen. Wie können Sie den öffentlichen Schlüssel einer Person herausfinden? Angenommen, ich möchte eine Verbindung zu einer Website herstellen, habe eine URL, zu der ich eine Verbindung herstellen möchte, oder einen Hostnamen. Wie kann ich herausfinden, welcher öffentliche Schlüssel dazu passt?

Wenn ich eine Verbindung zum MIT-Server herstelle, um meine Noten anzuzeigen, woher weiß der Server dann, wie mein öffentlicher Schlüssel aussehen soll, um ihn vom öffentlichen Schlüssel eines anderen MIT-Schülers zu unterscheiden?

Dies ist das Hauptproblem, mit dem sich das KDC befasst hat. Tatsächlich hat KDC zwei Probleme für uns gelöst. Zuerst generierte er eine Nachricht (Ebspk (S)), erstellte einen Sitzungsschlüssel und verschlüsselte ihn für den Server. Wir haben dies jetzt behoben, indem wir Kryptografie mit öffentlichem Schlüssel erstellt haben. Wir mussten aber auch die Hauptzeichenfolgen mit den zuvor bereitgestellten kryptografischen Kerberos-Schlüsseln abgleichen.

In der HTTPS-Welt gibt es ein TLC-Protokoll für solche Dinge. Dies bedeutet, dass wir uns weiterhin auf bestimmte Aspekte des Prozesses verlassen werden, die diese gigantischen Tabellen unterstützen, in denen die Namen der Prozessteilnehmer kryptografischen Schlüsseln zugeordnet sind. Der Plan ist, dass wir eine sogenannte Zertifizierungsstelle haben, die in allen Arten von Literatur zur Netzwerksicherheit durch die Buchstaben CA gekennzeichnet ist. Diese Zertifizierungsstelle unterstützt auch logisch die Tabelle, in einem Teil werden die Namen aller Teilnehmer angezeigt, in dem anderen die entsprechenden öffentlichen Schlüssel. Der Hauptunterschied zwischen diesem Center und Kerberos besteht darin, dass diese Zertifizierungsstelle nicht für alle Transaktionen online sein muss.
In Kerberos müssen Sie mit KDC sprechen, um eine Verbindung zu jemandem herzustellen oder den Schlüssel eines anderen zu finden. Stattdessen tun sie dies in der Welt von CA.



Wenn Sie hier einen Namensnamen und den entsprechenden Schlüsselschlüssel in einem anderen Teil der Tabelle haben, signiert die Zertifizierungsstelle einfach Nachrichten, dass bestimmte Zeilen in dieser Tabelle vorhanden sind. Daher muss die Zertifizierungsstelle hier über eigene private und öffentliche Schlüssel verfügen. Er verwendet einen geheimen Schlüssel, um Nachrichten für andere Benutzer auf dem System zu finden, auf die Sie sich verlassen können.

Wenn Sie also einen Datensatz "Name + Schlüssel" in der CA-Datenbank haben, erstellt CA eine Nachricht, dass dieser Name mit diesem öffentlichen Schlüssel übereinstimmt, und signiert diese Nachricht mit seinem privaten CA-Schlüssel.



Auf diese Weise können Sie Dinge tun, die denen von Kerberos sehr ähnlich sind. Gleichzeitig müssen wir jedoch nicht mehr online eine Zertifizierungsstelle für alle Transaktionen finden. Und es wird tatsächlich viel skalierbarer sein. Dies ist genau das, was üblicherweise als Zertifikat bezeichnet wird. Die Skalierbarkeit wird durch die Tatsache sichergestellt, dass für einen Kunden oder eine andere Person, die dieses System verwendet, ein Zertifikat aus einer Quelle einem Zertifikat aus einer anderen Quelle nicht unterlegen ist. Es ist mit dem geheimen Schlüssel der Zertifizierungsstelle signiert. So können Sie die Echtheit überprüfen, ohne sich an eine Zertifizierungsstelle oder eine andere hier aufgeführte Partei wenden zu müssen.

Das funktioniert so. Der Server, mit dem Sie sprechen möchten, speichert das Zertifikat, das er ursprünglich von der Zertifizierungsstelle erhalten hat. Und jedes Mal, wenn Sie eine Verbindung herstellen, sagt Ihnen der Server: „OK, hier ist mein Zertifikat. Es wurde von dieser CA unterzeichnet. Sie können die Signatur überprüfen und nur sicherstellen, dass es sich um meinen öffentlichen Schlüssel und meinen Namen handelt. “

Auf der anderen Seite passiert dasselbe mit Client-Zertifikaten. Wenn ein Benutzer eine Verbindung zum Webserver herstellt, zeigt sein Client-Zertifikat an, dass Ihr öffentlicher Schlüssel mit dem geheimen Schlüssel übereinstimmt, der ursprünglich im Browser generiert wurde. Wenn Sie eine Verbindung zum Server herstellen, legen Sie daher ein von der MIT-Zertifizierungsstelle signiertes Zertifikat vor, das angibt, dass Ihr Benutzername diesem öffentlichen Schlüssel entspricht. , , , , Athena.

: , ?

: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.

, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.

: ?

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

, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .



. , CA , , , , - , . , , . - , amazon.com, , - .

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

, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».

, , , CRL, , web-, CRL. , - , , . , , , , , .

, . , . , . , . , CRL, - .

, ? , . , CRL .

, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .

26:30 Min.

MIT-Kurs "Computer Systems Security". Vorlesung 14: „SSL und HTTPS“, Teil 2


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?