🚣🏻 🧑🏾‍🤝‍🧑🏾 🍬 Giblets IPsec messen wir gegen TLS 1.3, GOST und Go 🦏 👩🏼‍🔬 😩

Schöne Grüße! Ich möchte Sie über das Gerät des modernen sagen , IPsec - Stack von der ESPv3 und IKEv2 - Protokolle . IPSec umgeht meines Erachtens zu Unrecht viele Seiten, und ich habe keine detaillierte Analyse seiner Arbeit, seiner Protokolle und Fähigkeiten auf Russisch gesehen. Außerdem mache ich etwas Seltsames - vergleiche IPsec ESPv3 und IKEv2 (beide 2005) mit dem modernen, trendigen und hochmodernen TLS 1.3 von 2018.

Warum bin ich so begeistert von IPsec - dem wohl komplexesten Protokollstapel zur Sicherung von Netzwerken? Komplexität ist schließlich der Hauptfeind für Zuverlässigkeit und Sicherheit! Erstens, je mehr Sie über seine Protokolle, insbesondere IKEv2, erfahren, desto besser verstehen Sie, wie viele Möglichkeiten darin enthalten waren, und Sie sind beeindruckt von seiner Nachdenklichkeit, im Gegensatz zu dem üblichen Ansatz der Entwickler, "eine Krücke treibt eine Krücke" und ernsthafte Probleme zu lösen ", bis der Donner ausbricht. Zweitens sind IPSec-Protokolle aus kryptografischer Sicht gut durchdacht, und selbst das alte ESP / IKEv1 ist in der Tat das einzige industrielle Massenprotokoll, bei dem keine schwerwiegenden Schwachstellen aufgetreten sind. Das gleiche SSL (1995) wurde erst ab Version 1.3 anständig durchdacht. Und viele Menschen mögen IPSec aufgrund der ungeheuren Komplexität von IKEv1 nicht.das ist nicht mehr in v2.

Wenn die Entwickler von Betriebssystemen in ihrer Zeit mit der Implementierung und Implementierung von IPsec und IPv6 (für die Verfügbarkeit von Computern, so dass kein NAT) nicht langsamer geworden sind, sollte im Idealfall kein SSL / TLS im Prinzip erscheinen. Die Welt erwies sich als nicht perfekt, aber jetzt ist IPsec out of the box (zumindest SA / SP + ESP Teil des Stacks) in einem zumindest weit verbreiteten Betriebssystem (ich persönlich kenne nur DragonFly BSD , das IPSec getrunken hat, weil es keine Entwickler gab, die es unterstützen). und IPv6 in einigen Industrieländern steht der überwiegenden Mehrheit der Menschen sofort zur Verfügung.

IPsec ist ein Stapel von Protokollen, API-Aufrufen und Frameworks, damit Anwendungen und / oder der Administrator erkennen können, welche Sicherheit sie während der Kommunikation benötigen, und dies wird auf Netzwerkebene ( IP-Sek.) Transparent sichergestellturität). Wir können über beide IP-Pakete von nur einem Socket (z. B. TCP-Verbindungen) und über den Verkehr zwischen ganzen Netzwerken sprechen.

Verkehrssicherheit bedeutet: Gewährleistung der Vertraulichkeit von Daten, ihrer Authentizität / Integrität und Schutz vor Wiederholungsangriffen . Wie fast alle Protokolle verfügt IPsec über einen Transportteil, der IP-Pakete sichert, und einen Handshake-Teil, der sich auf die Schlüsselverhandlung, Parameter, Konfiguration und Authentifizierung der Parteien bezieht.

TLS 1.3 : Bietet nur Datenschutz pro Socket für TCP-Verbindungen. DTLS kann Datagramme schützen (DTLS 1.3 ist noch kein Standard), aber nicht jede Bibliothek unterstützt dies.

Transportprotokolle

Der IPSec-Transport verwendet IP-Protokolle:

AH (Authentifizierungsheader). Ich werde nicht weiter auf AH eingehen, da es keine Vertraulichkeit der Daten bietet und, soweit ich gehört habe, nur dazu gedacht war, die Gesetze einiger Länder in den neunziger Jahren in Bezug auf Beschränkungen der Verwendung von Verschlüsselung irgendwie zu "ertragen". Die Verschlüsselung ist im Vergleich zu allem anderen so leicht, dass es keinen Sinn macht, sie zu opfern. Aber fast überall, wo ESP erwähnt wird, ist auch AH gemeint.
ESP (Kapselung von Sicherheitsnutzdaten). ESP hat sich im Laufe der Zeit leicht weiterentwickelt und verwendet jetzt seine ESPv3-Version, die häufig abwärtskompatibel ist und sich nicht von der vorherigen Version unterscheidet.

IP-Verkehr wird nur durch die Transportschicht gesichert. Und da wir über viele Millionen Pakete pro Sekunde sprechen können, wird de facto ESP zumindest auf Kernelebene des Betriebssystems in seinem Netzwerkstapel implementiert, um keine teure Kontextumschaltung zwischen Kernel und Benutzerbereich durchzuführen (wie dies normalerweise bei TLS der Fall ist) , SSH, OpenVPN und andere).

Ich betone, dass AH und ESP IP-Protokolle sind, Netzwerk, nicht Transport. Warum nicht UDP? Die Prüfsumme ist redundant und brennt die CPU, und die Kryptografie stellt die Integrität trotzdem sicher. Wenn Ihr NAT jedoch nichts über ESP weiß (und er es nicht weiß), funktioniert dies alles nicht für ihn. Später kamen sie auf NAT-T- Krücken (NAT-Traversal), wenn der IPSec-Verkehr in ein UDP-Paket an Port 4500 eingeschlossen ist und NAT passieren kann. Dies ist jedoch ein unnötiger Aufwand und die Notwendigkeit, den IPSec-Stapel im Kernel zu bearbeiten, da er diese speziellen UDP-Pakete bereits verstehen und ESP daraus extrahieren sollte regelmäßige Verarbeitung.

SP, SA, SPI und unsere erste IPSec-Verschlüsselung

Woher weiß der Kernel, was mit einem IP-Paket zu tun ist: ob es mit einem Schlüssel verschlüsselt, das eingehende ESP entschlüsselt oder durchgelassen werden soll, ohne es zu berühren? Zu diesem Zweck verfügt der Kernel über Sicherheitsrichtlinien ( SP ). Dies sind Regeln wie in einer Firewall. Darüber hinaus gibt es im Kernel Sicherheitszuordnungen (Security Associations, SA ): Kontexte zum Ausführen kryptografischer Operationen (Schlüssel, Zähler, Fensterwiedergabe usw.). Im Allgemeinen sind weder SPs IPSec-spezifisch noch SAs - sie können für andere Aufgaben / Protokolle (z. B. OSPF) verwendet werden.

SP / SA kann entweder über eine spezielle API ( PF_KEYv2 ) oder manuell über ein Setkey- Dienstprogramm konfiguriert werden . Zum Beispiel, wenn wir dem Kernel mitteilen möchten, dass alle IP-Pakete von kommenfc :: 123- Adressen auf fc :: 321 müssen über ESP gesichert werden. Dies kann einfach durch Aufrufen über die Befehlszeile erfolgen:

$ echo "spdadd fc00::123 fc00::321 any -P out ipsec esp/transport//require;" | setkey -c

Vor diesem Befehl sahen wir Pings:

IP6 fc00::123 > fc00::321: ICMP6, echo request, seq 0, length 16
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 0, length 16
IP6 fc00::123 > fc00::321: ICMP6, echo request, seq 1, length 16
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 1, length 16

Wir werden es später nicht sehen, da der Kernel noch nicht weiß, "was" zu verschlüsseln ist. Sie müssen eine SA hinzufügen. Dies kann auch manuell erfolgen, indem Sie die einfache AE-GCM-16-Algorithmus- AEAD- Verschlüsselung und einen zufälligen 160-Bit-Schlüssel festlegen :

echo "add fc00::123 fc00::321 esp 0xdeadbabe -E aes-gcm-16 0x0c09d1d90f804b0b4cef80e255e29c0894db1928 ;" | setkey -c

Wenn wir dieselben Befehle auf dem Remote-Host ausführen (nur nicht vergessen, -P in anzugeben ), werden wir sehen:

IP6 fc00::123 > fc00::321: ESP(spi=0xdeadbabe,seq=0x1), length 52
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 0, length 16
IP6 fc00::123 > fc00::321: ESP(spi=0xdeadbabe,seq=0x2), length 52
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 1, length 16

Die Anfrage wird von ESP verschlüsselt, die Antwort jedoch nicht. Da ESP standardmäßig "in eine Richtung" und für die bidirektionale Kommunikation funktioniert, muss ein weiterer SP / SA für die entgegengesetzte Richtung hinzugefügt werden.

0xdeadbabe in diesem Beispiel ist der Security Parameters Index ( SPI ) - eine eindeutige Kennung für den ESP- "Tunnel" zwischen zwei IP-Adressen, unter der der Kernel den entsprechenden SA-Kontext finden und den Entschlüsselungsschlüssel daraus entnehmen kann. Und esp / transport // require ist eine Voraussetzung für die Verwendung von ESP im Transportmodus (mehr dazu weiter unten).

