🧘🏽 🚵🏾 🌈 Giblets IPsec, nous mesurons par rapport à TLS 1.3, GOST et Go 🚣🏽 ♨️ 🦂

Salutations! Je voudrais vous dire sur le périphérique du moderne IPsec pile de la ESPv3 et des protocoles IKEv2 . IPsec, me semble-t-il, contourne injustement de nombreux aspects et je n'ai pas vu d'analyse détaillée de son travail, de ses protocoles et de ses capacités en russe. De plus, je vais faire une chose étrange - comparer IPsec ESPv3 et IKEv2 (tous deux 2005) avec le TLS 1.3 de 2018 , moderne, branché et à la pointe de la technologie .

Pourquoi suis-je si passionné par IPsec - sans doute la pile de protocoles la plus complexe pour sécuriser les réseaux? Après tout, la complexité est le principal ennemi de la fiabilité et de la sécurité! Premièrement, plus vous en apprenez sur ses protocoles, en particulier IKEv2, plus vous comprenez combien de possibilités y ont été mises et plus vous êtes impressionné par sa prévenance, contrairement à l'approche courante des développeurs «une béquille entraîne une béquille» et la résolution de problèmes graves «jusqu'à ce que le tonnerre éclate». Deuxièmement, les protocoles IPsec sont bien pensés d'un point de vue cryptographique, et même l'ancien ESP / IKEv1, en fait, sont les seuls protocoles industriels utilisés en masse dans lesquels il n'y avait pas de vulnérabilités graves. Le même SSL (1995e année) n'est devenu décemment pensé qu'à partir de la version 1.3. Et beaucoup de gens n'aiment pas IPsec en raison de la complexité monstrueuse d'IKEv1,qui n'est plus dans la v2.

