Giblets IPsec ، نحن نقيس مقابل TLS 1.3 و GOST و Go

تحية طيبة! أود أن أقول لكم عن الجهاز من الحديث أمن بروتوكول الإنترنت كومة من على ESPv3 و البروتوكولات IKEv2 . يبدو لي أن IPsec يتخطى العديد من الجوانب بشكل غير مستحق ولم أر تحليلاً مفصلاً لعمله وبروتوكولاته وقدراته باللغة الروسية. أيضًا ، سأفعل شيئًا غريبًا - قارن IPsec ESPv3 و IKEv2 (كلاهما 2005) مع TLS 1.3 الحديث والعصري لعام 2018.





لماذا أنا متحمس جدًا لـ IPsec - يمكن القول إنه أكثر مجموعة بروتوكولات تعقيدًا لتأمين الشبكات؟ بعد كل شيء ، التعقيد هو العدو الرئيسي للثقة والأمان! أولاً ، كلما تعلمت أكثر عن بروتوكولاتها ، وخاصة IKEv2 ، كلما فهمت عدد الاحتمالات التي تم وضعها فيها ، وأعجبت بفكرها ، على عكس النهج الشائع للمطورين "عكاز يقود عكازًا" وحل المشكلات الخطيرة "حتى تندلع الرعد". ثانيًا ، بروتوكولات IPsec مدروسة جيدًا من وجهة نظر التشفير ، وحتى ESP / IKEv1 القديم ، في الواقع ، هو البروتوكولات الصناعية الوحيدة المستخدمة على نطاق واسع والتي لا توجد فيها نقاط ضعف خطيرة. تم التفكير في نفس SSL (العام 1995) بشكل لائق فقط من الإصدار 1.3. وكثير من الناس يكرهون IPsec بسبب التعقيد الوحشي لـ IKEv1 ،الذي لم يعد في الإصدار 2.



من الناحية المثالية ، إذا لم يتباطأ مطورو أنظمة التشغيل في وقتهم مع تنفيذ وتنفيذ IPsec و IPv6 (لتوافر أجهزة الكمبيوتر ، بحيث لا يوجد NAT) ، فلا ينبغي أن يظهر SSL / TLS من حيث المبدأ. تبين أن العالم ليس مثاليًا ، ولكن الآن IPsec خارج الصندوق (على الأقل جزء SA / SP + ESP من المكدس) موجود على الأقل في بعض أنظمة التشغيل المنتشرة على نطاق واسع (أنا شخصياً أعرف فقط DragonFly BSD ، التي شربت IPsec بسبب نقص المطورين لدعمها) ، و IPv6 في بعض البلدان المتقدمة على الفور للغالبية العظمى من الناس.



IPsec عبارة عن مجموعة من البروتوكولات واستدعاءات API وإطار عمل بحيث يمكن للتطبيقات و / أو المسؤول معرفة الأمان الذي يحتاجون إليه أثناء الاتصال وسيتم ضمانه بشفافية على مستوى الشبكة ( IP secنقاء). يمكننا التحدث عن كل من حزم IP لمقبس واحد فقط (على سبيل المثال ، اتصالات TCP) ، وحول حركة المرور بين الشبكات بأكملها.



يقصد بأمن حركة المرور: ضمان سرية البيانات وأصالتها / سلامتها وحمايتها من هجمات إعادة التشغيل . مثل جميع البروتوكولات تقريبًا ، يحتوي IPsec على جزء نقل يؤمن حزم IP ، وجزء مصافحة متعلق بالتفاوض الرئيسي والمعلمات والتكوين والمصادقة للأطراف.



TLS 1.3 : يوفر فقط حماية البيانات لكل مأخذ توصيل لاتصالات TCP. يمكن أن توفر DTLS الحماية لمخططات البيانات (DTLS 1.3 ليس معيارًا حتى الآن) ، ولكن لا تدعم كل مكتبة ذلك.

بروتوكولات النقل

يستخدم نقل IPsec بروتوكولات IP:

• AH (رؤوس المصادقة). لن أتحدث أكثر عن AH ، لأنه لا يوفر سرية البيانات ، وبقدر ما سمعت ، فقد تم فقط بطريقة ما "مواكبة" قوانين بعض البلدان في التسعينيات بشأن القيود المفروضة على استخدام التشفير. التشفير خفيف جدًا مقارنة بكل شيء آخر بحيث لا معنى للتضحية به. ولكن في كل مكان تقريبًا يتم ذكر ESP ، يُقصد بـ AH أيضًا.
• ESP (تغليف حمولات الأمان). لقد تطور برنامج ESP قليلاً بمرور الوقت ويستخدم الآن إصدار ESPv3 الخاص به ، والذي غالبًا ما يكون متوافقًا مع الإصدارات السابقة ولا يختلف عن الإصدار السابق.

يتم تأمين حركة مرور IP بواسطة طبقة النقل فقط. ونظرًا لأنه يمكننا التحدث عن عدة ملايين من الحزم في الثانية ، يتم تطبيق ESP الواقعي على مستوى نواة نظام التشغيل ، في مكدس الشبكة ، على الأقل من أجل عدم تحويل السياق المكلف بين kernel ومساحة المستخدمين (كما يحدث عادةً مع TLS و SSH و OpenVPN وغيرها).



أؤكد أن AH و ESP هما بروتوكولات طبقة IP ، وشبكة ، وليست وسيلة نقل. لماذا لا UDP؟ المجموع الاختباري زائد عن الحاجة ويؤدي إلى حرق وحدة المعالجة المركزية ، وسيضمن التشفير التكامل على أي حال. ولكن ، إذا كان NAT الخاص بك لا يعرف شيئًا عن ESP (وهو لا يعرف) ، فلن يعمل كل هذا معه. لاحقًا ، ابتكروا عكازات NAT-T (NAT traversal) ، عندما تكون حركة مرور IPsec ملفوفة في حزمة UDP على المنفذ 4500 وستكون قادرة على المرور عبر NAT ، ولكن هذا يمثل عبئًا غير ضروري والحاجة إلى تحرير مكدس IPsec في النواة ، لأنه يجب أن يفهم بالفعل حزم UDP الخاصة هذه واستخراج ESP منها من أجلها معالجة منتظمة.

SP ، SA ، SPI وأول تشفير IPsec لدينا

كيف تعرف النواة ما يجب فعله مع حزمة IP: هل تريد تشفيرها باستخدام مفتاح ما ، أو فك تشفير ESP الوارد ، أو السماح لها بالمرور دون لمسها؟ للقيام بذلك ، يحتوي kernel على نُهج أمان ( SP ). هذه قواعد مثل جدار الحماية. بالإضافة إلى ذلك ، توجد اقترانات الأمان ( SA ) في النواة : سياقات لإجراء عمليات التشفير (المفاتيح ، العدادات ، إعادة تشغيل النوافذ ، إلخ). بشكل عام ، لا يعتبر أي من مقدمي الخدمات خاصين بـ IPsec ولا SAs - يمكن استخدامها لمهام / بروتوكولات أخرى (مثل OSPF).



يمكن تكوين SP / SA إما من خلال واجهة برمجة تطبيقات خاصة ( PF_KEYv2 ) ، أو يدويًا من خلال بعض أدوات تعيين المفتاح . على سبيل المثال ، إذا أردنا إخبار النواة بأن جميع حزم IP تأتي منيجب تأمين عناوين fc :: 123 على fc :: 321 عبر ESP ، ثم يمكن القيام بذلك بسهولة عن طريق الاتصال من سطر الأوامر:

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

قبل هذا الأمر ، رأينا أصواتًا:

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