Giblets ESP

Das ESP-Paket ist schematisch wie folgt aufgebaut:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|               Security Parameters Index (SPI)                 | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A
|                      Sequence Number                          | | u
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t
~                       IV (variable)                           ~ | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e -----
|                    Payload Data  (variable)                   | | n   ^ E
~                                                               ~ | t   | n
|                                                               | | i   | c
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c   | r
|               |         TFC Padding * (optional, variable)    | | a   | y
+-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t   | p
|                         |        Padding (0-255 bytes)        | | e   | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d   | e
|                               |  Pad Length   | Next Header   | v     v d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------
~         Integrity Check Value-ICV   (variable)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SPI - 32-Bit-eindeutige Kennung für die ESP-Sitzung / den Tunnel / die Verbindung zwischen IP-Adressen. Typischerweise ist {SrcIP, DstIP, SPI} die SA und der kryptografische Kontext.
SeqNum — 32- . . , replay attack.
payload — ESP, .
TFC padding — (Traffic Flow Confidentiality), , - , . TFC , , payload , . , payload IP , . TFC - , .
Padding — ESP payload 32- , . , ( CBC) . . .
Pad Length — 8- Padding .
Next Header — 8- IP payload. «no next header», ESP- — , . TFC — .
ICV — Integrity Check Value, (MAC).

Der gesamte Teil des Pakets von der Nutzlast bis zum nächsten Header wird verschlüsselt. Alles außer dem MAC ist authentifiziert. Die Länge des ICV und das Vorhandensein einer IV (Initialisierungsvektor) hängen von den verwendeten Verschlüsselungs- und Authentifizierungsmodi / -algorithmen ab.

TLS 1.3 : Das optionale Auffüllen von Daten auf eine bestimmte Größe wurde nur in Version 1.3 angezeigt. Ansonsten sind Verschlüsselung und Authentifizierung völlig ähnlich. TLS 1.3 verpflichtet sich, nur AEAD-Algorithmen zu verwenden, was korrekt und gut ist. ESP unterstützt AEAD, es gibt jedoch eine Auswahl archaischerer Lösungen. Geben Sie die Felder SPI oder SeqNum einnein, da TCP Sequenz und Zustellung garantiert, wird in der Praxis außerdem kein Initialisierungsvektor explizit übertragen - das TLS-Record-Layer-Paket ist daher etwas kürzer. DTLS enthält bereits SeqNum sowie Nachrichtenfragmentierungsdaten.

Die 32-Bit-Paketnummer ist in der Praxis möglicherweise zu kurz. Dies sind nur mehr als 4 Milliarden IP-Pakete, die bei einer Geschwindigkeit von mehr als 10 Mpps in Minuten fliegen können. Was passiert, wenn der Zähler überläuft? Es wird auf Null zurückgesetzt. Dies bedeutet jedoch, dass sich der Wert von SPI + SeqNum für uns wiederholt und die zuvor abgefangenen ESP-Pakete zur Wiederholung des Angriffs verwendet werden können. Um dieses Problem zu lösen, wurde ESN erfunden(Erweiterte Sequenznummer). Dies ist ein 64-Bit-Zähler, von dem jedoch nur die "unteren" 32-Bit in das SeqNum- Feld übertragen werden und die oberen 32-Bit im Speicher gespeichert werden. Der volle Wert des ESN wird authentifiziert - daher sind die Parteien verpflichtet, die Nutzung des ESN im Voraus zu vereinbaren.

ESP-Verschlüsselung

Wie genau erfolgt die Verschlüsselung / Authentifizierung eines ESP-Pakets beispielsweise bei Verwendung von AES-GCM-16? Für die Arbeit mit ESP wird ein 64-Bit-Initialisierungsvektor verwendet, der sich am Anfang der Nutzlast befindet . Es verwendet auch 32-Bit-Salz als Teil des Schlüsselmaterials. Im Beispiel für setkey habe ich keinen 128-Bit-Schlüssel bereitgestellt, sondern einen 128 + 32-Bit-Schlüssel. Es kann Situationen geben, in denen der Schlüssel wiederverwendet wird und die IV mit einem schlechten Pseudozufallszahlengenerator (PRNG) gefüllt ist, dessen Werte wiederholt werden können. Das Salz soll vor diesem gefährlichsten Fall schützen, der möglicherweise zur Entschlüsselung abgefangener Pakete führt. Die Verschlüsselung / Authentifizierung von ESP selbst im AES-128-GCM-16-ESP-Modus ist wie folgt:

AES-GCM(
    key             = 128-bit key,
    plaintext       = 64-bit IV || payload || TFC || pad || padLen || NH,
    nonce           = 32-bit salt || IV,
    associated-data = SPI || {ESN  SeqNum},
) -> encrypted-payload || 128-bit ICV

ESP = SPI || SeqNum || IV || encrypted-payload || ICV

Für russische GOST-Algorithmen (Magma- oder Grasshopper-Chiffren) sind die Eingabedaten ähnlich. Beide Chiffren werden im MGM- Modus verwendet (ich würde sagen eine verbesserte Version von GCM ), und die regelmäßige Rotation des ESPTREE- Schlüsselmaterials wird mit HMAC-Stribog-256 angewendet . Dies reduziert die Belastung des Schlüssels. Hauptsächlich im Zusammenhang mit IPSec bedeutet dies weniger eine Verlängerung der Nutzungsdauer als vielmehr eine Reduzierung der Angriffsfläche durch Seitenkanäle. Beispielsweise erwies sich die GOST 28147-89-Blockverschlüsselung mit 64-Bit-Blockgröße aufgrund von Schlüsselnetzen (eine ähnliche Technologie der konstanten Schlüsselrotation) als unverwundbar für SWEET32- Angriffe.

Aus Sicherheitsgründen gibt es keine Beschwerden über ESP mit AEAD-Algorithmen. Bei AEAD-Algorithmen ist IV jedoch nur ein 64-Bit-Zähler, der explizit mit jedem Paket übergeben wird, das Speicherplatz im Paket verschwendet. SeqNum ist zu kurz und ESN wird nicht vollständig übertragen, obwohl es vollständig als IV passen würde. Für Nicht-AEAD-Algorithmen ist IV möglicherweise bereits erforderlich und weist einen unvorhersehbaren Wert auf, jedoch keinesfalls einen Zähler. Dies ist ein Vermächtnis, da wertvoller Platz in der Verpackung und das Gewicht die Zuverlässigkeit hier nicht beeinträchtigen.

Wenn IV für AEADs Werte von 128 Bit haben könnte, wäre es möglich, Algorithmen wie XSalsa20 / XChaCha20 mit 192-Bit-Nonce zu verwenden, von denen 128 Bit beim Start pseudozufällig generiert werden, und die verbleibenden 64 Bit können für den Zähler verwendet werden ... Dies könnte ein Lebensretter für Systeme sein, die ihren Zählerstatus verloren haben, aber weiterhin vorhandene Schlüssel verwenden möchten.

TLS 1.3 : XOR wird als Nonce zwischen dem Nachrichtenzähler und dem mit dem Schlüssel generierten Initialisierungsvektor verwendet. Da weder das Messgerät noch die IV explizit übertragen werden, ist TLS 1.3 etwas kompakter. Wenn ESP Nicht-AEAD-Algorithmen verwendet, muss möglicherweise eine unvorhersehbare IV generiert werden, die spürbar CPU-intensiv sein kann.

Tunnel- und Verkehrsträger

Was ist in der Nutzlast des Pakets enthalten? Dies hängt davon ab, ob das ESP im Transportmodus oder im Tunnelmodus arbeitet . Der Transportmodus ersetzt die Nutzlast des übertragenen IP-Pakets durch ESP durch diese Nutzlast. Das heißt, es war:

---------------------------------------
| orig IP hdr |[ext hdrs]| TCP | Data |
---------------------------------------

wurden:

---------------------------------------------------------
| orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
                             |<--- encryption ---->|
                         |<---- authenticity ----->|

Im Tunnelmodus wird das gesamte IP-Paket vollständig in ESP eingeschlossen und ein neues IP-Paket gebildet, normalerweise mit neuen Headern und SrcIP / DstIP-Adressen. Dieser Modus wird verwendet, um Pakete zwischen Netzwerken zu tunneln.

----------------------------------------------------------
| new* |new ext|   | orig*|orig ext|   |    | ESP   | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
----------------------------------------------------------
                   |<--------- encryption --------->|
               |<---------- authenticity ---------->|

Zum Beispiel kann ich über setkey festlegen, dass alle Pakete zwischen 2001: ac :: / 64 und 2001: dc :: / 64- Netzwerken verschlüsselt durch zwei Endpunkte von Tunneln mit den Adressen 2001 :: 123 , 2001 :: 321 geleitet werden sollen ...

spdadd 2001:ac::/64 2001:dc::/64 any -P out ipsec esp/tunnel/2001::123-2001::321/require ;
spdadd 2001:dc::/64 2001:ac::/64 any -P in  ipsec esp/tunnel/2001::321-2001::123/require ;