Idéalement, si les développeurs de systèmes d'exploitation n'ont pas ralenti en leur temps avec l'implémentation et l'implémentation d'IPsec et d' IPv6 (pour la disponibilité des ordinateurs, donc pas de NAT), alors aucun SSL / TLS n'aurait dû apparaître en principe. Le monde s'est avéré ne pas être parfait, mais maintenant IPsec prêt à l'emploi (au moins une partie SA / SP + ESP de la pile) est disponible dans au moins un système d'exploitation répandu (personnellement, je ne connais que DragonFly BSD , qui a bu IPsec en raison d'un manque de développeurs pour le supporter), et IPv6 dans certains pays développés est immédiatement disponible pour la grande majorité des gens.

IPsec est une pile de protocoles, d'appels d'API, de framework afin que les applications et / ou l'administrateur puissent dire de quelle sécurité ils ont besoin lors de la communication et cela serait assuré de manière transparente au niveau du réseau ( IP securité). On peut parler à la fois des paquets IP d'un seul socket (par exemple, les connexions TCP) et du trafic entre des réseaux entiers.

La sécurité du trafic signifie: assurer la confidentialité des données, leur authenticité / intégrité et leur protection contre les attaques par rejeu . Comme presque tous les protocoles, IPsec a une partie transport qui sécurise les paquets IP, et une partie handshake liée à la négociation des clés, des paramètres, de la configuration et de l'authentification des parties.

TLS 1.3 : fournit uniquement une protection des données par socket pour les connexions TCP. DTLS peut fournir une protection pour les datagrammes (DTLS 1.3 n'est pas encore une norme), mais toutes les bibliothèques ne le prennent pas en charge.

Protocoles de transport

Le transport IPsec utilise les protocoles IP:

AH (en-têtes d'authentification). Je ne parlerai pas plus de AH, car il n'assure pas la confidentialité des données et, d'après ce que j'ai entendu, il a été fait uniquement pour "supporter" les lois de certains pays dans les années 1990 sur les restrictions à l'utilisation du cryptage. Le chiffrement est si léger par rapport à tout le reste qu'il n'est pas logique de le sacrifier. Mais presque partout où ESP est mentionné, AH est également mentionné.
ESP (encapsulation des charges utiles de sécurité). ESP a légèrement évolué au fil du temps et utilise désormais sa version ESPv3, qui est souvent rétrocompatible et ne diffère pas de la version précédente.

Le trafic IP est sécurisé uniquement par la couche de transport. Et comme on peut parler de plusieurs millions de paquets par seconde, de facto ESP est implémenté au niveau du noyau du système d'exploitation, au moins dans sa pile réseau, afin de ne pas faire de basculement de contexte coûteux entre le noyau et l'espace utilisateur (comme cela se produit normalement avec TLS , SSH, OpenVPN et autres).

Je souligne que AH et ESP sont des protocoles de couche IP, réseau, pas de transport. Pourquoi pas UDP? La somme de contrôle est redondante et brûle le processeur, et la cryptographie garantira de toute façon l'intégrité. Mais, si votre NAT ne sait rien sur ESP (et il ne le sait pas), alors tout cela ne fonctionnera pas pour lui. Plus tard, ils ont proposé des béquilles NAT-T (Traversée NAT), lorsque le trafic IPsec est enveloppé dans un paquet UDP sur le port 4500 et pourra passer par NAT, mais il s'agit d'une surcharge inutile et de la nécessité de modifier la pile IPsec dans le noyau, car il doit déjà comprendre ces paquets UDP spéciaux et en extraire ESP pour cela traitement régulier.

SP, SA, SPI et notre premier cryptage IPsec

Comment le noyau sait-il quoi faire avec un paquet IP: s'il faut le crypter à l'aide d'une clé, décrypter l'ESP entrant ou le laisser passer sans le toucher? Pour ce faire, le noyau dispose de politiques de sécurité ( SP ). Ce sont des règles comme dans un pare-feu. En plus d'eux, le noyau contient des associations de sécurité ( SA ): des contextes pour effectuer des opérations cryptographiques (clés, compteurs, relecture de fenêtre, etc.). En général, ni les SP ne sont spécifiques à IPsec ni les SA - ils peuvent être utilisés pour d'autres tâches / protocoles (par exemple OSPF).

SP / SA peut être configuré soit via une API spéciale ( PF_KEYv2 ), soit manuellement via un utilitaire setkey . Par exemple, si nous voulons dire au noyau que tous les paquets IP provenant deLes adresses fc :: 123 sur fc :: 321 doivent être sécurisées via ESP, cela peut être facilement fait en appelant à partir de la ligne de commande:

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

Avant cette commande, nous avons vu des 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

Nous ne le verrons pas plus tard, car le noyau ne sait pas encore "quoi" crypter. Vous devez ajouter SA, et cela peut également être fait manuellement, en définissant l'algorithme de cryptage AEAD et une clé aléatoire de 160 bits pour plus de simplicité AES-GCM-16 :

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

Si nous exécutons les mêmes commandes sur l'hôte distant (sans oublier de spécifier -P in ), nous verrons:

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

La demande est chiffrée par ESP, mais la réponse ne l'est pas. Parce que ESP fonctionne par défaut dans "un sens" et pour la communication bidirectionnelle, vous devez ajouter un autre SP / SA pour la direction opposée.

0xdeadbabe dans cet exemple est l'indice des paramètres de sécurité ( SPI ) - un identifiant unique pour le "tunnel" ESP entre deux adresses IP, auquel le noyau peut trouver le contexte SA correspondant et en extraire la clé de déchiffrement. Et esp / transport // require est une exigence pour utiliser ESP en mode transport (plus à ce sujet ci-dessous).

Giblets ESP

Le package ESP est structuré schématiquement comme suit:

  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 - identifiant unique 32 bits pour la session / tunnel / connexion ESP entre les adresses IP. En général, {SrcIP, DstIP, SPI} est le SA et le contexte cryptographique.
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).

La partie entière du paquet de la charge utile à l'en- tête suivant est chiffrée. Tout sauf le MAC est authentifié. La longueur de l'ICV, la présence d'un IV (vecteur d'initialisation) dépend des modes / algorithmes de cryptage et d'authentification utilisés.

TLS 1.3 : le remplissage optionnel des données à une taille donnée n'apparaissait que dans la version 1.3. Sinon, le cryptage et l'authentification sont complètement similaires. TLS 1.3 oblige à n'utiliser que des algorithmes AEAD, ce qui est correct et bon. ESP prend en charge AEAD, mais il existe un choix de solutions plus archaïques. Saisissez les champs SPI ou SeqNumnon, puisque TCP garantit la séquence et la livraison, de plus, en pratique, aucun vecteur d'initialisation n'est explicitement transmis - le paquet de la couche d'enregistrement TLS est donc légèrement plus court. DTLS contient déjà SeqNum ainsi que des données de fragmentation des messages.

Le numéro de paquet de 32 bits peut être trop court dans la pratique. Il ne s'agit que de 4 milliards de paquets IP qui, à des vitesses de plus de 10 Mpps, peuvent voler en quelques minutes. Que se passe-t-il lorsque le compteur déborde? Il sera remis à zéro. Mais cela signifie que la valeur de SPI + SeqNum commencera à se répéter pour nous et que les paquets ESP précédemment interceptés pourront être utilisés pour rejouer l'attaque. Pour résoudre ce problème, ESN a été inventé(Numéro de séquence étendu). Il s'agit d'un compteur 64 bits, mais seuls les 32 bits «inférieurs» sont transférés dans le champ SeqNum et les 32 bits supérieurs sont stockés en mémoire. La valeur totale de l'ESN est authentifiée - par conséquent, les parties sont obligées de convenir à l'avance de l'utilisation d'ESN.

Cryptage ESP

Comment se déroule exactement le cryptage / l'authentification d'un paquet ESP, par exemple, lors de l'utilisation d'AES-GCM-16? Pour travailler avec ESP, il utilise un vecteur d'initialisation 64 bits situé au début de la charge utile . Il utilise également du sel 32 bits dans le cadre du matériel clé. Dans l'exemple de setkey, je n'ai pas fourni de clé de 128 bits, mais une clé de 128 + 32 bits. Il peut y avoir des situations où la clé est réutilisée et l'IV est rempli d'un mauvais générateur de nombres pseudo aléatoires (PRNG) dont les valeurs peuvent être répétées. Le sel est conçu pour se protéger contre ce cas le plus dangereux, qui conduit potentiellement au décryptage des paquets interceptés. Le cryptage / authentification ESP lui-même en mode AES-128-GCM-16-ESP est le suivant:

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

Pour les algorithmes russes GOST (chiffrements Magma ou Grasshopper), les données d'entrée sont similaires. Les deux chiffrements sont utilisés en mode MGM (je dirais une version améliorée de GCM ), et la rotation régulière du matériau de la clé ESPTREE est appliquée à l' aide de HMAC-Stribog-256. Cela réduit la charge sur la clé. Principalement dans le contexte d'IPsec, il ne s'agit pas tant d'augmenter son temps d'utilisation que de réduire la surface d'attaque via des canaux latéraux. Par exemple, en raison du maillage de clé (une technologie similaire de rotation de clé constante), le chiffrement par blocs GOST 28147-89 avec une taille de bloc de 64 bits s'est avéré invulnérable à l' attaque SWEET32 .

Du point de vue de la sécurité, il n'y a aucune plainte concernant l'ESP avec les algorithmes AEAD. Mais pour les algorithmes AEAD, IV n'est qu'un compteur 64 bits, passé explicitement avec chaque paquet qui gaspille de l'espace dans le paquet. SeqNum est trop court et ESN n'est pas entièrement transmis, bien qu'il convienne complètement en IV. Pour les algorithmes non AEAD, IV peut déjà être nécessaire et porter une valeur imprévisible, mais en aucun cas un compteur. C'est un héritage, qui ronge un espace précieux dans l'emballage et le poids n'affecte pas la fiabilité ici.

Si IV pour les AEAD pouvait avoir des valeurs de 128 bits, il serait alors possible d'utiliser des algorithmes comme XSalsa20 / XChaCha20 avec un nonce de 192 bits, dont 128 bits sont générés de manière pseudo-aléatoire au démarrage, et les 64 bits restants peuvent être utilisés pour le compteur ... Cela pourrait sauver la vie des systèmes qui ont perdu leur état de compteur, mais qui souhaitent continuer à utiliser les clés existantes.

TLS 1.3 : XOR est utilisé comme un nonce entre le compteur de messages et le vecteur d'initialisation généré avec la clé. Puisque ni le compteur ni le IV ne sont explicitement transmis, TLS 1.3 est un peu plus compact. Si ESP utilise des algorithmes non AEAD, ils peuvent nécessiter la génération d'un IV imprévisible, ce qui peut être considérablement gourmand en CPU.

Tunnel et modes de transport

Qu'est-ce qui est inclus dans la charge utile du package? Cela dépend du fait que l'ESP fonctionne en mode transport ou en mode tunnel . Le mode de transport remplace la charge utile du paquet IP transmis par un ESP avec cette charge utile. Autrement dit, c'était:

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

devenu:

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

En mode tunnel, le paquet IP entier est complètement enveloppé dans ESP et un nouveau paquet IP est formé, généralement avec de nouveaux en-têtes et adresses SrcIP / DstIP. Ce mode est utilisé pour acheminer les paquets entre les réseaux.

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

Par exemple, via setkey, je peux spécifier que tous les paquets entre les réseaux 2001: ac :: / 64 et 2001: dc :: / 64 doivent passer cryptés via deux extrémités de tunnels avec des adresses 2001 :: 123 , 2001 :: 321 ...

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 ;

Le mode de transport est souvent appelé connexion d'hôte à hôte. Si un protocole GRE ou IPv * -over-IPv * est utilisé pour le tunneling, qui fonctionne déjà entre deux points de terminaison, alors cela n'a aucun sens, dans ce cas, d'utiliser le mode tunnel au niveau IPsec. Cependant, le mode de transport n'authentifie pas l'en-tête IP. En règle générale, cela n'est ni important ni critique, mais si vous voulez vous assurer qu'aucun en-tête IPv6 étendu ou étiquette de flux de paquets n'a été modifié, vous devez utiliser le mode tunnel, même si entre deux hôtes, au prix d'une surcharge.

ISAKMP

Que se passe-t-il si je redémarre des ordinateurs, que SA avec toutes les valeurs de compteur disparaissent de leur mémoire et que je charge à nouveau les anciennes commandes SP / SA avec mes mains? Premièrement, les paquets qui correspondent à l'IV peuvent être déchiffrés, car cela revient à utiliser le pavé de chiffrement deux fois. Deuxièmement, puisque SPI / salt / ESN / SeqNum correspond, tous les paquets précédemment interceptés seront valablement authentifiés et vous pourrez les rejouer. La réutilisation de ces SA setkey est désastreuse pour la sécurité. Troisièmement, surtout si ESN n'est pas utilisé (par exemple, dans FreeBSD au moment de la rédaction de cet article, il n'est pas encore pris en charge), avec une longue opération SA, vous ne remarquerez peut-être pas que le compteur est «épuisé».

Tout cela signifie que nous devons changer régulièrement les clés ESP. Et aussi négocier un algorithme de cryptage, la présence d'ESN, TFC, mode transport / tunnel, valeurs SPI. De facto, le protocole ISAKMP (Internet Security Association and Key Management Protocol) est utilisé pour cela . Cependant, vous pouvez facilement visser une messagerie instantanée avec un cryptage authentifié OTR / PGP / OMEMO et simplement envoyer les commandes setkey du script shell au serveur, dans lequel les clés sont générées en lisant / dev / urandom . La manière dont cela a été convenu n'a pas d'importance pour le noyau. Comme dans OpenVPN: l'authentification X.509 avec des certificats et la négociation de clés ont généralement lieu via TLS, et le protocole de transport VPN lui-même est déjà le sien.

Dans sa forme "pure", ISAKMP n'est pas utilisé, car il ne contient pas de cryptographie. Pour authentifier les interlocuteurs et générer du matériel clé, un protocole tiers est utilisé qui encapsule ISAKMP en lui-même. Je connais:

KINK - Négociation Internet Kerberisée des clés , où un troisième KDC Kerberos approuvé est utilisé pour l'authentification et la négociation. En plus de la description de Wikipedia, je ne sais rien de plus sur KINK et je ne l'ai pas vu en direct.
IKE (v1) - Échange de clés Internet . Probablement toujours le protocole le plus populaire, même s'il a été créé en 1998.
IKEv2 est la deuxième version d'IKE, 2005, dont je vais parler.

Les protocoles IKE sont très extensibles en raison du grand nombre de types de charges utiles différents. IKEv1 dispose d'un grand nombre d'options pour configurer un seul tunnel pour qu'il fonctionne. Plus d'une douzaine de RFC décrivant l'ensemble de ISAKMP et IKEv1 avec des charges utiles communes. Complexité intimidante. De plus, la possibilité de bousiller facilement des configurations non infaillibles et le mythe bien connu, en partie à juste titre, selon lequel IKEv1 ne fonctionnera que si, presque complètement, copiez le fichier de configuration.

Heureusement, IKEv2 est apparu: un RFC pratique (pour la plupart des fonctionnalités), un protocole considérablement simplifié pour la négociation des paramètres et, par conséquent, sa configuration. En règle générale, il a moins d'aller-retour pour l'ensemble du processus de prise de contact et d'accord de clé que dans IKEv1. Par conséquent, lui seul sera pris en compte, car il n'y a plus de sens dans IKEv1 (mais il ne vaut guère la peine de chercher à remplacer les instances déjà en cours d'exécution et en fonctionnement, car elles fonctionnent). IKEv2, contrairement à IKEv1, utilise des algorithmes et des approches absolument similaires pour crypter ses propres messages comme le fait ESP. Il a également introduit l'authentification EAP et la possibilité pour chaque partie de s'authentifier avec différentes méthodes (par exemple, le client utilise PSK et le serveur X.509 utilise des certificats).

Démon IKE

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

Cette partie de la pile IPsec est déjà en cours d'exécution, généralement dans l'espace utilisateur. Premièrement, ce ne sont pas des démons très chargés: ils peuvent communiquer entre eux au moins une fois par jour, et la prise de contact initiale prend quelques allers-retours via UDP. Deuxièmement, le nombre de capacités ISAKMP / IKE est tel qu'il y a des centaines de fois plus de code que dans l'implémentation SA / SP / ESP complète. Il existe de nombreux démons ISAKMP: strongSwan (IKEv1 / v2) (ainsi que Openswan , Libreswan ), isakmpd (IKEv1), OpenIKED (IKEv2), racoon (IKEv1), racoon2 (IKEv1 / v2, KINK) et autres.

Remarque: correct d'écrire et de dire «Démons» ( démons), comme je l'ai vu dans les traductions de fiction. Mais dans les cercles techniques russophones, les «démons» ont déjà pris racine.

TLS 1.3 : en général, toute la pile TLS est constituée de fonctions de bibliothèque qui fonctionnent dans chaque application individuelle et stockent les éléments clés dans sa propre mémoire. Toute la cryptographie se fait avec le passage à l'espace utilisateur, ce qui représente une surcharge énorme. Cependant, au moins FreeBSD et Linux ont déjà des implémentations de déchargement du noyau de TLS, lorsque, comme IPsec, la partie transport est entièrement traitée dans le noyau et la négociation a lieu dans l'espace utilisateur.

IKEv2 s'exécute sur UDP, sur le port 500 par défaut ( isakmpun service). Les démons créent un canal sécurisé, s'authentifient les uns les autres, négocient / créent / suppriment des SA / SP ESP, mettent à jour les clés, font des pulsations (Dead Peer Detection ( DPD )) et bien plus encore. Toutes les communications entre les démons ont lieu sous la forme d'un échange d'une paire de messages de demande / réponse. Toute demande doit recevoir une réponse. Puisqu'il s'agit d'UDP, que faire si un paquet est perdu? Tenez-en compte dans votre état, renvoyez les demandes après l'expiration du délai pour lequel aucune réponse n'a été reçue, renvoyez les réponses aux demandes répétées, ignorez les réponses répétées. Les paquets peuvent arriver dans un ordre chaotique, ils peuvent disparaître de manière imprévisible - beaucoup est pris en compte dans la norme IKEv2 et il est décrit comment se comporter dans diverses conditions de course.

TLS 1.3: La nature TCP de TLS s'occupe de la commande et de la livraison des messages. Mais TCP occupe des ressources importantes dans le noyau du système d'exploitation et un grand nombre de sessions TCP peut être un problème (contrairement à UDP). Mais dans DTLS, tous les problèmes similaires se poseront de la même manière que dans IKE, plus les hémorroïdes avec le traitement des messages fragmentés seront ajoutées. La modification des adresses IP des points de terminaison pour UDP n'est pas un problème. Les connexions IKE, en règle générale, ont une durée de vie très longue (l'état IKE est petit et n'est stocké que dans la mémoire du démon de l'espace utilisateur) et nécessitent donc une poignée de main moins souvent, alors qu'en TLS, après avoir perdu une connexion TCP, vous devrez le faire (bien qu'il existe également des méthodes accélérées de poursuite des sessions si l'état n'était pas perdu, par exemple lors du redémarrage du programme). Étant donné que le démon IKE est un pour l'ensemble du système (en règle générale), alors si une application veut communiquer en toute sécurité avec celaavec quelqu'un qui a déjà une connexion IKE, il peut soit l'utiliser immédiatement, soit le démon, en un aller-retour, créera une ESP SA supplémentaire pour l'application.

Giblets IKE

Le premier échange (demande-réponse) des démons sera IKE_SA_INIT , qui crée une SA IKE pour une communication sécurisée supplémentaire. Notez que la SA ESP est "stockée" dans le noyau et que la SA IKE est dans le démon de l'espace utilisateur. Vient ensuite l' échange IKE_AUTH , où les parties sont authentifiées. Dans le même échange, une SA enfant (SA enfant ) est créée, qui est utilisée pour ESP SA. En général, ces deux échanges suffisent à authentifier les parties et à négocier les paramètres ESP SA avec les clés puis à piloter le trafic ESP crypté entre ordinateurs. Dans ce cas, une SA IKE en état de fonctionnement reste longtemps entre les démons. De plus, à tout moment, ils peuvent effectuer un échange CREATE_CHILD_SA , pour créer plus d'associations de sécurité enfants, ainsi que des informationséchange (diverses fins).

Tous les en-têtes de message IKEv2 ont la structure suivante:

                     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 - SPI d'initiateur SA IKE 64 bits. Un identifiant généré aléatoirement par l'initiateur de la session IKE.
SPIr - SPI de répondeur SA IKE 64 bits. De même, mais uniquement SPI du côté du répondeur. Dans le tout premier message de l'initiateur, ce champ est rempli de zéro octet.
NP - Charge utile suivante 8 bits. L'identifiant de la charge utile suivant l'en-tête.
Version - version 8 bits du protocole IKE.
ExchType - type d'échange IKE 8 bits: IKE_SA_INIT , IKE_AUTH , CREATE_CHILD_SA ou INFORMATIONAL .
Flags — 8- . .
MsgID — 32- . , , replay-. — request/response MsgID. , .
Len — 32- ( + ).

SPIi + SPIr sont de 128 bits. Pourquoi autant quand ESP n'a alloué que 32 bits? Premièrement, comme ils ne correspondent pas, mais sont générés de manière pseudo-aléatoire, 64 bits pour un côté suffiront pour éviter les collisions. Deuxièmement, ESP est également lié aux adresses IP, alors qu'une session IKE ne l'est généralement pas - les parties peuvent facilement changer leurs adresses IP (client mobile) et continuer à communiquer.

TLS 1.3: La modification de l'adresse IP déconnectera la connexion. Vous devrez effectuer un rehandshake, même avec iPSK, en économisant sur les ressources pour la cryptographie asymétrique, c'est 1,5 aller-retour plus des allers-retours pour établir une connexion TCP. La création de SA ESP enfants sur de nouvelles adresses IP, dans une connexion IKE déjà établie (non liée aux adresses), ne nécessitera qu'un aller-retour (+ aller-retour pour supprimer les anciennes, mais cela se produira déjà en arrière-plan d'une nouvelle SA ESP qui fonctionne).