لن نراه لاحقًا ، لأن النواة لا تعرف بعد "ماذا" يجب تشفيرها. تحتاج إلى إضافة SA ، ويمكن أيضًا القيام بذلك يدويًا ، بتعيين خوارزمية تشفير AEAD ومفتاح عشوائي 160 بت للبساطة AES-GCM-16 :

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

إذا قمنا بتنفيذ نفس الأوامر على المضيف البعيد (فقط دون أن ننسى تحديد -P in ) ، فسنرى :

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

الطلب مشفر بواسطة ESP ، لكن الرد ليس كذلك. نظرًا لأن المرساب الكهروستاتيكي يعمل "بطريقة واحدة" افتراضيًا وللاتصال ثنائي الاتجاه ، من الضروري عكس إضافة SP / SA للاتجاه المعاكس.



0xdeadbabe في هذا المثال هو مؤشر معلمات الأمان ( SPI ) - معرف فريد لـ "نفق" ESP بين عنواني IP ، حيث يمكن للنواة العثور على سياق SA المقابل وأخذ مفتاح فك التشفير منه. و esp / transport // required هو مطلب لاستخدام ESP في وضع النقل (المزيد عن ذلك أدناه).

الحوصلة ESP

تم تصميم حزمة ESP بشكل تخطيطي على النحو التالي:

  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 بت لجلسة ESP / النفق / الاتصال بين عناوين IP. عادةً ما يكون {SrcIP، DstIP، SPI} هو SA وسياق التشفير.
• 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).

يتم تشفير الجزء الكامل من الحزمة من الحمولة إلى الرأس التالي . تمت مصادقة كل شيء باستثناء MAC. يعتمد طول ICV ووجود ناقل IV (متجه التهيئة) على أوضاع / خوارزميات التشفير والمصادقة المستخدمة.



TLS 1.3 : الحشو الاختياري للبيانات بحجم معين ظهر فقط في الإصدار 1.3. بخلاف ذلك ، يكون التشفير والمصادقة متشابهين تمامًا. يلزم TLS 1.3 باستخدام خوارزميات AEAD فقط ، وهي صحيحة وجيدة. يدعم المرساب الكهروستاتيكي AEAD ، ولكن هناك مجموعة من الحلول القديمة. اكتب الحقول SPI أو SeqNumلا ، نظرًا لأن بروتوكول TCP يضمن التسلسل والتسليم ، بالإضافة إلى ذلك ، من الناحية العملية ، لا يتم إرسال ناقل تهيئة بشكل صريح - وبالتالي فإن حزمة طبقة تسجيل TLS أقصر قليلاً. يحتوي DTLS بالفعل على SeqNum بالإضافة إلى بيانات تجزئة الرسائل.



قد يكون رقم الحزمة 32 بت قصيرًا جدًا من الناحية العملية. هذه فقط +4 مليار حزمة IP ، والتي يمكن أن تطير بسرعة 10+ Mpps في دقائق. ماذا يحدث عندما يفيض العداد؟ ستتم إعادة تعيينه إلى الصفر. ولكن ، هذا يعني أن قيمة SPI + SeqNum ستبدأ في التكرار بالنسبة لنا ويمكن استخدام حزم ESP التي تم اعتراضها مسبقًا لإعادة الهجوم. لحل هذه المشكلة ، تم اختراع ESN(رقم التسلسل الممتد). هذا عداد 64 بت ، ولكن يتم نقل 32 بت "السفلي" فقط إلى حقل SeqNum ، ويتم تخزين 32 بت العلوية في الذاكرة. تمت مصادقة القيمة الكاملة لـ ESN - لذلك ، يلتزم الطرفان بالاتفاق على استخدام ESN مقدمًا.

تشفير ESP

كيف بالضبط يتم تشفير / مصادقة حزمة ESP ، على سبيل المثال ، عند استخدام AES-GCM-16؟ للعمل مع ESP ، فإنه يستخدم متجه تهيئة 64 بت موجود في بداية الحمولة . كما أنه يستخدم ملح 32 بت كجزء من المادة الأساسية. في مثال setkey ، لم أقم بتقديم مفتاح 128 بت ، ولكن مفتاح 128 + 32 بت. قد تكون هناك حالات حيث يتم إعادة استخدام المفتاح ويتم تعبئة IV بمولد رقم عشوائي زائف سيئ (PRNG) يمكن تكرار قيمه. تم تصميم الملح للحماية من هذه الحالة الأكثر خطورة ، مما قد يؤدي إلى فك تشفير الحزم التي تم اعتراضها. يكون تشفير / مصادقة ESP نفسها في وضع AES-128-GCM-16-ESP كما يلي:

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

بالنسبة لخوارزميات GOST الروسية (أصفار Magma أو Grasshopper) ، تكون بيانات الإدخال متشابهة. يتم استخدام كلا الشفرتين في وضع MGM (أود أن أقول نسخة محسنة من GCM ) ، ويتم تطبيق دوران مادة مفتاح ESPTREE العادي باستخدام HMAC-Stribog-256. هذا يقلل من الحمل على المفتاح. بشكل أساسي في سياق IPsec ، لا يؤدي هذا إلى زيادة وقت استخدامه بقدر ما هو لتقليل سطح الهجوم من خلال القنوات الجانبية. على سبيل المثال ، بسبب تشابك المفاتيح (تقنية مماثلة للدوران المستمر للمفاتيح) ، تبين أن تشفير كتلة GOST 28147-89 بحجم كتلة 64 بت غير معرض لهجمات SWEET32 .



من وجهة نظر السلامة ، لا توجد شكاوى حول ESP مع خوارزميات AEAD. ولكن بالنسبة لخوارزميات AEAD ، فإن IV هو مجرد عداد 64 بت ، يتم تمريره بوضوح مع كل حزمة تضيع مساحة في الحزمة. SeqNum قصير جدًا ، ولا يتم نقل ESN بشكل كامل ، على الرغم من أنه يتناسب تمامًا مع IV. بالنسبة لخوارزميات غير AEAD ، قد يكون IV ضروريًا بالفعل ويحمل قيمة غير متوقعة ، ولكن ليس بأي حال من الأحوال عداد. هذا إرث ، فالتخلص من المساحة الثمينة في العبوة والوزن لا يؤثر على الموثوقية هنا.







إذا كان من الممكن أن تحتوي IV لـ AEADs على قيم من 128 بت ، فسيكون من الممكن استخدام خوارزميات مثل XSalsa20 / XChaCha20 مع 192 بت nonce ، 128 بت منها يتم إنشاؤها بشكل عشوائي عند بدء التشغيل ، ويمكن استخدام 64 بت المتبقية للعداد ... قد يكون هذا منقذًا للأنظمة التي فقدت حالة العداد الخاصة بها ، ولكنها تريد الاستمرار في استخدام المفاتيح الحالية.



TLS 1.3 : يتم استخدام XOR على أنه رقم nonce بين عداد الرسائل ومتجه التهيئة الذي تم إنشاؤه باستخدام المفتاح. نظرًا لعدم إرسال العداد ولا الرابع بشكل صريح ، فإن TLS 1.3 يكون أكثر إحكاما بقليل. إذا كان ESP يستخدم خوارزميات غير AEAD ، فقد يتطلب الأمر إنشاء IV غير متوقع ، والذي يمكن أن يكون مكثفًا بشكل ملحوظ لوحدة المعالجة المركزية.

الأنفاق ووسائل النقل

ما هو مدرج في حمولة الحزمة؟ يعتمد ذلك على ما إذا كان ESP يعمل في وضع النقل أو وضع النفق . يستبدل وضع النقل حمولة حزمة IP المرسلة بـ ESP بهذه الحمولة. أي أنه كان:

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