Der Transportmodus wird häufig als Host-zu-Host-Verbindung bezeichnet. Wenn für das Tunneln ein GRE- oder IPv * -over-IPv * -Protokoll verwendet wird, das bereits zwischen zwei Endpunkten funktioniert, ist es in diesem Fall nicht sinnvoll, den Tunnelmodus auf IPSec-Ebene zu verwenden. Der Transportmodus authentifiziert den IP-Header jedoch nicht. Dies ist in der Regel nicht wichtig und nicht kritisch. Wenn Sie jedoch sicherstellen möchten, dass keine erweiterten IPv6-Header oder Flussbezeichnungen von Paketen geändert wurden, sollten Sie den Tunnelmodus auf Kosten des Overheads verwenden, auch wenn er zwischen zwei Hosts liegt.

ISAKMP

Was passiert, wenn ich die Computer neu starte, SA mit allen Zählerwerten aus ihrem Speicher verschwindet und ich die alten SP / SA-Befehle erneut mit meinen Händen lade? Erstens können Pakete, die mit der IV übereinstimmen, entschlüsselt werden, da dies einer zweimaligen Verwendung des Chiffrierpads gleichkommt. Zweitens werden alle zuvor abgefangenen Pakete gültig authentifiziert, da SPI / salt / ESN / SeqNum übereinstimmen, und Sie können sie erneut abspielen. Die Wiederverwendung solcher Setkey- SAs ist aus Sicherheitsgründen katastrophal. Drittens, insbesondere wenn ESN nicht verwendet wird (z. B. in FreeBSD zum Zeitpunkt dieses Schreibens wird es noch nicht unterstützt), stellen Sie bei einem langen SA-Betrieb möglicherweise nicht fest, dass der Zähler "verbraucht" ist.

All dies bedeutet, dass wir die ESP-Schlüssel regelmäßig ändern müssen. Und vereinbaren Sie auch den Verschlüsselungsalgorithmus, das Vorhandensein von ESN-, TFC-, Transport- / Tunnelmodus- und SPI-Werten. De facto wird hierfür das ISAKMP- Protokoll (Internet Security Association und Key Management Protocol) verwendet . Sie können jedoch problemlos einige IM mit OTR / PGP / OMEMO-authentifizierter Verschlüsselung verschrauben und einfach die Shell-Skript- Setkey- Befehle an den Server senden , auf dem die Schlüssel durch Lesen von / dev / urandom generiert werden . Für den Kernel ist es egal, wie es vereinbart wurde. Wie in OpenVPN: X.509 erfolgt die Authentifizierung mit Zertifikaten und Schlüsselaushandlung im Allgemeinen über TLS, und das VPN-Transportprotokoll selbst ist bereits ein eigenes.

In seiner "reinen" Form wird ISAKMP nicht verwendet, da es keine Kryptographie enthält. Um Gesprächspartner zu authentifizieren und Schlüsselmaterial zu generieren, wird ein Protokoll eines Drittanbieters verwendet, das ISAKMP in sich selbst kapselt. Ich weiß:

KINK - Kerberisierte Internetaushandlung von Schlüsseln , bei der ein drittes vertrauenswürdiges Kerberos-KDC zur Authentifizierung und Aushandlung verwendet wird. Neben der Beschreibung aus Wikipedia weiß ich nichts mehr über KINK und habe es nicht live gesehen.
IKE (v1) - Internet Key Exchange . Wahrscheinlich immer noch das beliebteste Protokoll, obwohl es 1998 erstellt wurde.
IKEv2 ist die zweite Version von IKE, 2005, über die ich sprechen werde.

IKE-Protokolle sind aufgrund der großen Anzahl unterschiedlicher Nutzlasttypen sehr erweiterbar. IKEv1 bietet eine Vielzahl von Optionen, um nur einen Tunnel für die Arbeit zu konfigurieren. Mehr als ein Dutzend RFCs beschreiben die gesamte Reihe von ISAKMP und IKEv1 mit gemeinsamen Nutzdaten. Einschüchternde Komplexität. Plus die Fähigkeit, nicht narrensichere Konfigurationen einfach zu vermasseln, und der bekannte, teilweise zu Recht zutreffende Mythos, dass IKEv1 garantiert nur funktioniert, wenn die Konfigurationsdatei fast vollständig kopiert wird.

Glücklicherweise ist IKEv2 erschienen: ein praktischer RFC (für die meisten Funktionen), ein erheblich vereinfachtes Protokoll für die Aushandlung von Parametern und entsprechend seine Konfiguration. In der Regel gibt es weniger Roundtrips für den gesamten Handshake- und Schlüsselvereinbarungsprozess als in IKEv1. Daher wird nur er berücksichtigt, da IKEv1 keinen Sinn mehr hat (aber es lohnt sich kaum, bereits laufende und funktionierende Instanzen zu ersetzen, da sie funktionieren). IKEv2 verwendet im Gegensatz zu IKEv1 absolut ähnliche Algorithmen und Ansätze, um seine eigenen Nachrichten zu verschlüsseln, wie dies bei ESP der Fall ist. Außerdem wurde die EAP-Authentifizierung eingeführt und die Möglichkeit für jede Partei, sich mit unterschiedlichen Methoden zu authentifizieren (z. B. verwendet der Client PSK und der X.509-Server Zertifikate).

IKE Daemon

      +-------------+
      |  |
      +-------------+
       |           |
       |           |
       |           |      /userspace
=====[PF_KEY]====[PF_INET]====================
       |           |                    
+-----------+   +-------------+
| |   |TCP/IP,      |
|  SA  SP  |---| IPsec|
+-----------+   +-------------+
                     |
                 +-----------+
                 |    |
                 |  |
                 +-----------+

Dieser Teil des IPSec-Stapels wird bereits ausgeführt, normalerweise im Benutzerbereich. Erstens sind dies keine stark belasteten Dämonen: Sie können mindestens einmal am Tag miteinander kommunizieren, und der erste Handschlag erfordert einige Roundtrips über UDP. Zweitens ist die Anzahl der ISAKMP / IKE-Funktionen so hoch, dass hunderte Male mehr Code vorhanden ist als in der vollständigen SA / SP / ESP-Implementierung. Es gibt viele ISAKMP-Dämonen: strongSwan (IKEv1 / v2) (sowie Openswan , Libreswan ), isakmpd (IKEv1), OpenIKED (IKEv2), Waschbär (IKEv1), racoon2 (IKEv1 / v2, KINK) und andere.

Hinweis: Richtig zu schreiben und zu sprechen "Daemons" ( Daemons)), wie ich in Übersetzungen der Fiktion gesehen habe. Aber in technischen russischsprachigen Kreisen haben "Dämonen" bereits Wurzeln geschlagen.

TLS 1.3 : Im Allgemeinen handelt es sich bei dem gesamten TLS-Stapel um Bibliotheksfunktionen, die in jeder einzelnen Anwendung funktionieren und Schlüsselmaterial in ihrem eigenen Speicher speichern. Die gesamte Kryptografie erfolgt durch Umschalten auf den Benutzerbereich, was einen enormen Aufwand bedeutet. Zumindest FreeBSD und Linux verfügen jedoch bereits über nukleare Offload-Implementierungen von TLS, wenn ähnlich wie bei IPSec der Transportteil vollständig im Kernel verarbeitet wird und der Handshake im Benutzerbereich stattfindet.

IKEv2 läuft standardmäßig über UDP auf Port 500 ( isakmp)Bedienung). Daemons erstellen einen sicheren Kanal, authentifizieren sich gegenseitig, verhandeln / erstellen / löschen ESP SA / SPs, aktualisieren Schlüssel, führen einen Heartbeat aus (Dead Peer Detection ( DPD )) und vieles mehr. Die gesamte Kommunikation zwischen Dämonen erfolgt in Form eines Austauschs von zwei Anforderungs- / Antwortnachrichten. Jede Anfrage muss beantwortet werden. Was tun, wenn ein Paket verloren geht, da dies UDP ist? Berücksichtigen Sie dies in Ihrem Bundesstaat, senden Sie Anfragen nach einer Zeitüberschreitung, für die keine Antworten eingegangen sind, erneut, senden Sie Antworten auf wiederholte Anfragen erneut, ignorieren Sie wiederholte Antworten. Pakete können in einer chaotischen Reihenfolge ankommen, sie können unvorhersehbar verschwinden - vieles wird im IKEv2-Standard berücksichtigt und es wird beschrieben, wie man sich unter verschiedenen Rennbedingungen verhält.