L'en-tête IKE est suivi d'une ou plusieurs charges utiles. Chaque charge utile a un en-tête de format général, puis un contenu spécifique à son type. Le contenu est aligné sur 32 bits. Un en-tête commun pour tous:

                     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 ( + ).

Ainsi, les messages IKE se composent d'un en-tête IKE et de charges utiles liées ensemble dans une chaîne. Les démons peuvent ignorer les charges utiles non critiques et inconnues. Le contenu de la charge utile du type Nonce (après l'en-tête) est juste un ensemble aléatoire de données, pas une taille fixe. Mais il existe aussi des structures beaucoup plus complexes. Dans les normes IKE, les désignations courtes des types de charge utile sont acceptées (par exemple, N * pour les messages nonce, où "*" est "i" (initiateur) ou "r" (répondeur)).

SIGMA

D'un point de vue cryptographique, IKEv1 / IKEv2 appartiennent à la classe STS, ISO / CEI IS 9798-3 et SIGMA (SIGn-et-MAc) des protocoles d'échange de clés authentifiés. Ce sont des solutions très bien étudiées et vérifiées mathématiquement (SIGMA). Dans mon article «P2P F2F E2EE IM en une soirée», j'ai déjà décrit le principe de fonctionnement et de mise en œuvre du protocole SIGMA-I. IKEv2 est complètement similaire. Lorsque nous discutons de la sécurité du protocole de prise de contact, à quoi nous attendons-nous?