أصبح:

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

في وضع النفق ، يتم تغليف حزمة IP بالكامل بالكامل في ESP ويتم تكوين حزمة IP جديدة ، عادةً برؤوس وعناوين SrcIP / DstIP جديدة. يستخدم هذا الوضع لنفق الحزم بين الشبكات.

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

على سبيل المثال ، من خلال setkey يمكنني تحديد أن جميع الحزم بين 2001: ac :: / 64 و 2001: dc :: / 64 يجب أن تمر الشبكات مشفرة عبر نقطتي نهاية من الأنفاق بالعناوين 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 ;

غالبًا ما يشار إلى وضع النقل باسم اتصال مضيف إلى مضيف. إذا تم استخدام بعض بروتوكول GRE أو IPv * -over-IPv * للنفق ، والذي يعمل بالفعل بين نقطتي نهاية ، فلا معنى ، في هذه الحالة ، لاستخدام وضع الاتصال النفقي على مستوى IPsec. ومع ذلك ، لا يصادق وضع النقل عنوان IP. كقاعدة عامة ، هذا ليس مهمًا وليس بالغ الأهمية ، ولكن إذا كنت تريد التأكد من عدم تغيير رؤوس IPv6 الممتدة أو تسميات تدفق الحزم ، فيجب عليك استخدام وضع النفق ، حتى لو كان بين مضيفين ، على حساب النفقات العامة.

ISAKMP

ماذا يحدث إذا قمت بإعادة تشغيل أجهزة الكمبيوتر ، واختفت SA مع جميع قيم العداد من ذاكرتها ، وقمت مرة أخرى بتحميل أوامر SP / SA القديمة بيدي؟ أولاً ، يمكن فك تشفير الحزم التي تطابق IV ، لأن هذا يعادل استخدام لوحة التشفير مرتين. ثانيًا ، منذ تطابق SPI / salt / ESN / SeqNum ، ستتم مصادقة جميع الحزم التي تم اعتراضها مسبقًا بشكل صحيح ويمكنك إعادة تشغيلها. إعادة استخدام مثل setkey SAs يمثل كارثة بالنسبة للأمان. ثالثًا ، خاصة إذا لم يتم استخدام ESN (على سبيل المثال ، في FreeBSD في وقت كتابة هذا التقرير ، لم يتم دعمه بعد) ، مع عملية SA الطويلة ، قد لا تلاحظ أن العداد "مستنفد".



كل هذا يعني أننا بحاجة إلى تغيير مفاتيح ESP بانتظام. وأيضًا التفاوض على خوارزمية تشفير ، وجود ESN ، TFC ، وضع النقل / النفق ، قيم SPI. في الواقع ، يتم استخدام بروتوكول ISAKMP (رابطة أمان الإنترنت وبروتوكول إدارة المفاتيح) لهذا الغرض . على الرغم من أنه يمكنك بسهولة فك بعض الرسائل الفورية باستخدام تشفير مصادق OTR / PGP / OMEMO وإرسال أوامر setkey للبرامج النصية إلى الخادم ، حيث يتم إنشاء المفاتيح عن طريق قراءة / dev / urandom . لا يهم النواة كيف تم الاتفاق عليها. كما هو الحال في OpenVPN: تتم مصادقة X.509 مع الشهادات والتفاوض على المفاتيح بشكل عام عبر TLS ، وبروتوكول نقل VPN نفسه هو بالفعل بروتوكول خاص به.



في شكله "النقي" ، لا يتم استخدام ISAKMP ، نظرًا لعدم وجود تشفير فيه. لمصادقة المحاورين وإنشاء مواد أساسية ، يتم استخدام بروتوكول طرف ثالث يغلف ISAKMP داخل نفسه. أنا أعلم:

• KINK - Kerberized الإنترنت تفاوض بشأن مفاتيح يستخدم، حيث وثق ثلث كيربيروس KDC للمصادقة والتفاوض. بالإضافة إلى الوصف من ويكيبيديا ، لا أعرف أي شيء آخر عن KINK ولم أشاهده على الهواء مباشرة.
• IKE (v1) - تبادل مفتاح الإنترنت . ربما لا يزال البروتوكول الأكثر شيوعًا ، على الرغم من أنه تم إنشاؤه في عام 1998.
• IKEv2 هو الإصدار الثاني من IKE ، 2005 ، والذي سأتحدث عنه.

بروتوكولات IKE قابلة للتوسعة للغاية بسبب العدد الكبير من أنواع الحمولة المختلفة. يحتوي IKEv1 على عدد كبير من الخيارات لتكوين نفق واحد فقط للعمل. أكثر من دزينة من طلبات التعليقات (RFC) تصف المجموعة الكاملة من ISAKMP و IKEv1 بحمولات مشتركة. تعقيد مخيف. بالإضافة إلى القدرة على فك التكوينات غير المخادعة بسهولة والأسطورة المعروفة والصحيحة جزئيًا التي تقول إن IKEv1 مضمون للعمل فقط في حالة نسخ ملف التكوين بالكامل تقريبًا.



لحسن الحظ ، ظهر IKEv2: RFC واحد مناسب (لمعظم الميزات) ، بروتوكول مبسط بشكل كبير للتفاوض على المعلمات ، وبالتالي تكوينه. كقاعدة عامة ، يحتوي على عدد أقل من الرحلات ذهابًا وإيابًا لعملية المصافحة الكاملة والاتفاقية الرئيسية مقارنة بـ IKEv1. لذلك ، سيتم النظر إليه فقط ، لأنه لم يعد هناك أي معنى في IKEv1 (ولكن لا يستحق الأمر مطاردة لاستبدال حالات التشغيل والتشغيل بالفعل ، نظرًا لأنها تعمل). يستخدم IKEv2 ، بخلاف IKEv1 ، خوارزميات وأساليب متشابهة تمامًا لتشفير الرسائل الخاصة به كما يفعل ESP. كما قدم أيضًا مصادقة EAP وإمكانية كل طرف للمصادقة بطرق مختلفة (على سبيل المثال ، يستخدم العميل PSK ، ويستخدم خادم X.509 الشهادات).

برنامج IKE الخفي

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

هذا الجزء من مكدس IPsec قيد التشغيل بالفعل ، عادةً في مساحة المستخدمين. أولاً ، هذه ليست شياطين محملة بشكل كبير: يمكنهم التواصل مع بعضهم البعض مرة واحدة على الأقل يوميًا ، وتتطلب المصافحة الأولية بضع رحلات ذهابًا وإيابًا عبر UDP. ثانيًا ، عدد إمكانيات ISAKMP / IKE هو أن هناك أكواد أكثر بمئات المرات مما هو عليه في التنفيذ الكامل SA / SP / ESP. هناك العديد من تطبيقات الشياطين ISAKMP: strongSwan (IKEv1 / V2) (وكذلك Openswan ، Libreswan )، isakmpd (IKEv1) تمكين، OpenIKED (IKEv2)، الراكون (IKEv1) تمكين، racoon2 (IKEv1 / v2 و KINK) وغيرها.



ملاحظة: صحيح أن يكتب ويتكلم "الشيطان" ( الشياطين) كما رأيت في الترجمات الروائية. ولكن في الدوائر الفنية الناطقة بالروسية ، ترسخت بالفعل "الشياطين".



TLS 1.3 : بشكل عام ، فإن TLS stack بأكمله عبارة عن وظائف مكتبة تعمل في كل تطبيق فردي وتخزن المواد الأساسية في ذاكرتها الخاصة. تتم جميع عمليات التشفير بالتبديل إلى مساحة المستخدمين ، وهو مقدار ضخم. ومع ذلك ، فإن FreeBSD و Linux على الأقل لديهم بالفعل تطبيقات إلغاء تحميل kernel لـ TLS ، عندما تتم معالجة جزء النقل بالكامل في النواة ، على غرار IPsec ، وتحدث المصافحة في مساحة المستخدمين.