TLS 1.3: Die TCP-Natur von TLS kümmert sich um die Bestellung und Zustellung von Nachrichten. TCP beansprucht jedoch erhebliche Ressourcen im Betriebssystemkern und eine große Anzahl von TCP-Sitzungen kann ein Problem darstellen (im Gegensatz zu UDP). In DTLS treten jedoch alle ähnlichen Probleme auf die gleiche Weise wie in IKE auf, und es werden Hämorrhoiden bei der Verarbeitung fragmentierter Nachrichten hinzugefügt. Das Ändern der IP-Adressen von Endpunkten für UDP ist kein Problem. IKE-Verbindungen sind in der Regel sehr langlebig (der IKE-Status ist klein und wird nur im Speicher des Userspace-Daemons gespeichert) und erfordern daher seltener einen Handshake, während Sie dies in TLS nach dem Verlust einer TCP-Verbindung tun müssen (obwohl es auch beschleunigte Methoden zum Fortfahren von Sitzungen gibt, wenn der Status dies nicht war verloren, zum Beispiel beim Neustart des Programms). Da der IKE-Dämon (in der Regel) einer für das gesamte System ist, sollten einige Anwendungen sicher damit kommunizierenMit jemandem, der bereits eine IKE-Verbindung hat, kann er diese entweder sofort verwenden, oder der Dämon erstellt in einem Roundtrip eine zusätzliche ESP-SA für die Anwendung.

Innereien IKE

Der erste Austausch (Request-Response) der Daemons ist IKE_SA_INIT , wodurch eine IKE SA für die weitere sichere Kommunikation erstellt wird. Beachten Sie, dass die ESP SA im Kernel "gespeichert" ist und die IKE SA im Userspace-Daemon. Dann kommt der IKE_AUTH- Austausch, bei dem die Parteien authentifiziert werden. Im gleichen Austausch wird eine untergeordnete SA ( Child SA ) erstellt, die für die ESP SA verwendet wird. Im Allgemeinen reichen diese beiden Austausche aus, um die Parteien zu authentifizieren und ESP SA-Parameter mit den Schlüsseln auszuhandeln und dann den verschlüsselten ESP-Verkehr zwischen Computern zu steuern. Gleichzeitig bleibt eine funktionierende IKE SA lange Zeit zwischen den Dämonen. Darüber hinaus können sie jederzeit CREATE_CHILD_SA austauschen, um mehr untergeordnete Sicherheitszuordnungen sowie INFORMATIONAL zu erstellenAustausch (eine Vielzahl von Zwecken).

Alle IKEv2-Nachrichtenkopfzeilen haben die folgende Struktur:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Initiator's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Responder's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Payload |    Version    | Exchange Type |     Flags     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Message ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Length                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SPIi - 64-Bit-IKE SA-Initiator-SPI. Ein vom Initiator der IKE-Sitzung zufällig generierter Bezeichner.
SPIr - 64-Bit-IKE SA-Responder-SPI. Ebenso aber nur SPI von der Responder-Seite. In der allerersten Nachricht des Initiators wird dieses Feld mit null Bytes gefüllt.
NP - 8-Bit Nächste Nutzlast. Nutzlastkennung nach dem Header.
Version - 8-Bit-Version des IKE-Protokolls.
ExchType - 8-Bit-Typ des IKE-Austauschs: IKE_SA_INIT , IKE_AUTH , CREATE_CHILD_SA oder INFORMATIONAL .
Flags — 8- . .
MsgID — 32- . , , replay-. — request/response MsgID. , .
Len — 32- ( + ).

SPIi + SPIr sind 128-Bit. Warum so viel, wenn ESP nur 32 Bit hat? Erstens, da sie nicht übereinstimmen, sondern pseudozufällig generiert werden, reicht 64-Bit für eine Seite aus, um Kollisionen zu vermeiden. Zweitens ist ESP auch an IP-Adressen gebunden, während dies bei einer IKE-Sitzung im Allgemeinen nicht der Fall ist. Die Parteien können ihre IP-Adressen (mobiler Client) problemlos ändern und weiterhin kommunizieren.

TLS 1.3: Durch Ändern der IP-Adresse wird die Verbindung getrennt. Selbst mit iPSK müssen Sie einen Rehandshake durchführen, um Ressourcen für die asymmetrische Kryptografie zu sparen. Dies sind 1,5 Roundtrips plus Roundtrips, um eine TCP-Verbindung herzustellen. Die Erstellung von untergeordneten ESP-SAs für neue IP-Adressen in einer bereits eingerichteten IKE-Verbindung (ungebunden an Adressen) erfordert nur einen Roundtrip (+ Roundtrip zum Entfernen alter Adressen, dies geschieht jedoch bereits im Hintergrund einer neuen funktionierenden ESP-SA).

Auf den IKE-Header folgen eine oder mehrere Nutzdaten. Jede Nutzlast hat einen allgemeinen Formatheader und dann einen für ihren Typ spezifischen Inhalt. Der Inhalt ist 32-Bit ausgerichtet. Ein gemeinsamer Header für alle:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Payload — 8- . payload- . payload. payload IKE . Encrypted Payload, payload- NP ( payload IKE ), payload- .
C — «» payload. IKEv2 payload , IKE . payload . IKE vendor-specific , .
Len — 16- payload ( + ).

Daher bestehen IKE-Nachrichten aus einem IKE-Header und Nutzdaten, die in einer Kette miteinander verbunden sind. Daemons können unkritische und unbekannte Nutzdaten ignorieren. Der Nutzdateninhalt des Nonce- Typs (nach dem Header) ist nur ein zufälliger Datensatz, keine feste Größe. Es gibt aber auch viel komplexere Strukturen. In IKE-Standards werden kurze Bezeichnungen für Nutzlasttypen akzeptiert (z. B. N * für Nonce-Nachrichten, wobei "*" entweder "i" (Initiator) oder "r" (Responder) ist).

SIGMA

Aus kryptografischer Sicht gehören IKEv1 / IKEv2 zur Klasse der authentifizierten Schlüsselaustauschprotokolle STS, ISO / IEC IS 9798-3 und SIGMA (SIGn-and-MAc). Dies sind sehr gut erforschte und mathematisch verifizierte (SIGMA) Lösungen. In meinem Artikel "P2P F2F E2EE IM an einem Abend" habe ich bereits das Funktionsprinzip und die Implementierung des SIGMA-I-Protokolls beschrieben. IKEv2 ist völlig ähnlich. Was erwarten wir, wenn wir die Sicherheit des Handshake-Protokolls diskutieren?

Vertraulichkeit übermittelter Nachrichten;
Authentizität und Integrität der übertragenen Nachrichten - ihre Änderung muss erkannt werden;
Schutz vor Wiederholungsangriffen - Die Tatsache des Verlusts oder der Wiederholung von Nachrichten muss erkannt werden.
;

perfect forward secrecy (PFS) — PSK ( IKE ESP SA). ;

/ ( ) IKE . / ( ) ;

, , . .

Nach einem solchen IKE_SA_INIT- Austausch haben die Dämonen die Adressen der anderen, SPIi + SPIr den Wert der IKE-Sitzung, die von der SA ausgehandelten Algorithmen (im Fall von IKE sind dies Schlüsselvereinbarung ( DH ), Nachrichtenverschlüsselung / -authentifizierung ( ENCR ), Schlüsselgenerierungsalgorithmen ( PRF )), der öffentliche Schlüssel (DH) der gegenüberliegenden Seite. Dies reicht aus, um den Status im Speicher zu speichern und eine Schlüsselvereinbarung durchzuführen (Diffie-Hellman, GOST R 34.10-VKO, Kurve 25519 usw.), um einen symmetrischen Schlüssel zum Verschlüsseln der Nutzdaten nachfolgender IKE-Nachrichten zu generieren.

TLS 1.3: Das Format der Handshake-Nachrichten ist sehr unterschiedlich, es gibt viel Vermächtnis, aber im Grunde nichts, was auffällt. Das Zufallsfeld wird anstelle von Nonce verwendet. Anstelle von Nutzlasten zahlreiche Erweiterungen. Anstelle einer komplexen SA-Vorschlagsstruktur werden Verschlüsselungskennungen verwendet, die kompakter und einfacher sind. Meiner Meinung nach ist die Flexibilität von SA-Vorschlägen übermäßig hoch, aber in IKEv2 ist dies immer noch kein Problem, und Werte, die Ciphersuite ähneln, werden in die Konfigurationsdatei geschrieben. Nur mit TLS 1.3 wird der DH-Austausch obligatorisch.

IKE Schlüsselmaterial

Nach IKE_SA_INIT wird SKEYSEED generiert :

SKEYSEED = PRF (Ni [: 8] || Nr [: 8], DH-KEY)

Der PRF-Algorithmus wird in der IKE SA ausgewählt. Für GOST IKEv2 ist dies beispielsweise die HMAC-Stribog-512-Funktion. Der PRF-Schlüssel ist ein 64-Bit-Block aus jeder Nonce.

Es sieht leichtfertig aus, weil Nonces offen übertragen werden, was bedeutet, dass der Schlüssel für diese PRF jedem bekannt ist, der den Verkehr abgefangen hat. PRF wird hier jedoch ausschließlich verwendet, um aus dem DH-KEY- Ergebnis der Berechnung des DH einen Schlüssel zu generieren, der dem Angreifer bereits unbekannt ist . Das Ergebnis der DH-Funktion kann ein großer und ungleichmäßiger Entropiewert sein, es kann ein Punkt auf einer elliptischen Kurve sein - all dies kann nicht als kurzer symmetrischer Schlüssel mit hoher Entropie verwendet werden. Daher müssen Sie die Entropie aus DH-KEY extrahieren (dies ist nur SKEYSEED ) und dann erweitern (erweitern ) auf die erforderliche Anzahl von Schlüsseln:

PRF+(SKEYSEED, Ni || Nr || SPIi || SPIr) ->
    SK_d || SK_ai || SK_ar || SK_ei || SK_er || SK_pi || SK_pr

PRF+(K,S) = T1 || T2 || T3 || T4 || ...
T1 = PRF(K,       S || 0x01)
T2 = PRF(K, T1 || S || 0x02)
T3 = PRF(K, T2 || S || 0x03)
T4 = PRF(K, T3 || S || 0x04)

Dies ist alles eine klassische Schlüsselableitungsoperation mit Extraktions- / Erweiterungsstufen , ähnlich der HKDF- Funktion. Wenn HKDF jedoch die Verwendung von Hash-Funktionen übernimmt, kann diese PRF / PRF + -Konstruktion einfach mit symmetrischen Chiffren verwendet werden - im Fall des üblichen AES-GCM + AES-XCBC-PRF werden wir nirgendwo eine Hash-Funktion verwenden, sondern nur eine kleine Anzahl gebrauchte Grundelemente sind immer gut.

Folgende Schlüssel werden generiert:

SK_d- Schlüssel zum Generieren von Schlüsseln für untergeordnete ESP-SAs.
SK_a [ir] Schlüssel für die IKE-Nachrichtenauthentifizierung. Nicht generiert / nicht verwendet, wenn der AEAD-Algorithmus vereinbart ist (AES-GCM, Grasshopper / Magma-MGM, ChaCha20-Poly1305 usw.).
SK_e[ir] IKE .
SK_p[ir] AUTH.

TLS 1.3: hat eine wesentlich komplexere Schlüsselplanung. Die Entropie wird auf einmal aus den gesamten Handshake-Nachrichten herausgedrückt und nicht aus einzelnen Feldern. Die generierte erweiterte Sequenz wird nicht nur in eine Reihe von Schlüsseln geschnitten (+ Salz für diese bei Bedarf), sondern auch von HMAC-Transformationen mit Labels (Labels) für jeden Verwendungskontext dieser Schlüssel oder generierten IVs begleitet. Die Verwendung von Textbezeichnungen / Anwendungen / Kontexten für jede Art von generiertem Wert ist eine gute moderne Praxis und einfacher, als sich zu fragen, ob Sie sie benötigen. Alles zu hacken, was auffällt, ist auch eine sehr gute Praxis: "Es wird nicht schlimmer werden." Dies bedeutet jedoch nicht, dass die Sicherheit von IKEv2 schlechter ist oder dass man leicht zumindest eine entfernt theoretische Situation finden kann, in der das Fehlen eines Labels in den Händen eines Angreifers liegen kann.In IKEv2 ist der Ansatz minimal, während es in TLS 1.3 "besser ist, ihn zu überschreiben" (weil in früheren Versionen des Protokolls wie viele Pfosten oder Schwierigkeiten aufgetreten sind!). IKEv2 verwendet weiterhin bewährte Ansätze und Grundelemente, authentifiziert alles, was benötigt wird, drückt / berücksichtigt die gesamte übertragene Entropie und verwendet unterschiedliche Schlüssel für jede Seite und Aufgabe.

IKE_AUTH

Als nächstes wird ein IKE_AUTH- Austausch durchgeführt , der beide Parteien authentifiziert und die ESP SA aushandelt:

    SK{IDi, [CERT, ...], [CERTREQ], [IDr], AUTH, SAi2, TSi, TSr} -->
<-- SK{IDr, [CERT, ...],                   AUTH, SAr2, TSi, TSr}

IKE-Nachrichten enthalten eine verschlüsselte Nutzlast ( SK ), die alle anderen enthält.
Der Initiator stellt seine Kennung ( IDi ), seinen Authentifikator ( AUTH ), sein SA-Angebot für ESP ( SAi2 ) und ein Initiator / Responder-Paar bereit , sogenannte Verkehrsselektoren ( TS * ). Optional kann auch die erwartete Responder-ID gesendet werden, die als eine Art SNI-Analogon von TLS betrachtet werden kann.
Als Antwort erhält es die Kennung des Antwortenden, den ausgehandelten ESP SA-Vorschlag, validierte Verkehrsselektoren und einen Authentifikator.
Danach betrachten sich beide Parteien gegenseitig als authentifiziert, haben eine Vereinbarung über ESP SA, Datenverkehr, der zu diesem ESP gehören muss, und können dem Kernel bereits einen Befehl zum Erstellen von SA und möglicherweise SP erteilen (es gibt Dämonen, die sich überhaupt nicht mit SP befassen).

Jetzt genauer über diese Nutzlasten:

ID - Partei- ID . Enthält den Identifikationstyp und die dafür spezifischen Daten. Die Parteien können auf viele Arten identifiziert werden: IPv4 / IPv6-Adresse, FQDN (vollqualifizierter Domänenname, nur eine Zeichenfolge, die beliebteste Methode), RFC822-E-Mail-Adresse, ASN.1 DER Distinguished Name (die häufigste Methode bei Verwendung von X.509-Zertifikaten) oder Allgemeiner Name sowie herstellerspezifisch.
AUTH — . PRF ( MAC-), (pre-shared key (PSK)), . (TBS*):
```
TBSi = Msg0 || Nr || PRF(SK_pi, IDi)
TBSr = Msg1 || Ni || PRF(SK_pr, IDr)
```
(Msg0), nonce (Nr), (IDi), «» . , SK_pi ( ). «».

/ . . ( Ni Nr), . , , .

, . ( ), . , - . round-trip-. SIGMA- , IKEv2, ESP SA, . , , . SIGMA MAC c ( SK_*). IKEv2 PRF, . , PRF(ID*) , brute-force ( ) .

PSK, :
```
AUTHi = PRF(PRF(PSK, "Key Pad for IKEv2"), TBSi)
AUTHr = PRF(PRF(PSK, "Key Pad for IKEv2"), TBSr)
```
PRF(PSK) PSK ? PSK PRF . PSK , /. PRF() «» . PRF(PSK) PSK PSK , ( Argon2, Balloon ).
SA*2 — SA , ESP .
TS* — . : IPv4/IPv6 , IP (), / (), / . :
```
TSi = ((proto=17, port=100, fc::123 - fc::123),
       (proto=17, port=200, fc::123 - fc::123))
TSr = ((proto=17, port=300, :: - ffff:..:ffff),
       (proto=17, port=400, :: - ffff:..:ffff))
```
, UDP ( = 17), 100- 200- fc::123 , UDP 300 400. , IP . , , IP , ( , ICMP ). , .

UDP . , , , 100 300-, ESP SA .

Die antwortende Partei sendet ihre bestätigte Auswahl von Selektoren, die entweder übereinstimmen oder engere Auswahlbereiche haben können.

Alle diese Nutzdaten werden auf dem von der IKE SA nach dem ersten Nachrichtenaustausch generierten Schlüssel verschlüsselt. Die Verschlüsselung ist erforderlich, um die übermittelten Kennungen der Parteien, ihre Zertifikate und andere private Informationen offen zu verbergen. Ein aktiver Angreifer kann sich jedoch in den ersten IKE_SA_INIT- Austausch einklemmen und diese Informationen anzeigen , obwohl er die Sitzung nicht mehr fortsetzen kann.

TLS 1.3 :

application ( ServerHello ||… || Finished, , , ), (Client Finished). IKEv2 ESP SA round-trip-, TCP/SCTP handshake.
, (IDr ), SNI, ClientHello . IKEv2 . ESNI, , DNS, DPI.
IKEv2 , «»/«» ( ), PSK, , EAP. TLS 1.3 X.509 . TLS 1.3 X.509 . RFC TLS 1.3 «» . IKEv2 / .
TLS 1.3 , , application ClientHello (EarlyData), application Client Finished . TLS 1.3 EarlyData .
TLS (session resumption), iPSK , , . IKEv2 , RFC 5723 . IKE , , ( TCP/SCTP/whatever ) IP .
TLS . IKEv2 IKE SA ESP SA . , () high-grade , . , , , . - ChaCha20-Poly1305, AES-256-GCM-16, -MGM . IKE SA ESP - NIST-.

Die Verschlüsselung von SK- Nutzlast-AEAD-Chiffren ist nicht schwierig und ähnelt ESP beispielsweise für AES-GCM (bei dem das Salz ähnlich wie bei AES-GCM-ESP Teil des Schlüsselmaterials ist):

AES-GCM(
    key             = SK_*e,
    plaintext       = 64-bit IV || payloads || pad || 8-bit padLen,
    nonce           = 32-bit salt || IV,
    associated-data = IKEHdr || unencrypted payloads
) -> ciphertext

Authentifizierung mit EDS