confidentialité des messages transmis;
authenticité et intégrité des messages transmis - leur modification doit être détectée;
protection contre les attaques par rejeu - le fait de perdre ou de rejouer des messages doit être détecté;
;

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

/ ( ) IKE . / ( ) ;

, , . .

Après un tel échange IKE_SA_INIT , les démons ont les adresses les uns des autres, SPIi + SPIr la valeur de la session IKE, les algorithmes négociés par SA (dans le cas d'IKE, il s'agit d'un accord de clé ( DH ), de chiffrement / authentification de message ( ENCR ), d'algorithmes de génération de clé ( PRF )), la clé publique (DH) du côté opposé. Cela suffit pour enregistrer l'état en mémoire et effectuer un accord de clé (Diffie-Hellman, GOST R 34.10-VKO, curve25519, etc.), générant une clé symétrique pour crypter la charge utile des messages IKE suivants.

TLS 1.3: le format des messages de prise de contact est très différent, il y a beaucoup d'héritage, mais fondamentalement rien qui ressort. Le champ aléatoire est utilisé à la place de nonce. Au lieu de charges utiles, de nombreuses extensions. Au lieu d'une structure de proposition SA complexe, des identificateurs de suites de chiffrement sont utilisés, ce qui est plus compact et plus simple. À mon avis, la flexibilité des propositions SA est excessive, mais dans IKEv2 ce n'est toujours pas un problème et des valeurs similaires à ciphersuite sont écrites dans le fichier de configuration. L'échange DH devient obligatoire uniquement avec la version TLS 1.3.