يعمل IKEv2 عبر UDP ، على المنفذ 500 افتراضيًا ( isakmpالخدمات). تقوم Daemons بإنشاء قناة آمنة ، والمصادقة على بعضها البعض ، والتفاوض / إنشاء / حذف ESP SA / SPs ، وتحديث المفاتيح ، وتنفيذ ضربات القلب (Dead Peer Detection ( DPD )) ، والمزيد. تتم جميع الاتصالات بين الشياطين في شكل تبادل زوج من رسائل الطلب / الاستجابة. يجب الرد على أي طلب. نظرًا لأن هذا هو UDP ، ماذا تفعل إذا كانت الحزمة مفقودة؟ ضع ذلك في الاعتبار في ولايتك ، وأعد إرسال الطلبات بعد انتهاء المهلة التي لم يتم تلقي أي ردود بشأنها ، وأعد إرسال الردود على الطلبات المتكررة ، وتجاهل الردود المتكررة. يمكن أن تصل الحزم بترتيب فوضوي ، ويمكن أن تختفي بشكل غير متوقع - يتم أخذ الكثير في الاعتبار في معيار IKEv2 ويتم وصف كيفية التصرف في ظل ظروف السباق المختلفة.



TLS 1.3: تهتم طبيعة بروتوكول TCP لـ TLS بترتيب الرسائل وتسليمها. لكن TCP يستهلك موارد كبيرة في OS kernel ويمكن أن يمثل عددًا كبيرًا من جلسات TCP مشكلة (على عكس UDP). ولكن في DTLS ستظهر جميع المشكلات المشابهة بنفس الطريقة كما في IKE ، بالإضافة إلى إضافة البواسير مع معالجة الرسائل المجزأة. تغيير عناوين IP لنقاط النهاية لـ UDP ليس مشكلة. اتصالات IKE ، كقاعدة عامة ، طويلة العمر (حالة IKE صغيرة ويتم تخزينها فقط في ذاكرة برنامج مساحة المستخدمين الخفي) وبالتالي تتطلب مصافحة أقل ، بينما في TLS ، بعد فقدان اتصال TCP ، يجب عليك القيام بذلك (على الرغم من وجود طرق متسارعة لمواصلة الجلسات إذا لم تكن الحالة كذلك فقدت ، على سبيل المثال عند إعادة تشغيل البرنامج). نظرًا لأن برنامج IKE الخفي للنظام بأكمله (كقاعدة عامة) ، إذا أراد بعض التطبيقات التواصل بشكل آمن مع ذلكمع شخص لديه اتصال IKE بالفعل ، فيمكنه إما استخدامه على الفور أو يقوم البرنامج الخفي ، في رحلة واحدة ذهابًا وإيابًا ، بإنشاء ESP SA إضافي للتطبيق.

حوصلة IKE

سيكون أول تبادل (طلب-استجابة) للشياطين هو IKE_SA_INIT ، مما يؤدي إلى إنشاء IKE SA لمزيد من الاتصالات الآمنة. لاحظ أن ESP SA "مخزنة" في kernel ، وأن IKE SA موجود في عفريت مساحة المستخدمين. ثم تأتي بورصة IKE_AUTH ، حيث تتم مصادقة الأطراف. في نفس التبادل ، يتم إنشاء SA تابع ( Child SA ) ، والذي يتم استخدامه لـ ESP SA. بشكل عام ، يكون هذان التبادلان كافيان لمصادقة الأطراف والتفاوض على معلمات ESP SA مع المفاتيح ثم توجيه حركة مرور ESP المشفرة بين أجهزة الكمبيوتر. في هذه الحالة ، تظل IKE SA عاملة بين الشياطين لفترة طويلة. علاوة على ذلك ، في أي وقت ، يمكنهم إجراء تبادل CREATE_CHILD_SA ، لإنشاء المزيد من SAs التابعة ، بالإضافة إلى INFORMATIONALالتبادل (أغراض متنوعة).



تحتوي جميع رؤوس رسائل IKEv2 على البنية التالية:

                     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 بادئ IKE SA 64 بت. المعرف الذي تم إنشاؤه عشوائيًا بواسطة البادئ في جلسة IKE.
• SPIr - 64 بت IKE SA المستجيب SPI. وبالمثل ، ولكن SPI فقط من جانب المستجيب. في الرسالة الأولى من البادئ ، يتم ملء هذا الحقل بصفر بايت.
• NP - الحمولة التالية 8 بت. معرّف الحمولة التي تلي الرأس.
• الإصدار - إصدار 8 بت من بروتوكول IKE.
• ExchType - نوع 8 بت الصرف IKE: IKE_SA_INIT ، IKE_AUTH ، CREATE_CHILD_SA، أو INFORMATIONAL .
• Flags — 8- . .
• MsgID — 32- . , , replay-. — request/response MsgID. , .
• Len — 32- ( + ).

SPIi + SPIr هي 128 بت. لماذا كثيرًا عندما يحتوي ESP على 32 بت فقط؟ أولاً ، نظرًا لأنها غير متطابقة ، ولكن يتم إنشاؤها بشكل شبه عشوائي ، فإن 64 بت لجانب واحد ستكون كافية لتجنب الاصطدامات. ثانيًا ، يرتبط ESP أيضًا بعناوين IP ، في حين أن جلسة IKE ليست كذلك بشكل عام - يمكن للأطراف بسهولة تغيير عناوين IP الخاصة بهم (عميل الهاتف المحمول) والاستمرار في التواصل.



TLS 1.3: سيؤدي تغيير عنوان IP إلى قطع الاتصال. ستحتاج إلى إعادة المصافحة ، حتى مع iPSK ، وتوفير الموارد للتشفير غير المتماثل ، وهذا هو 1.5 رحلة ذهابًا وإيابًا بالإضافة إلى رحلات ذهابًا وإيابًا لإنشاء اتصال TCP. سيستغرق إنشاء ESP SAs التابعة على عناوين IP الجديدة ، في اتصال IKE الذي تم إنشاؤه بالفعل (غير مرتبط بالعناوين) ، رحلة واحدة ذهابًا وإيابًا (+ ذهابًا وإيابًا لإزالة القديمة ، ولكن هذا سيحدث بالفعل في خلفية ESP SA عامل جديد)



يتبع رأس IKE حمولة واحدة أو أكثر. كل حمولة لها رأس تنسيق عام ، متبوعًا بمحتوى خاص بنوعها. المحتوى محاذاة 32 بت. عنوان مشترك للجميع:

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

وبالتالي ، تتكون رسائل IKE من رأس IKE وحمولات مرتبطة ببعضها البعض في سلسلة. يمكن لـ Daemons تجاهل الحمولات غير الحرجة وغير المعروفة. محتوى الحمولة من نوع Nonce (بعد الرأس) هو مجرد مجموعة عشوائية من البيانات ، وليس حجمًا ثابتًا. لكن هناك أيضًا هياكل أكثر تعقيدًا. في معايير IKE ، يتم قبول التعيينات القصيرة لأنواع الحمولة (على سبيل المثال ، N * للرسائل nonce ، حيث يكون "*" إما "i" (البادئ) أو "r" (المستجيب)).

سيجما