Was ist, wenn sich eine Partei mit Signatur und X.509-Zertifikaten authentifizieren möchte? Zu diesem Zweck kann bereits in IKE_SA_INIT eine CERTREQ- Nutzlast gesendet werden, wobei die gegenüberliegende Seite aufgefordert wird, ein Zertifikat in Form von CERT- Nutzdaten bereitzustellen . CERT und CERTREQ enthalten die Zertifikatsformatkennung und den formatspezifischen Inhalt. In der Regel können Zertifikate als ASN.1 DER oder als SHA1-Hash des Zertifikats + der URL angezeigt werden, von der sie heruntergeladen werden können. Da die Größe von UDP durch die MTU begrenzt ist und die Größe von Zertifikaten viel größer sein kann, ist die Option Hash + URL hier nützlich (obwohl sie als Krücke betrachtet werden kann).

Der IKEv2-RFC allein listet zusätzlich zu DER-codierten X.509-Zertifikaten und SHA1 + -URLs Folgendes auf: PKCS # 7-umschlossenes X.509-Zertifikat, PGP-Zertifikat, DNS-signierter Schlüssel, SPKI-Zertifikat, X.509-Attributzertifikat, öffentliche Rohschlüssel. Wenn Sie IPSec auf die gleiche Weise wie das häufigste TLS für Anwendungsfälle verwenden möchten: einen Server, der durch ein X.509-Zertifikat und einen anonymen Client authentifiziert wurde, gibt es in IKEv2 keine Möglichkeit, eine der Parteien nicht zu authentifizieren. Aber RFC 5386 beschreibt einen besser als Nichts-Sicherheit Ansatz , bei dem der „Client“ die nackten öffentlichen Schlüssel verwenden kann , und der Server kann es als anonym behandelt.

Darüber hinaus wird die EAP-Authentifizierung standardmäßig unterstützt, wobei IKE_AUTH Roundtrips hinzugefügt werdenAustausch. EAP kann sowohl angeben, ob die Partei authentifiziert ist oder nicht, als auch einen Schlüssel generieren, den IKEv2 berücksichtigt und verwendet. Ich werde Ihnen nur ein Diagramm zeigen, wie EAP funktionieren kann:

                 SAi1, KEi, Ni  -->
                                <--  SAr1, KEr, Nr
SK{IDi, [IDr], SAi2, TSi, TSr}  -->
                                <--  SK{IDr, AUTH, EAP}
                       SK{EAP}  -->
                                <--  SK{EAP(success)}
                      SK{AUTH}  -->
                                <--  SK{AUTH, SAr2, TSi, TSr}

TLS 1.3 : Darin wird die Signatur (oder MAC in der fertigen Nachricht) über dem Hash aller gesehenen Nachrichten platziert, die am Handshake teilgenommen haben. Auch ein einfacher und zuverlässiger guter Ansatz. Es gibt keine Vielzahl von Authentifizierungsmethoden. Ich würde mir aber ein starkes PAKE-Protokoll (Authenticated Password Key Agreement) wünschen, wie das russische SESPAKE oder OPAQUE .

ESP SA Schlüsselmaterial und seine Erneuerung

Also haben wir die Authentifizierung überprüft, überprüft, ob die Schlüsselvereinbarung korrekt ist, die ESP SA und die Verkehrsselektoren ausgehandelt. Es müssen noch symmetrische Schlüssel für ESP generiert werden, und die erforderliche SA / SP kann im Kernel installiert werden:

PRF + (SK_d, Ni || Nr) -> KEYMAT0 || KEYMAT1

Für die bidirektionale Kommunikation sind zwei ESP-SAs erforderlich. Daher generiert IKEv2 zwei Schlüsselmaterialien gleichzeitig, die bereits direkt an den Kern in der entsprechenden SA übertragen werden. Die Länge des Materials hängt vom verwendeten ESP-Algorithmus ab (zum Beispiel benötigt AES-GCM-ESP neben dem Schlüssel auch 32-Bit-Salz). Der SPI-Wert ist der SPI-Wert, der von jeder Partei in den ESP SA-Vorschlägen angegeben wird.

Was ist, wenn wir uns beispielsweise auf mehrere ESP SA / SPs einigen müssen, weil nicht alle Wünsche in einem einzigen TSi / TSr- Paar spezifiziert werden können? Hierzu werden CREATE_CHILD_SA- Austausche verwendet, die jederzeit nach IKE_AUTH stattfinden . Die Erstellung einer untergeordneten SA erfolgt im folgenden Austausch:

    SK {SA, Ni, [KEi], TSi, TSr} ->
<- SK {SA, Nr, [KEr], TSi, TSr}

SA-Angebot wird gemacht, Nonces, Verkehrsselektoren werden gesendet. Alles ist wie zuvor. Das Schlüsselmaterial wird bereits mit diesen neuen Nonces generiert. Optional können Sie Nutzdaten für den Schlüsselaustausch verwenden, die die Entropie erhöhen und die Parteien dazu zwingen, eine noch asymmetrischere Kryptografie zu verwenden. Möglicherweise muss die PFS-Eigenschaft ständig beachtet werden (im OTR- Protokoll werden mit jeder Nachricht kurzlebige DH-Schlüssel gesendet). Das Schlüsselmaterial in diesem Fall wird wie folgt ausgearbeitet:

PRF + (SK_d, DH-KEY || Ni || Nr) -> KEYMAT0 || KEYMAT1

Was ist, wenn wir die IKE SA der Verbindung erneuern möchten? Wir führen den folgenden CREATE_CHILD_SA- Austausch durch:

    SK {SA, Ni, KEi} ->
<- SK {SA, Nr, KEr}

wobei SA bereits IKE SA-Vorschläge enthalten wird und ein neuer SKEYSEED entwickelt wird :

PRF (SK_d_old, DH-KEY || Ni || Nr) -> SKEYSEED

Der ESP SA-Schlüssel wird entweder durch Erstellen einer neuen ESP SA (mit einem anderen SPI) und Löschen des alten oder durch Senden einer speziellen Benachrichtigung (siehe unten) aktualisiert. Die Umstellung des Datenverkehrs auf die Verwendung der neuen ESP SA ist transparent und verlustfrei. Für kurze Zeit werden die Parteien zwei aktive ESP-SAs haben, die die Verarbeitung von Verkehr ermöglichen, der noch auf Kommunikationskanälen übertragen wird.

Das Löschen einer ESP-SA erfolgt durch Senden einer DELETE- Nutzlast in nachfolgenden INFORMATIONAL- Austauschen, in denen die zu löschenden SPIs aufgeführt sind. Da alle ESP-SAs paarweise vorhanden sind (für bidirektionale Kommunikation), sendet jede Seite SPI-Werte nur an die ESP-SAs, die für den ausgehenden Verkehr verantwortlich sind. Empfangen Sie als Antwort SPI ESP SA-Werte für eingehenden Datenverkehr.

    SK {D (SPIi)} ->
<- SK {D (SPIr)}

Das Löschen einer IKE SA erfolgt ebenfalls über DELETE , jedoch mit einem IKE SPI und Akzeptieren einer leeren authentifizierten Antwort:

    SK {D} ->
<- SK {}

TLS 1.3 : Es gibt einen Mechanismus zum Drehen von Schlüsseln durch KeyUpdate- Nachrichten, es besteht jedoch keine Möglichkeit, zusätzliche Entropie hinzuzufügen oder DH durchzuführen. TLS ist eindeutig nicht für sehr langlebige Verbindungen ausgelegt. Im besten Fall können Sie die Sitzung nur unterbrechen und mit iPSK-ECDHE mit einem Handschlag eine neue Sitzung erstellen.

IKEv1 verfügt sowohl über ein separates Verfahren zur Erneuerung des IKE-Schlüssels als auch über ein separates Verfahren zur erneuten Authentifizierung. In IKEv2 findet keine erneute Authentifizierung statt. Dazu wird einfach eine neue IKE SA von Grund auf neu erstellt, die alte über DELETE gelöscht .

TLS 1.3 : verfügt über eine Post-Handshake-Clientauthentifizierungsfunktion, wenn zu einem beliebigen Zeitpunkt nach dem Handshake ( Fertig)Nachrichten von beiden Seiten) kann der Server eine Anforderung zur Clientauthentifizierung mithilfe eines X.509-Zertifikats senden. Zum Beispiel ging ein Kunde, der auf der Website herumwanderte, auf die Seite seines persönlichen Kontos. In IKEv2 ist dies nicht möglich - die Authentifizierung erfolgt nur zum Zeitpunkt des Handshakes.

BENACHRICHTIGEN

Wie werden Tunnel- / Transportmodi ausgehandelt, TFC? Zu diesem Zweck werden der Anforderung Nutzdaten von "Benachrichtigungen" NOTIFY ( N ) hinzugefügt . Allein im IKEv2-RFC gibt es Dutzende Arten von Benachrichtigungen. Warnungen werden verwendet, um Fehler, Probleme bei der Aushandlung von SAs für Vorschläge, Verkehrsselektoren usw.

zu signalisieren. Um den Wunsch zu signalisieren, den Transportmodus in einer ausgehandelten ESP-SA zu verwenden, wird sowohl vom Initiator als auch vom Antwortenden eine N- Benachrichtigung (USE_TRANSPORT_MODE) hinzugefügt, um die Modusaushandlung zu bestätigen. N (ESP_TFC_PADDING_NOT_SUPPORTED) Alarm signalisiert, dass TFC nicht unterstützt wird. Und N (HTTP_CERT_LOOKUP_SUPPORTED) gibt an, dass das Herunterladen eines Zertifikats von einer URL unterstützt wird.