Matériel clé IKE

Après IKE_SA_INIT , SKEYSEED est généré :

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

L'algorithme PRF est sélectionné dans la SA IKE. Par exemple, pour GOST IKEv2, il s'agit de la fonction HMAC-Stribog-512. La clé PRF est un morceau de 64 bits de chaque nonce.

Cela semble frivole, car les nonces sont transmis ouvertement, ce qui signifie que la clé de ce PRF est connue de quiconque a intercepté le trafic. Mais PRF sert ici exclusivement à générer une clé à partir du résultat DH-KEY du calcul de DH , déjà inconnu de l'attaquant . Le résultat de la fonction DH peut être une valeur d'entropie énorme et inégale, cela peut être un point sur une courbe elliptique - tout cela ne peut pas être utilisé comme une clé symétrique courte à haute entropie. Par conséquent, vous devez extraire l' entropie de DH-KEY (il ne s'agit que de SKEYSEED ), puis développer (expand ) jusqu'au nombre de clés requis:

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)

Tout cela est une opération de dérivation de clé classique avec des étapes d' extraction / expansion , similaire à la fonction HKDF . Mais si HKDF suppose l'utilisation de fonctions de hachage, alors cette construction PRF / PRF + peut être utilisée simplement avec des chiffrements symétriques - dans le cas du courant AES-GCM + AES-XCBC-PRF, nous n'utiliserons pas du tout de fonction de hachage, mais un petit nombre les primitives utilisées sont toujours bonnes.

Les clés suivantes sont générées:

SK_d clé pour générer des clés pour les SA ESP enfants.
SK_a [ir] clés pour l'authentification de message IKE. Non généré / non utilisé si l'algorithme AEAD est accepté (AES-GCM, Grasshopper / Magma-MGM, ChaCha20-Poly1305, etc.).
SK_e[ir] IKE .
SK_p[ir] AUTH.

TLS 1.3: a une planification des clés beaucoup plus complexe. L'entropie est extraite de l'ensemble des messages de prise de contact à la fois, plutôt que des champs individuels. La séquence étendue générée n'est pas seulement découpée en un certain nombre de clés (+ sel pour celles-ci si nécessaire), mais également accompagnée de transformations HMAC avec des étiquettes (étiquettes) pour chaque contexte d'utilisation de ces clés ou IV générées. Utiliser une étiquette textuelle / une application / un contexte pour tout type de valeur générée est une bonne pratique moderne et est plus facile à faire que de se demander si vous en avez besoin. Hacher tout ce qui se présente est également une très bonne pratique, "ça ne va pas empirer". Cependant, cela ne signifie pas que la sécurité d'IKEv2 est pire, ou que l'on peut facilement trouver au moins une situation théorique à distance où l'absence d'étiquette peut être entre les mains d'un attaquant.Dans IKEv2, l'approche est minimale, alors que dans TLS 1.3, il est "préférable de passer outre" (car combien de montants ou de difficultés ont été réalisés dans les versions précédentes du protocole!). IKEv2 utilise toujours des approches et des primitives éprouvées, authentifie tout ce qui est nécessaire, serre / prend en compte toute l'entropie transférée, utilise des clés différentes pour chaque côté et tâche.

IKE_AUTH

Ensuite, un échange IKE_AUTH est effectué , authentifiant les deux côtés et négociant l'ESP SA:

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

Les messages IKE contiennent une charge utile chiffrée ( SK ), qui contient toutes les autres.
L'initiateur fournit son identifiant ( IDi ), son authentificateur ( AUTH ), l'offre SA pour ESP ( SAi2 ) et une paire initiateur / répondeur, appelés sélecteurs de trafic ( TS * ). Il peut également éventuellement envoyer l'identifiant de répondeur attendu, qui peut être considéré comme une sorte d'analogue SNI de TLS.
En réponse, il reçoit l'ID du répondeur, la proposition d'ESP SA négociée, les sélecteurs de trafic confirmés et l'authentificateur.
Après cela, les deux parties se considèrent comme authentifiées, ont un accord sur ESP SA, le trafic qui doit appartenir à cet ESP, et peuvent déjà émettre une commande au noyau pour créer SA et, éventuellement, SP (il existe des démons qui ne traitent pas du tout avec SP).

Maintenant, plus en détail sur ces charges utiles:

ID - identifiant du parti. Contient le type d'identification et les données qui lui sont spécifiques. Les parties peuvent être identifiées de nombreuses manières: adresse IPv4 / IPv6, FQDN (nom de domaine complet, juste une chaîne, le moyen le plus courant), adresse e-mail RFC822, nom distinctif ASN.1 DER (le moyen le plus courant lors de l'utilisation de certificats X.509) ou nom général ainsi que spécifique au fournisseur.
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 .

Le répondant envoie sa sélection confirmée de sélecteurs, qui correspondent ou peuvent avoir des plages de sélection plus étroites.

Toutes ces charges utiles sont chiffrées sur la clé générée par la SA IKE après le premier échange de messages. Le cryptage est nécessaire pour masquer les identifiants des parties transmises, leurs certificats et d'autres informations privées à l'air libre. Cependant, un attaquant actif peut se coincer dans le premier échange IKE_SA_INIT et voir ces informations, bien qu'il ne soit plus en mesure de poursuivre la session.

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-.

Le chiffrement de la charge utile SK avec des chiffrements AEAD n'est pas délicat et est complètement similaire à ESP, par exemple, pour AES-GCM (dans lequel, comme AES-GCM-ESP, le sel fait partie du matériau clé):

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

Authentification avec EDS

Que faire si une partie souhaite s'authentifier avec une signature et des certificats X.509? Pour cela, déjà dans IKE_SA_INIT , une charge utile CERTREQ peut être envoyée , demandant au côté opposé de fournir un certificat sous la forme de charges utiles CERT . CERT et CERTREQ contiennent l'identificateur de format de certificat et le contenu spécifique au format. En général, les certificats peuvent être présentés sous forme de ASN.1 DER ou de hachage SHA1 du certificat + URL à partir de laquelle il peut être téléchargé. Étant donné que la taille d'UDP est limitée par MTU et que les tailles des certificats peuvent être beaucoup plus grandes, l'option hash + URL est ici salutaire (bien qu'elle puisse être considérée comme une béquille).

Le RFC IKEv2 seul répertorie, en plus des certificats X.509 encodés DER et des URL SHA1 +: certificat X.509 encapsulé PKCS # 7, certificat PGP, clé signée DNS, certificat SPKI, certificat d'attribut X.509, clés publiques brutes. Si vous souhaitez utiliser IPsec de la même manière que le cas d'utilisation le plus courant TLS: un serveur authentifié par un certificat X.509 et un client anonyme, alors dans IKEv2, il n'y a aucun moyen de ne pas authentifier l'une des parties. Mais la RFC 5386 décrit une approche Better-Than-Nothing-Security où le «client» peut utiliser la clé publique nue et le serveur peut la traiter comme anonyme.

En outre, l'authentification EAP est prise en charge en standard, ajoutant des allers-retours à IKE_AUTHéchange. EAP peut à la fois dire si la partie est authentifiée ou non, et générer une clé que IKEv2 prendra en compte et utilisera. Je vais seulement vous montrer un diagramme de la façon dont le PAE peut fonctionner:

                 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 : dans celui-ci, la signature (ou MAC dans le message Terminé ) est placée au-dessus du hachage de tous les messages vus qui ont participé à la prise de contact. Aussi une bonne approche simple et fiable. Il n'existe aucune variété de méthodes d'authentification. Mais j'aimerais voir un protocole PAKE (Authenticated Password Key Agreement) fort, tel que le russe SESPAKE ou OPAQUE .

Matériel clé ESP SA et son renouvellement

Nous avons donc vérifié l'authentification, vérifié que l'accord de clé était correct, négocié l'ESP SA et les sélecteurs de trafic. Il reste à générer des clés symétriques pour ESP et le SA / SP requis peut être installé dans le noyau:

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

La communication bidirectionnelle nécessite deux SA ESP, donc IKEv2 génère deux éléments clés à la fois, qui sont déjà transmis directement au cœur de l'association SA correspondante. La longueur du matériau dépend de l'algorithme ESP utilisé (par exemple, AES-GCM-ESP nécessite, en plus de la clé, également un sel de 32 bits). La valeur SPI est la valeur SPI spécifiée par chaque partie dans les propositions d'ESP SA.

Que faire si nous devons nous mettre d'accord sur plusieurs ESP SA / SP, par exemple, parce que tous les souhaits ne peuvent pas être spécifiés dans une seule paire TSi / TSr ? Pour cela, des échanges CREATE_CHILD_SA sont utilisés qui se produisent à tout moment après IKE_AUTH . La création d'une SA enfant se produit dans l'échange suivant:

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

Une offre SA est faite, des nonces, des sélecteurs de trafic sont envoyés. Tout est comme avant. Le matériel clé est déjà généré à l'aide de ces nouveaux nonces. En option, vous pouvez utiliser des charges utiles d'échange de clés, qui ajoutent de l'entropie et obligent les parties à utiliser une cryptographie encore plus asymétrique. Il peut être nécessaire d'observer constamment la propriété PFS (dans le protocole OTR , des clés DH éphémères sont envoyées avec chaque message). Le matériel clé dans ce cas sera élaboré comme suit:

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

Que faire si nous voulons renouveler la SA IKE de la connexion? Nous effectuons l' échange CREATE_CHILD_SA suivant :

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

où SA contiendra déjà des propositions d'IKE SA et un nouveau SKEYSEED sera développé :

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

La clé ESP SA est mise à jour soit en créant une nouvelle ESP SA (avec un SPI différent) et en supprimant l'ancienne, soit en envoyant une notification spéciale (à ce sujet ci-dessous). Le passage du trafic à l'utilisation de la nouvelle ESP SA sera transparent et sans perte. Pendant une courte période, les parties disposeront de deux SA ESP actives, ce qui permettra de traiter le trafic encore en transit sur les canaux de communication.

La suppression d'une ESP SA se fait en envoyant une charge utile DELETE dans les échanges INFORMATION suivants qui répertorient les SPI à supprimer. Puisque toutes les SA ESP existent par paires (pour la communication bidirectionnelle), chaque côté envoie des valeurs SPI uniquement aux SA ESP responsables du trafic sortant. En réponse, recevez les valeurs SPI ESP SA pour le trafic entrant.

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

La suppression d'une SA IKE se fait également via DELETE , mais avec un SPI IKE et en acceptant une réponse authentifiée vide:

    SK {D} ->
<- SK {}

TLS 1.3 : il existe un mécanisme de rotation des clés à travers les messages KeyUpdate , mais il n'y a aucune possibilité d'ajouter une entropie supplémentaire ou d'exécuter DH. TLS n'est clairement pas conçu pour les connexions à très longue durée de vie. Dans le meilleur des cas, vous ne pouvez interrompre la session et continuer / créer une nouvelle session avec iPSK-ECDHE qu'avec une poignée de main.

IKEv1 a à la fois une procédure de renouvellement de clé IKE distincte et une procédure distincte pour la ré-authentification. Il n'y a pas de ré-authentification dans IKEv2. Pour ce faire, une nouvelle SA IKE est simplement créée à partir de zéro, l'ancienne est supprimée via DELETE .

TLS 1.3 : a la capacité d'authentification du client après l'établissement de la liaison à tout moment après l'établissement de la liaison ( Terminémessages des deux côtés), le serveur peut envoyer une demande d'authentification client à l'aide d'un certificat X.509. Par exemple, un client, errant sur le site, est allé sur la page de son compte personnel. Dans IKEv2, cela n'est pas possible - l'authentification est effectuée uniquement au moment de la négociation.

NOTIFIER

Alors, comment les modes tunnel / transport sont-ils négociés, TFC? Pour cela, des charges utiles de "notifications" NOTIFY ( N ) sont ajoutées à la requête . Il existe des dizaines de types de notifications dans le seul RFC IKEv2. Les alertes sont utilisées pour signaler les erreurs, les problèmes de négociation SA, les sélecteurs de trafic, etc.

Pour signaler le désir d'utiliser le mode de transport dans une SA ESP négociée, une annonce N (USE_TRANSPORT_MODE) est ajoutée par l'initiateur et le répondeur pour confirmer la négociation de mode. L' alerte N (ESP_TFC_PADDING_NOT_SUPPORTED) signale que TFC n'est pas pris en charge. Et N (HTTP_CERT_LOOKUP_SUPPORTED) indique que le téléchargement d'un certificat à partir d'une URL est pris en charge.

La possibilité de mettre à jour la clé ESP SA, sans créer de nouvelles SA ESP, est similaire à la procédure de création d'une SA ESP enfant, mais l'initiateur ajoute une alerte N (REKEY_SA) contenant le SPI de la SA ESP actuelle:

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

DPD

L' échange INFORMATIONNEL avec SK vide est utilisé pour la détection de pair mort ( DPD ), comme un battement de cœur entre les démons. Si le démon IKE est indisponible pendant une longue période, il est fort probable qu'il a perdu son état et que, par conséquent, personne ne surveille ESP SA du côté opposé, ou ils ne sont plus actifs. Par conséquent, lorsqu'il est clair que le côté distant n'est pas disponible, il est logique de supprimer toutes les associations de sécurité ESP / IKE associées. Un SK vide signifie qu'il n'y a pas de charge utile, mais qu'il contient des données authentifiées (au moins des en-têtes IKE avec des compteurs), donc l'authentification d'un tel paquet est un signe de vie fiable.

    SK {} ->
<- SK {}

Mais que se passe-t-il si un côté redémarre rapidement, perd son état et commence à établir une connexion IKE à partir de zéro? Le côté opposé pourrait même ne pas remarquer que l'autre n'était pas disponible, et il penserait qu'il a décidé de se ré-authentifier ou de créer de nouvelles SA enfants dans une autre connexion IKE. Rien de catastrophique ne sera, mais l'ancienne ESP SA peut encore vivre un temps décent. Un initiateur PEUT placer une alerte N (INITIAL_CONTACT) dans son échange IKE_AUTH , signalant qu'il s'agit de la seule connexion IKE connue de ce côté. Après avoir vu une telle notification authentifiée, vous pouvez supprimer toutes les anciennes SA IKE / ESP en toute conscience.

DoS et mauvais KE

Déjà au tout début de IKE_SA_INIT, une charge utile KEi est envoyée avec une clé publique DH éphémère. Mais l'initiateur n'a pas encore échangé la SA IKE, et comment sait-il quel algorithme le côté récepteur prend en charge? Il ne peut que deviner ou se souvenir dans la mémoire à long terme de ce qui était auparavant utilisé pour associer à cette adresse. Si le répondeur ne prend pas en charge l'algorithme, il enverra à N (INVALID_KEY_PAYLOAD) une notification, qui indiquera l'identifiant de l'algorithme DH préféré. L'initiateur devra réitérer sa demande, mais avec un nouveau KEi .

TLS 1.3: peut envoyer plusieurs clés publiques éphémères à la fois en utilisant différents algorithmes, peut-être que certains le feront. Mais ce sont les ressources et le trafic. Il se peut qu'il n'envoie pas du tout la clé publique et le serveur lui répondra avec HelloRetryRequest avec ses préférences - l'avantage est que la cryptographie asymétrique coûteuse n'est pas du tout utilisée tant que les algorithmes de serveur préférés ne sont pas connus, mais au prix d'un aller-retour supplémentaire. Si le client a initialement fourni un algorithme de clé publique inapproprié, alors, comme dans IKEv2, il recevra une HelloRetryRequest avec les algorithmes parmi lesquels choisir.

Mais que faire si vous envoyez le même paquet initial de l'initiateur? Il est possible d'y générer un nouveau SPIi à chaque fois... Le répondeur effectuera au minimum les calculs DH honnêtement et répondra avec IKE_AUTH . DH est une opération très gourmande en ressources, brûlant le CPU et la source d'entropie - par conséquent, le transpondeur peut être désactivé.

Dans IKEv2 (mais pas IKEv1), il existe une protection contre cela, sous la forme d'une réponse N (COOKIE) avec une alerte contenant une chaîne de cookie, après quoi l'initiateur doit répéter sa demande, mais en y ajoutant cette charge utile N (COOKIE) :

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

La requête doit avoir le même SPI / Ni que la première. Il est assez facile de le compléter avec une charge utile. Le répondeur peut enregistrer l'état de la connexion entre la demande et le cookie qui lui est envoyé, et seulement après qu'ils correspondent, après avoir terminé ce travail sur l'ajout du cookie à la requête par l'initiateur, le répondeur peut continuer l' échange IKE_AUTH de manière régulière .

Mais il est possible de stocker l'état directement à l'intérieur du cookie, le rendant «auto-authentifié». Il peut porter le fait que l'intimé a vu la demande de l'initiateur ( Ni et SPIi l'ont vu , au moins):

Cookie = MAC (un peu secret, Ni || SPIi || horodatage)

Ainsi, l'amant DoS devra stocker l'état et recycler ses messages répétés, ce qui rend l'attaque beaucoup plus coûteuse. Il n'est logique d'activer la protection des cookies qu'en cas de suspicion d'attaque DoS, afin de ne pas forcer tout le monde à effectuer un aller-retour supplémentaire.

TLS 1.3 : a une sécurité optionnelle similaire. Le serveur PEUT répondre avec HelloRetryRequest avec un message contenant l' extension de cookie , que le client devrait insérer dans son ClientHello2 répété .

CP

IKEv2 vous permet de négocier la configuration des réseaux / adresses IP. La charge utile de configuration ( CP ) vous permet de faire une demande pour recevoir une configuration ( types de paquets CFG_REQUEST / CFG_REPLY ) et de définir la configuration du côté opposé ( types CFG_SET / CFG_ACK ). La demande de configuration contient les attributs que la partie souhaite connaître / définir. Les attributs peuvent être: adresse «interne», adresse DNS, DHCP, connaissance du sous-réseau ou d'autres types décrits dans les RFC associées. Par exemple, l'initiateur de l' échange IKE_AUTH peut faire une demande pour lui délivrer une adresse intranet (se connectant au réseau de l'entreprise) et un serveur DNS:

    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)