من وجهة نظر التشفير ، تنتمي IKEv1 / IKEv2 إلى فئة STS و ISO / IEC IS 9798-3 و SIGMA (SIGn-and-MAc) لبروتوكولات تبادل المفاتيح المصدق عليها. هذه حلول مدروسة جيدًا وتم التحقق منها رياضيًا (SIGMA). في مقالتي "P2P F2F E2EE IM في إحدى الأمسيات" ، سبق لي أن وصفت مبدأ تشغيل وتنفيذ بروتوكول SIGMA-I. IKEv2 مشابه تمامًا. عندما نناقش أمان بروتوكول المصافحة ، ماذا نتوقع؟

• سرية الرسائل المرسلة ؛
• أصالة وسلامة الرسائل المرسلة - يجب الكشف عن تغييرها ؛
• الحماية من هجمات إعادة الإرسال - يجب الكشف عن حقيقة فقدان الرسائل أو إعادة تشغيلها ؛
• ;
  
  perfect forward secrecy (PFS) — PSK ( IKE ESP SA). ;
  
  / ( ) IKE . / ( ) ;
  
  , , . .
  
  

بعد تبادل IKE_SA_INIT ، يكون للشياطين عناوين بعضهم البعض ، SPIi + SPIr قيمة جلسة IKE ، خوارزميات SA المتفاوض عليها (في حالة IKE ، هذه هي اتفاقية المفتاح ( DH ) ، تشفير / مصادقة الرسائل ( ENCR ) ، خوارزميات إنشاء المفتاح ( PRF )) ، المفتاح العمومي (DH) للجانب الآخر. هذا يكفي لحفظ الحالة في الذاكرة وتنفيذ اتفاقية المفاتيح (Diffie-Hellman ، GOST R 34.10-VKO ، curve25519 ، إلخ) ، وإنشاء مفتاح متماثل لتشفير الحمولة النافعة لرسائل IKE اللاحقة.



TLS 1.3: تنسيق رسائل المصافحة مختلف تمامًا ، فهناك الكثير من الإرث ، ولكن في الأساس لا شيء يبرز. يتم استخدام الحقل العشوائي بدلاً من الحقل nonce. بدلاً من الحمولات ، تمديدات عديدة. بدلاً من هيكل اقتراح SA المعقد ، يتم استخدام معرفات ciphersuites ، وهي أكثر إحكاما وأبسط. في رأيي ، فإن مرونة مقترحات ضمان البرنامج (SA) مفرطة ، ولكن في IKEv2 لا تزال هذه ليست مشكلة ويتم كتابة القيم المشابهة لـ ciphersuite في ملف التكوين. فقط مع إصدار TLS 1.3 يصبح تبادل DH إلزاميًا.

المواد الرئيسية IKE

بعد IKE_SA_INIT ، يتم إنشاء SKEYSEED :

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

يتم تحديد خوارزمية PRF في IKE SA. على سبيل المثال ، بالنسبة لـ GOST IKEv2 ، هذه هي وظيفة HMAC-Stribog-512. مفتاح PRF هو قطعة 64 بت من كل nonce.



يبدو تافهًا ، لأنه يتم نقل الرموز غير المفصلية علانية ، مما يعني أن مفتاح PRF هذا معروف لأي شخص اعترض حركة المرور. ولكن يتم استخدام PRF هنا حصريًا لإنشاء مفتاح من نتيجة DH-KEY لحساب DH ، وهو غير معروف بالفعل للمهاجم . يمكن أن تكون نتيجة دالة DH قيمة ضخمة وغير متساوية في الانتروبيا ، ويمكن أن تكون نقطة على منحنى إهليلجي - كل هذا لا يمكن استخدامه كمفتاح متماثل قصير عالي الانتروبيا. لذلك ، تحتاج إلى استخراج الانتروبيا من DH-KEY (هذا مجرد SKEYSEED ) ، ثم توسيع (توسيع ) إلى العدد المطلوب من المفاتيح:

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)

هذه كلها عملية اشتقاق مفتاح كلاسيكية مع مراحل استخراج / توسيع ، على غرار وظيفة HKDF . ولكن إذا افترضت HKDF استخدام وظائف التجزئة ، فيمكن استخدام بنية PRF / PRF + ببساطة مع الأصفار المتماثلة - في حالة انتشار AES-GCM + AES-XCBC-PRF ، فلن نستخدم دالة تجزئة في أي مكان على الإطلاق ، وعدد صغير الأوليات المستخدمة جيدة دائمًا.



تم إنشاء المفاتيح التالية:

• مفتاح SK_d لإنشاء مفاتيح لـ ESP SAs.
• مفاتيح SK_a [ir] لمصادقة رسالة IKE. لم يتم إنشاؤه / عدم استخدامه إذا تم الاتفاق على خوارزمية AEAD (AES-GCM ، Grasshopper / Magma-MGM ، ChaCha20-Poly1305 ، إلخ).
• SK_e[ir] IKE .
• SK_p[ir] AUTH.

TLS 1.3: لديه جدولة مفاتيح أكثر تعقيدًا بشكل ملحوظ. يتم إخراج الانتروبيا من رسائل المصافحة بأكملها دفعة واحدة ، بدلاً من الحقول الفردية. لا يتم قطع التسلسل الممتد الذي تم إنشاؤه إلى عدد من المفاتيح (+ ملح لهم عند الحاجة) ، ولكنه أيضًا مصحوب بتحولات HMAC مع تسميات (تسميات) لكل سياق لاستخدام هذه المفاتيح أو IVs التي تم إنشاؤها. يعد استخدام التسمية النصية / التطبيق / السياق لأي نوع من القيم المولدة ممارسة حديثة جيدة ويسهل القيام بها دائمًا بدلاً من التساؤل عما إذا كنت بحاجة إليها. تجزئة كل ما يظهر هو أيضًا ممارسة جيدة جدًا ، "لن تزداد سوءًا". ومع ذلك ، هذا لا يعني أن أمان IKEv2 أسوأ ، أو أنه يمكن للمرء أن يتوصل بسهولة إلى موقف نظري عن بعد على الأقل حيث يمكن أن يكون غياب الملصق في يد المهاجم.في IKEv2 ، يكون النهج ضئيلًا ، بينما في TLS 1.3 من الأفضل "التجاوز" (نظرًا لعدد العضادات أو الصعوبات التي تم إجراؤها في الإصدارات السابقة من البروتوكول!). لا يزال IKEv2 يستخدم مناهج وأوليات مثبتة ، ويصادق على كل ما هو مطلوب ، ويضغط / يأخذ في الاعتبار كل الانتروبيا المنقولة ، ويستخدم مفاتيح مختلفة لكل جانب ومهمة.

IKE_AUTH

بعد ذلك ، يتم إجراء تبادل IKE_AUTH ، للمصادقة على كلا الطرفين والتفاوض على ESP SA:

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

• تحتوي رسائل IKE على حمولة مشفرة ( SK ) ، يوجد بداخلها جميع الرسائل الأخرى.
• يوفر البادئ معرفه ( IDi ) ، والموثق ( AUTH ) ، وعرض SA لـ ESP ( SAi2 ) وزوج البادئ / المستجيب ، ما يسمى محددات حركة المرور ( TS * ). يمكنه أيضًا إرسال معرف المستجيب المتوقع اختياريًا ، والذي يمكن اعتباره نوعًا من نظير SNI من TLS.
• واستجابة لذلك ، يتلقى معرّف المستجيب ، واقتراح ESP SA المتفاوض عليه ، ومحددات حركة المرور المؤكدة ، والمصدق.
• بعد ذلك ، يعتبر كلا الطرفين أن بعضهما البعض موثقًا ، ولهما اتفاقية بشأن ESP SA ، وحركة المرور التي يجب أن تنتمي إلى ESP ، ويمكنهما بالفعل إصدار أمر إلى kernel لإنشاء SA ، وربما SP (هناك عناصر عفوية لا تتعامل مع SP على الإطلاق).

