स्ट्रीमिंग अपडेट्स

अवलोकन

Java I2P और i2pd राउटर जो API 0.9.58 (मार्च 2023 में जारी) से पुराने हैं, वे स्ट्रीमिंग SYN पैकेट रिप्ले अटैक के प्रति संवेदनशील हैं। यह एक प्रोटोकॉल डिज़ाइन समस्या है, न कि एक कार्यान्वयन बग।

SYN पैकेट साइन किए जाते हैं, लेकिन एलिस द्वारा बॉब को भेजे गए प्रारंभिक SYN पैकेट हस्ताक्षर बॉब की पहचान से बाध्य नहीं होता है, इसलिए बॉब उस पैकेट को संग्रहीत और पुनरावर्तित कर सकता है, और इसे किसी पीड़ित चार्ली के पास भेज सकता है। चार्ली सोचेगा कि पैकेट एलिस से आया है और उसे जवाब देगा। अधिकांश मामलों में, यह हानिरहित है, लेकिन SYN पैकेट प्रारंभिक डेटा (जैसे GET या POST) शामिल कर सकता है जिसे चार्ली तुरंत संसाधित करेगा।

डिज़ाइन

समाधान यह है कि एलिस, बॉब के गंतव्य हैश को साइन किए गए SYN डेटा में शामिल करे। प्राप्ति पर बॉब यह सत्यापित करता है कि यह हैश उसके हैश से मेल खाता है।

कोई भी संभावित हमलावर विक्टिम चार्ली इस डेटा की जांच करता है और अगर यह उसके हैश से मेल नहीं खाता है तो SYN को अस्वीकार कर देता है।

SYN में हैश को स्टोर करने के लिए NACKs विकल्प फील्ड का उपयोग करके, परिवर्तन पिछड़े अनुकूल है, क्योंकि NACKs को SYN पैकेट में शामिल नहीं करने की उम्मीद की जाती है और वर्तमान में अनदेखा किया जाता है।

सभी विकल्प हस्ताक्षर द्वारा कवर होते हैं, जैसा कि सामान्य रूप से होता है, इसलिए बॉब हैश को पुनर्लिख नहीं सकता।

यदि एलिस और चार्ली API 0.9.58 या नए हैं, तो बॉब द्वारा कोई भी पुनरावर्तन प्रयास अस्वीकार कर दिया जाएगा।

विनिर्देश

Streaming विनिर्देश को निम्नलिखित अनुभाग जोड़ने के लिए अपडेट करें:

पुनरावृत्ति रोकथाम

एलिस से प्राप्त एक मान्य साइन की गई SYNCHRONIZE पैकेट को संग्रहीत करके, और बाद में इसे एक पीड़ित चार्ली को भेजने के लिए बॉब को एक पुनरावृत्ति हमले का उपयोग करने से रोकने के लिए, एलिस को SYNCHRONIZE पैकेट में बॉब के गंतव्य हैश को निम्नलिखित रूप से शामिल करना चाहिए:

.. raw:: html

{% highlight lang=‘dataspec’ %} Set NACK count field to 8 Set the NACKs field to Bob’s 32-byte destination hash

{% endhighlight %}

SYNCHRONIZE के प्राप्ति पर, यदि NACK गणना फील्ड 8 है, तो बॉब को NACKs फील्ड को 32-बाइट गंतव्य हैश के रूप में व्याख्या करनी चाहिए, और सुनिश्चित करना चाहिए कि वह उसके गंतव्य हैश से मेल खाता है। उसे यह भी सुनिश्चित करना चाहिए कि पैकेट का हस्ताक्षर सामान्य रूप से सत्यापित है, क्योंकि यह पूरे पैकेट को कवर करता है जिसमें NACK गिनती और NACKs फील्ड शामिल हैं। यदि NACK गिनती 8 है और NACKs फील्ड मेल नहीं खाता, तो बॉब को पैकेट को छोड़ देना चाहिए।

यह संस्करण 0.9.58 और उच्चतर के लिए आवश्यक है। यह पुराने संस्करणों के साथ पिछड़े अनुकूल है, क्योंकि SYNCHRONIZE पैकेट में NACKs की उम्मीद नहीं की जाती है। गंतव्य नहीं जानते और न ही जान सकते हैं कि दूसरा अंतिम संस्करण क्या चला रहा है।

बॉब से एलिस को भेजे गए SYNCHRONIZE ACK पैकेट के लिए कोई परिवर्तन आवश्यक नहीं है; उस पैकेट में NACKs शामिल न करें।

सुरक्षा विश्लेषण

यह समस्या स्ट्रीमिंग प्रोटोकॉल में 2004 में बनाए जाने के समय से रही है। इसे I2P डेवलपर्स द्वारा आंतरिक रूप से खोजा गया था। हमारे पास इस बात का कोई सबूत नहीं है कि इस मुद्दे का कभी भी शोषण किया गया था। वास्तव में शोषण की सफलता की संभावना व्यापक रूप से भिन्न हो सकती है, जो एप्लिकेशन-लेयर प्रोटोकॉल और सेवा पर निर्भर करती है। सहकर्मी-से-सहकर्मी एप्लिकेशन संभवतः क्लाइंट/सर्वर एप्लिकेशन की तुलना में अधिक प्रभावित हो सकते हैं।

अनुकूलता

कोई समस्या नहीं। सभी ज्ञात कार्यान्वयन वर्तमान में SYN पैकेट में NACKs फील्ड को अनदेखा करते हैं। और भले ही वे उसे अनदेखा नहीं करते, और 8 विभिन्न संदेशों के लिए उसे NACKs के रूप में व्याख्या करने का प्रयास करते हैं, उन संदेशों को SYNCHRONIZE हैंडशेक के दौरान लंबित नहीं किया जाएगा और NACKs का कोई अर्थ नहीं होगा।

माइग्रेशन

कार्यान्वयन किसी भी समय समर्थन जोड़ सकते हैं, कोई समन्वय की आवश्यकता नहीं है। Java I2P और i2pd राउटर ने इसे API 0.9.58 (मार्च 2023 में जारी) में कार्यान्वित किया।