Die Möglichkeit, den ESP-SA-Schlüssel zu aktualisieren, ohne neue ESP-SAs zu erstellen, ähnelt dem Verfahren zum Erstellen einer untergeordneten ESP-SA, der Initiator fügt jedoch eine N- Benachrichtigung (REKEY_SA) hinzu, die den SPI der aktuellen ESP-SA enthält:

    SK {N (REKEY_SA), SA, Ni, [KEi], TSi, TSr} ->
<- SK {SA, Nr, [KEr], TSi, TSr}

DPD

Der INFORMATIONSaustausch mit leerem SK wird für die Dead Peer Detection ( DPD ) als Herzschlag zwischen Dämonen verwendet. Wenn der IKE-Dämon längere Zeit nicht verfügbar ist, hat er höchstwahrscheinlich seinen Status verloren und daher beobachtet niemand die ESP SA auf der gegenüberliegenden Seite oder sie sind nicht mehr aktiv. Wenn klar ist, dass die Remote-Seite nicht verfügbar ist, ist es daher sinnvoll, alle zugeordneten ESP / IKE-SAs zu entfernen. Ein leerer SK bedeutet, dass keine Nutzdaten enthalten sind, aber authentifizierte Daten (mindestens IKE-Header mit Zählern) vorhanden sind. Die Authentifizierung eines solchen Pakets ist daher ein vertrauenswürdiges Lebenszeichen.

    SK {} ->
<- SK {}

Was aber, wenn eine Seite schnell neu gestartet wurde, den Status verlor und eine IKE-Verbindung von Grund auf neu aufbaute? Die andere Seite bemerkt möglicherweise nicht einmal, dass die andere nicht verfügbar ist, und sie würde denken, dass sie beschlossen hat, sich entweder erneut zu authentifizieren oder neue untergeordnete Sicherheitszuordnungen in einer anderen IKE-Verbindung zu erstellen. Nichts wird katastrophal sein, aber die alte ESP SA kann noch eine anständige Zeit leben. Ein Initiator kann einen N- Alarm (INITIAL_CONTACT) in seinen IKE_AUTH- Austausch einfügen , der signalisiert, dass dies die einzige bekannte IKE-Verbindung zu dieser Seite ist. Wenn Sie eine solche authentifizierte Benachrichtigung sehen, können Sie alle alten IKE / ESP-Sicherheitszuordnungen mit gutem Gewissen löschen.

DoS und schlechte KE

Bereits zu Beginn von IKE_SA_INIT wird eine KEi- Nutzlast mit einem kurzlebigen öffentlichen DH-Schlüssel gesendet . Der Initiator hat die IKE SA jedoch noch nicht ausgetauscht, und woher weiß er, welchen Algorithmus die empfangende Seite unterstützt? Es kann im Langzeitgedächtnis nur raten oder sich daran erinnern, was zuvor zur Zuordnung zu dieser Adresse verwendet wurde. Wenn der Responder den Algorithmus nicht unterstützt, sendet er N (INVALID_KEY_PAYLOAD) eine Benachrichtigung, die die Kennung des bevorzugten DH-Algorithmus angibt. Der Initiator muss seine Anfrage wiederholen, jedoch mit einem neuen KEi .

TLS 1.3: kann mit verschiedenen Algorithmen mehrere kurzlebige öffentliche Schlüssel gleichzeitig senden, möglicherweise reichen einige aus. Aber das sind Ressourcen und Verkehr. Möglicherweise sendet er den öffentlichen Schlüssel überhaupt nicht und der Server antwortet ihm mit HelloRetryRequest mit seinen Einstellungen. Das Plus ist, dass teure asymmetrische Kryptografie erst verwendet wird, wenn die bevorzugten Serveralgorithmen bekannt sind, jedoch auf Kosten eines zusätzlichen Roundtrips. Wenn der Client ursprünglich einen unangemessenen Algorithmus für öffentliche Schlüssel bereitgestellt hat, erhält er wie in IKEv2 eine HelloRetryRequest mit den zur Auswahl stehenden Algorithmen.

Was aber, wenn Sie dasselbe Anfangspaket vom Initiator senden? Dort kann jedes Mal ein neues SPIi generiert werden... Der Responder führt mindestens DH-Berechnungen ehrlich durch und antwortet mit IKE_AUTH . DH ist ein sehr ressourcenintensiver Vorgang, bei dem die CPU und die Entropiequelle verbrannt werden - der Transponder kann also beschädigt werden.

In IKEv2 (aber nicht in IKEv1) gibt es einen Schutz dagegen in Form einer Antwort N (COOKIE) mit einer Benachrichtigung, die eine Cookie-Zeichenfolge enthält. Danach muss der Initiator seine Anforderung wiederholen, aber diese N (COOKIE) -Nutzlast hinzufügen :

           SAi1, KEi, Ni -->
                         <-- N(COOKIE)
SAi1, KEi, Ni, N(COOKIE) -->
                         <-- SAr1, KEr, Nr, [CERTREQ]

Die Anfrage muss identischen SPI / Ni wie die erste haben. Es ist leicht genug, es mit Nutzlast zu ergänzen. Der Antwortende kann den Status der Verbindung zwischen der Anforderung und dem an ihn gesendeten Cookie speichern . Erst wenn diese übereinstimmen, kann der Antwortende nach Abschluss dieser Arbeit zum Hinzufügen des Cookies zur Anforderung durch den Initiator den IKE_AUTH- Austausch routinemäßig fortsetzen .

Es ist jedoch möglich, den Status direkt im Cookie zu speichern, wodurch er sich selbst authentifiziert. Es kann die Tatsache tragen, dass der Befragte die Anfrage des Initiators gesehen hat ( Ni und SPIi haben sie zumindest gesehen):

Cookie = MAC (ein Geheimnis, Ni || SPIi || Zeitstempel)

Daher muss der DoS-Liebhaber den Status speichern und seine wiederholten Nachrichten recyceln, was den Angriff viel teurer macht. Es ist nur dann sinnvoll, den Cookie-Schutz zu aktivieren, wenn der Verdacht eines DoS-Angriffs besteht, um nicht alle zu einer zusätzlichen Hin- und Rückfahrt zu zwingen.

TLS 1.3 : Hat ähnliche optionale Sicherheit. Der Server kann mit HelloRetryRequest mit einer Nachricht antworten , die die Cookie- Erweiterung enthält, die der Client in sein wiederholtes ClientHello2 einfügen sollte .

CP