الآن بمزيد من التفاصيل حول هذه الحمولات:

• ID - معرف الطرف. يحتوي على نوع التعريف والبيانات الخاصة به. يمكن تحديد الأطراف بعدة طرق: عنوان IPv4 / IPv6 ، FQDN (اسم مجال مؤهل بالكامل ، مجرد سلسلة ، الطريقة الأكثر شيوعًا) ، عنوان البريد الإلكتروني RFC822 ، الاسم المميز ASN.1 DER (الطريقة الأكثر شيوعًا عند استخدام شهادات X.509) أو الاسم العام فضلا عن البائع المحدد.
• 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 .
  
  
  
  يرسل الطرف المستجيب اختياراته المؤكدة من المحددات ، والتي تتطابق أو قد تحتوي على نطاقات اختيار أضيق.

يتم تشفير كل هذه الحمولات على المفتاح الذي تم إنشاؤه بواسطة IKE SA بعد تبادل الرسائل الأول. التشفير ضروري لإخفاء المعرفات المرسلة للأطراف وشهاداتهم والمعلومات الخاصة الأخرى في العراء. ومع ذلك ، يمكن للمهاجم النشط أن يدخل في أول تبادل IKE_SA_INIT ويرى هذه المعلومات ، على الرغم من أنه لم يعد قادرًا على متابعة الجلسة.



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

إن تشفير حمولة SK باستخدام شفرات AEAD ليس صعبًا ويشبه تمامًا ESP ، على سبيل المثال ، لـ AES-GCM (حيث يكون الملح ، على غرار AES-GCM-ESP ، جزءًا من المادة الأساسية):

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

المصادقة مع EDS

ماذا لو أراد أي طرف المصادقة باستخدام التوقيع وشهادات X.509؟ لهذا ، بالفعل في IKE_SA_INIT ، يمكن إرسال حمولة CERTREQ ، مطالبة الجانب الآخر بتقديم شهادة في شكل حمولات CERT . يحتوي CERT و CERTREQ على معرف تنسيق الشهادة والمحتوى الخاص بالتنسيق. عادةً ، يمكن تقديم الشهادات كـ ASN.1 DER أو تجزئة SHA1 للشهادة + عنوان URL حيث يمكن تنزيلها. نظرًا لأن حجم UDP مقيد بواسطة MTU ، ويمكن أن تكون أحجام الشهادات أكبر بكثير ، فإن خيار التجزئة + URL مفيد هنا (على الرغم من أنه يمكن اعتباره عكازًا).



يسرد IKEv2 RFC وحده ، بالإضافة إلى شهادات X.509 المشفرة بواسطة DER وعناوين SHA1 + URL: شهادة X.509 مغلفة PKCS # 7 ، وشهادة PGP ، ومفتاح موقع DNS ، وشهادة SPKI ، وشهادة سمة X.509 ، ومفاتيح عامة خام. إذا كنت ترغب في استخدام IPsec بنفس الطريقة مثل TLS لحالة الاستخدام الأكثر شيوعًا: خادم مصدق عليه بشهادة X.509 وعميل مجهول ، فلا توجد طريقة في IKEv2 لعدم مصادقة أحد الأطراف. لكن RFC 5386 يصف نهجًا أفضل من لا شيء للأمان حيث يمكن لـ "العميل" استخدام المفتاح العام المجرد ويمكن للخادم التعامل معه على أنه مجهول.



بالإضافة إلى ذلك ، يتم دعم مصادقة EAP بشكل قياسي ، مع إضافة رحلات الذهاب والعودة إلى IKE_AUTHتبادل. يمكن لـ EAP تحديد ما إذا كان الطرف قد تمت مصادقته أم لا ، وكذلك إنشاء مفتاح سيأخذه IKEv2 في الاعتبار ويستخدمه. سأعرض لك فقط رسمًا تخطيطيًا لكيفية عمل EAP:

                 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 : في ذلك ، يتم وضع التوقيع (أو MAC في الرسالة النهائية ) فوق التجزئة من جميع الرسائل المرئية التي شاركت في عملية المصافحة. أيضا نهج جيد بسيط وموثوق. لا توجد طرق متنوعة للمصادقة. ولكن أود أن نرى بعض القوي كلمة مصادق اتفاق مفتاح بروتوكول (PAKE)، مثل الروسية SESPAKE أو OPAQUE .

المواد الرئيسية ESP SA وتجديدها

لذلك ، تحققنا من المصادقة ، وتحققنا من صحة الاتفاقية الرئيسية ، وتفاوضنا مع ESP SA ومحددات حركة المرور. يبقى إنشاء مفاتيح متماثلة لـ ESP ويمكن تثبيت SA / SP المطلوبة في النواة:

PRF + (SK_d، Ni || Nr) -> KEYMAT0 || مفتاح 1

يتطلب الاتصال ثنائي الاتجاه جهازي ESP SA ، لذلك يقوم IKEv2 بإنشاء مادتين رئيسيتين في وقت واحد ، والتي يتم نقلها بالفعل مباشرة إلى النواة في SA المقابل. يعتمد طول المادة على خوارزمية ESP المستخدمة (على سبيل المثال ، يتطلب AES-GCM-ESP ، بالإضافة إلى المفتاح ، ملح 32 بت أيضًا). قيمة SPI هي قيمة SPI المحددة من قبل كل طرف في مقترحات ESP SA.



ماذا لو احتجنا إلى الاتفاق على عدة ESP SA / SPs ، على سبيل المثال ، لأنه لا يمكن تحديد كل الرغبات في زوج TSi / TSr واحد ؟ لهذا، CREATE_CHILD_SA التبادل تستخدم التي تحدث في أي وقت بعد IKE_AUTH . يتم إنشاء طفل SA في التبادل التالي:

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

يتم تقديم عرض SA ، يتم إرسال محددات حركة المرور. كل شيء كما كان من قبل. تم إنشاء المادة الرئيسية بالفعل باستخدام هذه الرموز الجديدة. اختياريًا ، يمكنك استخدام حمولات تبادل المفاتيح ، والتي تضيف إنتروبيا وتجبر الأطراف على استخدام المزيد من التشفير غير المتماثل. قد يكون من الضروري مراقبة خاصية PFS باستمرار (في بروتوكول OTR ، يتم إرسال مفاتيح DH سريعة الزوال مع كل رسالة). سيتم عمل المادة الرئيسية في هذه الحالة على النحو التالي:

PRF + (SK_d، DH-KEY || Ni || Nr) -> KEYMAT0 || مفتاح 1

ماذا لو أردنا تجديد IKE SA للاتصال؟ نقوم بإجراء التبادل التالي CREATE_CHILD_SA :

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

حيث ستحتوي SA بالفعل على مقترحات IKE SA وسيتم تطوير SKEYSEED جديد :

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

يتم تحديث مفتاح ESP SA إما عن طريق إنشاء ESP SA جديد (بمعرف SPI مختلف) وحذف القديم ، أو عن طريق إرسال إشعار خاص (حوله أدناه). سيكون تحويل حركة المرور إلى استخدام ESP SA الجديد شفافًا وخاسرًا. لفترة قصيرة ، سيكون لدى الأطراف اثنين من ESP SA نشطتين ، مما سيسمح بمعالجة حركة المرور التي لا تزال قيد النقل على قنوات الاتصال.