L' adresse 2001: db8 :: 5 est allouée à l'initiateur .
ESP SA 2001:db8::/64 .
2001:db8::1 DNS .
2001:db8:abcd::/64 , , ESP SA, 2001:db8:: .

Go?

Pour tester les implémentations domestiques modernes de la pile IPsec avec les algorithmes GOST, nous avons décidé d'écrire une implémentation complètement indépendante (de Linux, FreeBSD, strongSwan et d'autres piles). Et pour la rapidité et la facilité de développement dans le langage Go , avec l'implémentation déjà existante des algorithmes GOST de la bibliothèque GoGOST . Avant, j'avais déjà l' expérience de l'intégration de GOST dans l'implémentation TLS 1.3 des bibliothèques crypto / tls et crypto / x509 Go.

Le projet gostipsec est un logiciel libre composé de deux démons: ESPER (ESPv3) et IKER (IKEv2):

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

Pour le moment, ESPER ne fonctionne qu'avec les sockets DIVERT (je n'ai rien trouvé d'aussi simple sous Linux), donc il n'est supporté que sur FreeBSD (probablement OpenBSD, n'a pas vérifié) OS. ESPER, comme IKER, n'utilise pas PF_KEYv2 , qui nécessiterait des liaisons C, comme interface entre les liaisons ESP <-> IKE , mais l' interface textuelle de type setkey déjà mentionnée au début de l'article. IKER peut donc également être utilisé pour négocier des clés pour une implémentation ESP du noyau en appelant la commande setkey réelle . Ces commandes pour ESPER ressemblent à ceci:

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 prend en charge: AES-128/256-GCM-16, Magma / Grasshopper-MGM, ESN, TFC, modes transport / tunnel, IPv6 / IPv4 (la prise en charge de ce dernier, beaucoup plus complexe, n'a pas été minutieusement testée, et qui a besoin d'IPv4 pour nouveaux projets?), protection contre les attaques par rejeu. IKER vous permet de faire correspondre: AES-128/256-GCM-16 + AES-XCBC + courbe25519, Magma / Grasshopper-MGM + HMAC-Stribog-512 + GOST R 34.10-2012-VKO-256/512, ESN / TFC / transport / tunnel-modes, authentification à l'aide des signatures numériques PSK et X.509 (ECDSA, GOST R 34.10-2012). Configuré par un seul fichier Hjson :

{
    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
        }
    ]
}