Mit IKEv2 können Sie die Konfiguration von IP-Netzwerken / Adressen aushandeln. Mit Configuration Payload ( CP ) können Sie eine Anforderung zum Empfang einer Konfiguration ( CFG_REQUEST / CFG_REPLY- Pakettypen) stellen und die Konfiguration auf die gegenüberliegende Seite setzen ( CFG_SET / CFG_ACK- Typen). Die Konfigurationsanforderung enthält die Attribute, die die Partei kennen / festlegen möchte. Attribute können sein: "interne" Adresse, DNS-Adresse, DHCP, Subnetzkenntnisse oder andere in verwandten RFCs beschriebene Typen. Beispielsweise kann der Initiator im IKE_AUTH- Austausch eine Anfrage stellen, um ihm eine Intranetadresse (Verbindung zum Unternehmensnetzwerk) und einen DNS-Server zu erteilen:

    SK{IDi, [IDr], AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->
<-- SK{IDr,        AUTH, CP(CFG_REPLY),   SAr2, TSi, TSr}

CP(CFG_REQUEST) =
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
TSi = (proto=0, port=0-65535, :: - ffff:...:ffff)
TSr = (proto=0, port=0-65535, :: - ffff:...:ffff)

CP(CFG_REPLY) =
  INTERNAL_IP6_ADDRESS(2001:db8::5/64)
  INTERNAL_IP6_DNS(2001:db8::1)
  INTERNAL_IP6_SUBNET(2001:db8:abcd::/64)
TSi = (proto=0, port=0-65535, 2001:db8::5 - 2001:db8::5)
TSr = (proto=0, port=0-65535, 2001:db8::0 - 2001:db8::ffff:ffff:ffff:ffff)

Die Adresse 2001: db8 :: 5 wird dem Initiator zugewiesen .
ESP SA 2001:db8::/64 .
2001:db8::1 DNS .
2001:db8:abcd::/64 , , ESP SA, 2001:db8:: .

Go?

Um moderne inländische Implementierungen des IPsec-Stacks mit GOST-Algorithmen zu testen, haben wir beschlossen, eine völlig unabhängige Implementierung (von Linux, FreeBSD, strongSwan und anderen Stacks) zu schreiben. Und für eine schnelle und einfache Entwicklung in der Go- Sprache mit der bereits vorhandenen Implementierung der GoGOST- Bibliothek für GOST-Algorithmen . Zuvor hatte ich bereits Erfahrung mit der Integration von GOST in die TLS 1.3-Implementierung von crypto / tls- und crypto / x509 Go-Bibliotheken.

Das Gostipsec- Projekt ist freie Software, die aus zwei Dämonen besteht: ESPER (ESPv3) und IKER (IKEv2):

          ┌──────┐          ┌────┐          ┌─────┐          ┌────┐
          │remote│          │iker│          │esper│          │ipfw│
          └──┬───┘          └─┬──┘          └──┬──┘          └─┬──┘
             │                │                │               │
╔══════╤═════╪════════════════╪════════════╗   │               │
║ UDP  │     │                │            ║   │               │
╟──────┘     │    IKEv2...    │            ║   │               │
║            │ <───────────────            ║   │               │
║            │                │            ║   │               │
║            │    IKEv2...    │            ║   │               │
║            │ ───────────────>            ║   │               │
╚════════════╪════════════════╪════════════╝   │               │
             │                │                │               │
             │                │                │               │
             │    ╔═══════════╪══╤═════════════╪════════════╗  │
             │    ║ UNIX-SOCKET  │             │            ║  │
             │    ╟─────────────setkey-commands│            ║  │
             │    ║           │ ───────────────>            ║  │
             │    ╚═══════════╪════════════════╪════════════╝  │
             │                │                │               │
             │                │                │               │
             │                │   ╔════════════╪═══╤═══════════╪════════════╗
             │                │   ║ DIVERT-SOCKET  │           │            ║
             │                │   ╟──────────────encrypted ESP │            ║
             │                │   ║            │ <──────────────            ║
             │                │   ║            │               │            ║
             │                │   ║            │ decrypted ESP │            ║
             │                │   ║            │ ──────────────>            ║
             │                │   ║            │               │            ║
             │                │   ║            │ unencrypted IP│            ║
             │                │   ║            │ <──────────────            ║
             │                │   ║            │               │            ║
             │                │   ║            │  encrypted IP │            ║
             │                │   ║            │ ──────────────>            ║
             │                │   ╚════════════╪═══════════════╪════════════╝
             │                │                │               │

Im Moment funktioniert ESPER nur mit DIVERT- Sockets (ich fand unter Linux nichts so einfaches), daher wird es nur unter FreeBSD-Betriebssystemen (wahrscheinlich OpenBSD, nicht überprüft) unterstützt. ESPER verwendet wie IKER nicht PF_KEYv2 , für das C-Bindungen erforderlich wären, als Schnittstelle zwischen ESP <-> IKE- Bindungen, sondern die bereits am Anfang des Artikels erwähnte Text- Setkey- ähnliche Schnittstelle. IKER kann daher auch zum Aushandeln von Schlüsseln für eine Kernel-ESP-Implementierung verwendet werden, indem der eigentliche Befehl setkey aufgerufen wird . Diese Befehle für ESPER sehen folgendermaßen aus:

add fc00::ac fc00::dc esp 0x12345678 -u 123 -E aes-gcm-16 0xd3537e657fde5599a2804fbb52d1aaed94b65d3e ;
add fc00::dc fc00::ac esp 0x12345679 -u 234 -E aes-gcm-16 0x9a2dae68e475eacb39d41f23c3cbef890e9f6276 tfc:1320 ;

spdadd fc00::ac/128 fc00::dc/128 all -P in ipsec esp/transport//unique:123 ;
spdadd fc00::dc/128 fc00::ac/128 all -P out ipsec esp/transport//unique:234 ;

ESPER unterstützt: AES-128/256-GCM-16, Magma / Grasshopper-MGM, ESN, TFC, Transport- / Tunnelmodi, IPv6 / IPv4 (Unterstützung für letztere, viel komplexer, wurde nicht gründlich getestet und wer benötigt IPv4 für neue Projekte?), Schutz vor Wiederholungsangriffen. Mit IKER hingegen können Sie Folgendes anpassen: AES-128/256-GCM-16 + AES-XCBC + Kurve25519, Magma / Heuschrecke-MGM + HMAC-Stribog-512 + GOST R 34.10-2012-VKO-256/512, ESN / TFC / Transport / Tunnel-Modi, Authentifizierung mit digitalen PSK- und X.509-Signaturen (ECDSA, GOST R 34.10-2012). Konfiguriert durch eine einzelne Hjson- Datei:

{
    IKEAlgos: [
        gost128-vko512
        aes256gcm16-aesxcbc-curve25519
        aes128gcm16-aesxcbc-curve25519
    ]
    ESPAlgos: [
        gost128-esn
        gost64-esn
        aes256gcm16-esn
        aes256gcm16-noesn
        aes128gcm16-esn
        aes128gcm16-noesn
    ]
    SigHashes: [
        streebog512
        streebog256
        sha512
        sha256
    ]
    DPDTimeout: 300
    Peers: [
        {
            Autostart: true
            OurIP: fc00::dc
            TheirIP: fc00::ac
            OurId: our.company.net
            TheirId: CN=example.com
            OurTSS: [
                fc00::dc/128[tcp]
                fc00::dc/128[udp/53]
            ]
            TheirTSS: [
                fc00::ac/128
            ]
            Mode: transport
            # Won't be used, because of X.509 signature authentication
            PSK: DEADBABE
            TheirCertHash: a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
            OurCert: our.company.net.cer.pem
            OurPrvKey: our.company.net.key.pem
            TFC: 1200
        }
    ]
}

In diesem Beispiel haben wir das einzige Mitglied festgelegt, von dem wir wissen:

Mit welchem Daemon wird automatisch eine Verbindung hergestellt?
Führen Sie alle fünf Minuten eine Dead Peer-Erkennung durch
ESN, fallback- , TFC 1200 .
TCP DNS fc00::dc fc00::ac .
X.509 , CN=example.com subject- SHA256 SubjectPublicKeyInfo . OurId OurCert .
OurCert/OurPrvKey , PSK FQDN OurId.

IKER unterstützt noch nicht alle IKEv2-Funktionen ( CREATE_CHILD_SA , Rekeying), überwacht den Paketverlust nicht und kümmert sich nicht um das DON'T PANIC- Prinzip. Daher kann es noch nicht als Kandidat für eine "industrielle" Verwendung angesehen werden.

Tarball gostipsec enthält bereits alle Abhängigkeiten, kompilierte .info- Dokumentationen und Ziele für das Redo- Build- System , obwohl das Erstellen ausführbarer Dateien mit einem regulären Go-Build- Aufruf problemlos möglich ist .

Hjson?

Holywar-Thema, aber ich werde trotzdem mein Phi ausdrücken:

In INI können Sie solche Sweeping-Strukturen nicht angeben, und es gibt keinen Standard für INI- Dateien.
capabilities database , termcap-like, BSD , (, , ), C. IKER .
XML — .
JSON — , Python Go . , . - !
YAML — , , . , . , YAML , , , . . . - . YAML ( ) - ( StrictYAML ).
TOML — : , , , . , :
```
[[foo.bar]]
baz = 123

[[foo.bar]]
abc = 123
```
:
```
{
  "foo": {
    "bar": [
      {"baz": 123 },
      {"abc": 123 }
    ]
  }
}
```
«» / , . , TOML, NNCP , . , , .
Hjson — JSON ( , ), Hjson. github.com/hjson/hjson-go Hjson JSON, . . , . , JSON Hjson.

Wenn Sie eine Teilmenge von Funktionen implementieren, die TLS 1.3 ähneln (Authentifizierung nur durch PSK- und X.509-Zertifikate, keine ernsthafte Neuverschlüsselung), ist ESPv3 mit IKEv2 und IPv6 (es ist viel einfacher, damit zu arbeiten!) Aus Sicht des Programmierers etwas schwieriger in der Umsetzung. Der RFC ist nicht einmal verpflichtet, den Austausch von CREATE_CHILD_SA zu unterstützen . Die Sicherheit wird ohne die umstrittenen und gefährlichen möglichen Modi von TLS 1.3 ausgezeichnet sein. Die Leistung einer IPSec-Lösung ist im Allgemeinen aufgrund des Transports auf nuklearer Ebene und langlebiger IKE-Sitzungen höher.

Es ist ersichtlich, dass in IPSec alles geschärft wird, um die enorme Menge an Verkehr zwischen ganzen Netzwerken zu schützen, aber BTNS(Besser als nichts Sicherheit) Die IETF-Arbeitsgruppe hat mehrere RFCs verfasst, die zeigen, dass IPSec problemlos für Verbindungen pro Socket verwendet werden kann, bei denen eine der Parteien (der Client) anonym ist, wodurch die Zweckmäßigkeit der Verwendung von TLS vollständig in Frage gestellt wird. In diesem Fall würde die Verbindungsverriegelung es jeder Netzwerkanwendung ermöglichen, durch einen einfachen Systemaufruf wie setsockopt anzuzeigen, dass ein ESP für die Adresse FQDN = bank.com erforderlich ist, sich als X.509-Zertifikat präsentiert (oder anonym bleibt) und dann transparent, schnell und schnell Sicheres Arbeiten mit dieser bank.com , ohne Krücken in Form von Userspace-Transportbibliotheken pro Anwendung.

Sergey Matveev , Cypherpunk, Python / Go / C-Entwickler, Chefspezialist von FGUP STC Atlas.

Giblets IPsec messen wir gegen TLS 1.3, GOST und Go