يتم حذف ESP SA عن طريق إرسال حمولة DELETE في التبادلات المعلوماتية اللاحقة التي تسرد SPI المراد حذفها. نظرًا لأن جميع ESP SAs موجودة في أزواج (للاتصال ثنائي الاتجاه) ، يرسل كل جانب قيم SPI فقط إلى ESP SAs المسؤولة عن حركة المرور الصادرة. استجابةً لذلك ، استقبل قيم SPI ESP SA لحركة المرور الواردة.

    SK {D (SPIi)} ->
<- كورونا {D (SPIr)}

يتم أيضًا حذف IKE SA عبر DELETE ، ولكن باستخدام IKE SPI وقبول استجابة فارغة مصادق عليها:

    SK {D} ->
<- كورونا {}

TLS 1.3 : توجد آلية لتدوير المفاتيح عبر رسائل KeyUpdate ، ولكن لا توجد إمكانية لإضافة إنتروبيا إضافية أو تنفيذ DH. من الواضح أن TLS غير مصمم للاتصالات طويلة الأمد. في أحسن الأحوال ، يمكنك فقط كسر الجلسة ومتابعة / إنشاء جلسة جديدة بمصافحة iPSK-ECDHE.



IKEv1 لديه كل من إجراء تجديد مفتاح IKE منفصل وآخر منفصل لإعادة المصادقة. لا توجد إعادة مصادقة في IKEv2. للقيام بذلك ، يتم إنشاء IKE SA الجديد ببساطة من البداية ، ويتم حذف القديم عبر DELETE .



TLS 1.3 : لديه إمكانية مصادقة العميل بعد المصافحة في أي وقت بعد المصافحة ( انتهىمن كلا الجانبين) ، يمكن للخادم إرسال طلب لمصادقة العميل باستخدام شهادة X.509. على سبيل المثال ، عميل ، يتجول في الموقع ، انتقل إلى صفحة حسابه الشخصي. في IKEv2 ، هذا غير ممكن - تتم المصادقة فقط في وقت المصافحة.

إخطار

إذن كيف يتم التفاوض على الأنفاق / وسائط النقل ، TFC؟ لهذا الغرض ، يتم إضافة حمولات "الإخطارات" NOTIFY ( N ) إلى الطلب . هناك العشرات من أنواع الإشعارات في IKEv2 RFC وحده. تُستخدم التنبيهات للإشارة إلى الأخطاء ، وقضايا تفاوض SA ، ومحددات حركة المرور ، وما



إلى ذلك ... للإشارة إلى الرغبة في استخدام وضع النقل في ESP SA متفاوض عليه ، تمت إضافة إعلان N (USE_TRANSPORT_MODE) من قبل كل من البادئ والمستجيب لتأكيد مفاوضات الوضع. إشارات تنبيه N (ESP_TFC_PADDING_NOT_SUPPORTED) بأن TFC غير مدعوم. و N (HTTP_CERT_LOOKUP_SUPPORTED) يشير إلى أن يتم اعتماد شهادة من URL تحميل.



تشبه القدرة على تحديث مفتاح ESP SA ، دون إنشاء ESP SAs جديدة ، إجراء إنشاء ESP SA تابع ، لكن البادئ يضيف تنبيه N (REKEY_SA) يحتوي على SPI الخاص بـ ESP SA الحالي:

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

DPD

يستخدم التبادل المعلوماتي مع SK الفارغ لاكتشاف الأقران الميت ( DPD ) ، كنبض قلب بين الشياطين. إذا كان برنامج IKE الخفي غير متاح لفترة طويلة ، فمن المرجح أنه فقد حالته ، وبالتالي لا أحد يراقب ESP SA على الجانب الآخر أو أنه لم يعد نشطًا. لذلك ، عندما يكون من الواضح أن النظير غير متاح ، فمن المنطقي إزالة جميع ESP / IKE SAs المرتبطة. يعني SK الفارغ عدم وجود حمولة فيه ، ولكنه يحتوي على بيانات مصادقة (على الأقل رؤوس IKE مع عدادات) ، وبالتالي فإن مصادقة مثل هذه الحزمة هي علامة موثوقة للحياة.

    SK {} ->
<- كورونا {}

ولكن ماذا لو قام أحد الأطراف بإعادة التشغيل بسرعة وفقد حالته وبدأ في إنشاء اتصال IKE من البداية؟ قد لا يلاحظ الجانب الآخر أن الآخر لم يكن متاحًا ، وسيعتقد أنه قرر إما إعادة المصادقة أو إنشاء SAs فرعية جديدة في اتصال IKE آخر. لن يكون هناك شيء كارثي ، لكن ESP SA القديم لا يزال بإمكانه العيش لفترة مناسبة. قد يقوم البادئ بوضع تنبيه N (INITIAL_CONTACT) في تبادل IKE_AUTH الخاص به ، مما يشير إلى أنه اتصال IKE الوحيد المعروف بهذا الجانب. بعد الاطلاع على مثل هذا الإخطار المصدق ، يمكنك حذف جميع IKE / ESP SAs القديمة بضمير مرتاح.

DoS و KE سيئة

بالفعل في بداية IKE_SA_INIT ، يتم إرسال حمولة KEi بمفتاح DH عام سريع الزوال. لكن البادئ لم يتبادل IKE SA بعد ، وكيف يعرف الخوارزمية التي يدعمها الجانب المستقبل؟ يمكنه فقط تخمين أو تذكر ما تم استخدامه سابقًا لربط هذا العنوان في الذاكرة طويلة المدى. إذا كان المستجيب لا يدعم الخوارزمية ، فسيقوم بإرسال إخطار N (INVALID_KEY_PAYLOAD) ، والذي سيشير إلى معرف خوارزمية DH المفضلة. يجب على البادئ أن يكرر طلبه ، ولكن مع KEi جديد .



TLS 1.3: يمكنه إرسال عدة مفاتيح عامة سريعة الزوال في وقت واحد باستخدام خوارزميات مختلفة ، وربما يفعل البعض ذلك. لكن هذه موارد وحركة مرور. قد لا يرسل المفتاح العام على الإطلاق وسوف يرد عليه الخادم بـ HelloRetryRequest مع تفضيلاته - الإضافة هي أن التشفير غير المتماثل المكلف لا يتم استخدامه على الإطلاق حتى يتم معرفة خوارزميات الخادم المفضلة ، ولكن على حساب رحلة ذهاب وإياب إضافية. إذا قدم العميل في البداية خوارزمية مفتاح عام غير مناسب ، فعندئذ ، كما في IKEv2 ، سيتلقى طلب HelloRetryRequest مع الخوارزميات للاختيار من بينها.



ولكن ماذا لو أرسلت نفس الحزمة الأولية من البادئ؟ من الممكن إنشاء SPI جديد هناك في كل مرة... سيقوم المستجيب ، على الأقل ، بإجراء حسابات DH بصدق والرد باستخدام IKE_AUTH . DH هي عملية كثيفة الاستخدام للموارد تحرق وحدة المعالجة المركزية ومصدر الانتروبيا - لذلك يمكن أن يتلف جهاز الإرسال والاستقبال.



في IKEv2 (ولكن ليس IKEv1) هناك حماية ضد هذا ، في شكل استجابة N (COOKIE) مع إشعار يحتوي على سلسلة ملف تعريف الارتباط ، وبعد ذلك يجب على البادئ تكرار طلبه ، مع إضافة حمولة N (COOKIE) إليه:

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

يجب أن يحتوي الطلب على SPI / Ni متطابق كالأول . من السهل استكمالها بالحمولة. يمكن للمستجيب حفظ الحالة المتعلقة بالاتصال بين الطلب وملف تعريف الارتباط المرسل إليه ، وفقط بعد التطابق ، وبعد إكمال هذا العمل على إضافة ملف تعريف الارتباط إلى الطلب من قبل البادئ ، يمكن للمستجيب متابعة تبادل IKE_AUTH بطريقة منتظمة .