Dans cet exemple, nous avons défini le seul membre que nous connaissons:

À quel démon se connectera automatiquement
Faites la détection des pairs morts toutes les cinq minutes
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 ne prend pas encore en charge l'ensemble complet de toutes les fonctionnalités IKEv2 ( CREATE_CHILD_SA , rekeying), ne surveille pas la perte de paquets et ne se soucie pas du principe DON'T PANIC . Par conséquent, il ne peut pas encore être considéré comme un candidat à une utilisation "industrielle".

Tarball gostipsec contient déjà toutes les dépendances, la documentation .info compilée et les cibles pour le système de redo build, bien que la construction d'exécutables se fasse facilement avec un appel go build régulier .

Hjson?

Thème Holywar, mais je vais quand même donner mon phi:

INI ne vous permet pas de spécifier de telles structures de balayage et il n'y a pas de norme pour les fichiers .ini .
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.

En général, si vous implémentez un sous-ensemble de capacités similaire à TLS 1.3 (authentification uniquement par les certificats PSK et X.509, pas de rekeying sérieux), alors ESPv3 avec IKEv2 et IPv6 (il est beaucoup plus facile de travailler avec!), Du point de vue du programmeur, sera légèrement plus difficile en cours de mise en œuvre. La RFC n'oblige même pas à prendre en charge les échanges CREATE_CHILD_SA . La sécurité sera excellente, sans les modes de fonctionnement controversés et dangereux possibles de TLS 1.3. Les performances d'une solution IPsec seront généralement plus élevées en raison du transport au niveau nucléaire et des sessions IKE de longue durée.

On peut voir que dans IPsec, tout est affiné pour protéger la quantité colossale de trafic entre des réseaux entiers, mais BTNS(mieux que rien de la sécurité), le groupe de travail de l'IETF a écrit plusieurs RFC démontrant qu'IPsec peut être utilisé sans problème pour les connexions par socket, où l'une des parties (le client) est anonyme, remettant ainsi complètement en question l'opportunité d'utiliser TLS. Le verrouillage de connexion, dans ce cas, permettrait à toute application réseau, en effectuant un appel système trivial comme setsockopt , d'indiquer qu'elle a besoin d'un ESP à l' adresse FQDN = bank.com , se présentant comme un certificat X.509 (ou en restant anonyme), puis de manière transparente, rapide et travailler en toute sécurité avec ce bank.com , sans béquilles sous la forme de bibliothèques de transport d'espace utilisateur par application.

Sergey Matveev , cypherpunk, Développeur Python / Go / C, spécialiste en chef de FGUP STC Atlas.

Giblets IPsec, nous mesurons par rapport à TLS 1.3, GOST et Go