ولكن من الممكن تخزين الحالة داخل ملف تعريف الارتباط ، مما يجعلها "ذاتية المصادقة". يمكن أن تحمل حقيقة أن المدعى عليه قد رأى الطلب من البادئ (رأى Ni و SPIi ، على الأقل):

ملف تعريف الارتباط = MAC (بعض السرية ، Ni || SPIi || الطابع الزمني)

وبالتالي ، سيتعين على عاشق DoS تخزين الحالة وإعادة تدوير رسائله المتكررة ، مما يجعل الهجوم أكثر تكلفة. من المنطقي فقط تمكين حماية ملفات تعريف الارتباط عندما يكون هناك اشتباه في هجوم DoS ، حتى لا يجبر الجميع على القيام برحلة إضافية ذهابًا وإيابًا.



TLS 1.3 : لديه أمان اختياري مماثل. قد يستجيب الخادم بـ HelloRetryRequest برسالة تحتوي على امتداد ملف تعريف الارتباط ، والذي يجب على العميل إدراجه في ClientHello2 المتكرر .

CP

يسمح لك IKEv2 بالتفاوض على تكوين شبكات / عناوين IP. حمولة التكوين ( CP ) يسمح لك لتقديم طلب للحصول على التكوين ( CFG_REQUEST / CFG_REPLY أنواع الحزمة) وتعيين التكوين إلى الجانب المقابل ( CFG_SET / CFG_ACK أنواع). يحتوي طلب التكوين على السمات التي يريد الطرف معرفتها / تعيينها. يمكن أن تكون السمات: عنوان "داخلي" أو عنوان DNS أو DHCP أو معرفة الشبكة الفرعية أو أنواع أخرى موصوفة في طلبات RFC ذات الصلة. على سبيل المثال ، يمكن للبادئ في تبادل IKE_AUTH تقديم طلب لإصدار عنوان إنترانت له (الاتصال بشبكة الشركة) وخادم 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)

• يتم تخصيص عنوان 2001: db8 :: 5 للبادئ .
• ESP SA 2001:db8::/64 .
• 2001:db8::1 DNS .
• 2001:db8:abcd::/64 , , ESP SA, 2001:db8:: .

Go?

لاختبار التطبيقات المحلية الحديثة لمكدس IPsec باستخدام خوارزميات GOST ، قررنا كتابة تطبيق مستقل تمامًا (عن Linux و FreeBSD و strongSwan ومكدسات أخرى). وللسرعة وسهولة التطوير في لغة Go ، مع التنفيذ الحالي بالفعل لمكتبة GoGOST لخوارزميات GOST . في السابق ، كان لدي بالفعل خبرة في دمج GOST في تنفيذ TLS 1.3 لمكتبات التشفير / tls و crypto / x509 Go.



مشروع gostipsec هو برنامج مجاني يتكون من شيطان: ESPER (ESPv3) و IKER (IKEv2):

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

في الوقت الحالي ، يعمل ESPER فقط مع مآخذ DIVERT (لم أجد شيئًا بسيطًا في نظام Linux) ، لذلك فهو مدعوم فقط على FreeBSD (ربما OpenBSD ، لم يتم التحقق منه) OS. لا يستخدم ESPER ، مثل IKER ، PF_KEYv2 ، الأمر الذي يتطلب روابط C ، كواجهة بين روابط ESP <-> IKE ، ولكن واجهة setkey النصية التي تم ذكرها بالفعل في بداية المقالة. لذلك يمكن استخدام IKER للتفاوض على مفاتيح تنفيذ kernel ESP من خلال استدعاء الأمر setkey الحقيقي . تبدو أوامر ESPER التالية كما يلي:

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: AES-128/256-GCM-16 ، Magma / Grasshopper-MGM ، ESN ، TFC ، أوضاع النقل / النفق ، IPv6 / IPv4 (دعم الأخير ، أكثر تعقيدًا ، لم يتم اختباره بدقة ، ومن يحتاج إلى IPv4 من أجل مشاريع جديدة؟) ، الحماية من هجمات الإعادة. يسمح لك IKER بمطابقة: AES-128/256-GCM-16 + AES-XCBC + curve25519 ، Magma / Grasshopper-MGM + HMAC-Stribog-512 + GOST R 34.10-2012-VKO-256/512 ، ESN / TFC / النقل / أوضاع النفق ، المصادقة باستخدام التوقيعات الرقمية PSK و X.509 (ECDSA ، GOST R 34.10-2012). تم تكوينه بواسطة ملف 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
        }
    ]
}

في هذا المثال ، قمنا بتعيين العضو الوحيد الذي نعرفه:

• ما البرنامج الخفي الذي سيتم الاتصال به تلقائيًا
• قم باكتشاف الأقران الميت كل خمس دقائق
• 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 حتى الآن المجموعة الكاملة لجميع ميزات IKEv2 ( CREATE_CHILD_SA ، rekeying) ، ولا يراقب فقدان الحزم ولا يهتم بمبدأ DON'T PANIC . لذلك ، لا يمكن اعتباره مرشحًا للاستخدام "الصناعي".



كتل القطران gostipsec بالفعل يحتوي على كافة التبعيات، وقد تم تجميعها INFO. ثائق والأهداف ل إعادته بناء نظام ، على الرغم من أن بناء التنفيذية يتم بسهولة مع العادية الذهاب بناء المكالمة.

هجسون؟

موضوع هوليوار ، لكنني سأقدم فاي على أي حال:

• لا يسمح INI لك بتحديد مثل هذه الهياكل الشاملة ، ولا يوجد معيار لملفات .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.

بشكل عام ، إذا قمت بتنفيذ مجموعة فرعية من القدرات المشابهة لـ TLS 1.3 (المصادقة فقط من خلال شهادات PSK و X.509 ، لا يوجد إعادة إدخال جاد) ، فإن ESPv3 مع IKEv2 و IPv6 (من الأسهل بكثير العمل معها!) ، من وجهة نظر المبرمج ، سيكون أكثر صعوبة قليلاً في التنفيذ. لا يلزم RFC حتى بدعم عمليات التبادل CREATE_CHILD_SA . سيكون الأمان ممتازًا ، بدون أنماط تشغيل TLS 1.3 المحتملة المثيرة للجدل والخطيرة. سيكون أداء حل IPsec أعلى بشكل عام بسبب النقل على المستوى النووي وجلسات IKE طويلة الأمد.



يمكن ملاحظة أنه في IPsec يتم شحذ كل شيء لحماية الكمية الهائلة من حركة المرور بين الشبكات بأكملها ، ولكن BTNS(أفضل من لا شيء أمان) كتبت مجموعة عمل IETF العديد من طلبات التعليقات التي توضح أنه يمكن استخدام IPsec دون مشاكل في الاتصالات لكل مقبس ، حيث يكون أحد الأطراف (العميل) مجهول الهوية ، وبالتالي يشكك تمامًا في استصواب استخدام TLS. إغلاق الاتصال ، في هذه الحالة ، سيسمح لأي تطبيق شبكة ، من خلال إجراء مكالمة نظام تافهة مثل setockopt ، للإشارة إلى أنه يحتاج إلى ESP إلى FQDN = عنوان bank.com ، وتقديم نفسه كشهادة X.509 (أو البقاء مجهول الهوية) ، ثم بشفافية وبسرعة و العمل بأمان مع هذا bank.com ، دون عكازات في شكل مكتبات نقل مساحة المستخدمين لكل تطبيق.



سيرجي ماتفيف ، سايفرونك، Python / Go / C-developer ، المتخصص الرئيسي في FGUP STC Atlas.