सुरक्षा नीति

Herkos निजी कुंजियां और एन्क्रिप्ट किए गए संदेश संभालता है, इसलिए हम सुरक्षा रिपोर्ट को गंभीरता से लेते हैं और किसी समस्या के बारे में देर से नहीं, जल्दी जानना पसंद करते हैं।

किसी कमज़ोरी की रिपोर्ट करना

कृपया सुरक्षा समस्याओं के लिए कोई सार्वजनिक issue न खोलें।

इसकी रिपोर्ट निजी तौर पर GitHub की निजी कमज़ोरी रिपोर्टिंग के ज़रिए, या security@herkos.email पर ईमेल करके करें।

रिपोर्ट में ये बातें शामिल करना उपयोगी है: समस्या क्या है, उसे दोबारा कैसे पैदा करें, आपने किस प्लेटफ़ॉर्म और वर्शन पर जांच की, और कोई हमलावर इससे क्या हासिल कर सकता है। प्रूफ़ ऑफ़ कॉन्सेप्ट से बहुत मदद मिलती है।

रिपोर्ट में अपनी nsec, गुप्त कुंजी या बंकर सीक्रेट कभी शामिल न करें।

हमारा लक्ष्य कुछ ही दिनों में रिपोर्ट मिलने की पुष्टि करना है। क्योंकि Herkos एक छोटा प्रोजेक्ट है, कृपया सार्वजनिक रूप से बताने से पहले सुधार के लिए उचित समय दें। अगर आप न चाहें तो बात अलग है, वरना हमें सुरक्षा सलाह (advisory) में आपको श्रेय देने में ख़ुशी होगी।

दायरे में क्या है

ख़ुद Herkos ऐप्लिकेशन: कुंजी को संभालना और स्टोर करना, संदेशों का एन्क्रिप्शन और डिक्रिप्शन (local_packages/nostr_mail में NIP-59 भेजने वाले की जांच और Bcc को अलग रखने समेत), ऐप लॉक, रिले और ब्रिज के साथ संचार, अटैचमेंट को संभालना, और बिल्ड और रिलीज़ पाइपलाइन।

दायरे से बाहर क्या है

• ख़ुद Nostr प्रोटोकॉल और उसके NIP — इनकी रिपोर्ट मूल स्रोत (upstream) को करें।
• तीसरे पक्ष द्वारा चलाए जाने वाले रिले, ब्रिज और Blossom सर्वर। Herkos इन्हें डिफ़ॉल्ट के रूप में देता है, लेकिन इन्हें चलाता नहीं; समस्याओं की रिपोर्ट इनके ऑपरेटरों को करें।
• मूल प्रोजेक्ट Nostr Mail Client, जब तक कि समस्या Herkos में किए गए बदलावों से जुड़ी न हो।
• ऐसी सुरक्षा कमियां जिन्हें हम पहले से ज्ञात सीमा के रूप में दर्ज कर चुके हैं (नीचे देखें)।

ज्ञात सीमाएं, साफ़-साफ़

ये डिज़ाइन से जुड़े समझौते हैं, कमज़ोरियां नहीं। हम इन्हें पहले ही लिख देना पसंद करते हैं, बजाय इसके कि किसी को ये मुश्किल से पता चलें:

• पारंपरिक पतों पर भेजा गया मेल एंड-टू-एंड एन्क्रिप्टेड नहीं होता। Nostr उपयोगकर्ताओं के बीच संदेश NIP-17 गिफ़्ट रैप का इस्तेमाल करते हैं और E2E एन्क्रिप्टेड होते हैं। जब आप किसी सामान्य ईमेल पते पर लिखते हैं, तो ब्रिज संदेश को बदलता है और उसे पढ़ सकता है।
• ऐप लॉक (PIN और बायोमेट्रिक्स) सुविधा के लिए एक रुकावट है, स्टोर किए गए डेटा का एन्क्रिप्शन नहीं। यह उस व्यक्ति को रोकता है जो किसी अनलॉक डिवाइस को उठा ले; यह उस हमलावर से सुरक्षा नहीं देता जिसके पास डिवाइस या उसके स्टोरेज का पूरा ऐक्सेस हो।
• Windows पर सिर्फ़-बायोमेट्रिक प्रमाणीकरण लागू नहीं किया जा सकता। Windows Hello तरीका चुनने नहीं देता, इसलिए सिस्टम PIN हमेशा विकल्प के रूप में उपलब्ध रहता है।
• कुंजी खोने का मतलब है खाता खोना। कोई रिकवरी नहीं है, यह जान-बूझकर ऐसा है।
• मेटाडेटा पूरी तरह छिपा नहीं है। रिले कनेक्शन के पैटर्न देख सकते हैं, और हर रिले आपका IP पता देखता है, तब भी जब वह संदेश की सामग्री नहीं पढ़ सकता। Herkos जो ज़ाहिर नहीं करता (30-09-2026 से), वह यह है कि कौन किसे लिख रहा है, जब कोई रिले NIP-42 प्रमाणीकरण मांगता है:
• कहां डिलीवर करना है, यह पता करना। पाने वाले के रिले और Blossom की सूचियां एक अलग कनेक्शन पर मांगी जाती हैं, जो कभी आपकी पहचान नहीं बताता, और पहले उन रिले पर जिन्हें प्रमाणीकरण की ज़रूरत नहीं होती (purplepag.es, user.kindpag.es, nos.lol, offchain.pub)।
• प्रोफ़ाइल और शेड्यूलर। किसी और के लिए दिखाया जाने वाला नाम और तस्वीर (kind 0), और जब आप कोई ईमेल शेड्यूल या रद्द करते हैं तो शेड्यूलर DVM के रिले की सूची, इसी तरह मांगी जाती है: पहले गुमनाम रूप से और, अगर कोई रिले ज़िद करे, तो नीचे बताई गई अस्थायी कुंजी से, आपकी कुंजी से कभी नहीं (01-10-2026 से; उससे पहले, प्रमाणीकरण मांगने वाले रिले को आपकी कुंजी मिल जाती थी, और वह बता सकता था कि आप किसकी प्रोफ़ाइल देख रहे हैं)। सिर्फ़ आपकी अपनी प्रोफ़ाइल अब भी आपकी पहचान से पढ़ी जाती है।
• डिलीवर करना। गिफ़्ट रैप पाने वाले के DM रिले पर जाते हैं, उसी अलग कनेक्शन पर। अगर उनमें से कोई प्रमाणीकरण मांगता है, तो Herkos इसी काम के लिए बनाई गई और सिर्फ़ मेमरी में रखी गई कुंजी से जवाब देता है, आपकी कुंजी से कभी नहीं; डिवाइस पर हर खाते की अपनी अलग कुंजी होती है। रिले फिर भी देख सकता है कि एक ही डिवाइस (एक ही IP, एक ही अस्थायी कुंजी) ने एक सेशन के दौरान कई लिफ़ाफ़े भेजे।
• बड़े ईमेल। 32 KB से बड़े ईमेल की एन्क्रिप्ट की गई कॉपी Blossom सर्वर पर अपलोड की जाती है, जिनमें पाने वालों के सर्वर भी शामिल हैं। सिर्फ़ आपके अपने सर्वर (आपकी Blossom सूची) को आपकी कुंजी से अधिकृत अपलोड मिलता है। किसी भी दूसरे सर्वर को यह गुमनाम रूप से मिलता है और, अगर वह प्राधिकरण पर ज़िद करे, तो ऊपर वाली उसी अस्थायी कुंजी से साइन किया गया प्राधिकरण (01-10-2026 से; उससे पहले, हर सर्वर को आपकी कुंजी मिलती थी)। जो सर्वर सिर्फ़ जानी-पहचानी कुंजियां स्वीकार करता है, वह इसे मना कर देता है, और कॉपी दूसरे सर्वर पर रहती है।
• आपका अपना डेटा। आपके मेलबॉक्स, लेबल, सेटिंग और ड्राफ़्ट का सिंक, जहां कोई रिले मांगे, उसी खाते के रूप में प्रमाणित होता है जिसका वह डेटा है, यहां तक कि खाता बदलते समय भी। आपके अपने रिले पर इससे उन्हें कुछ ऐसा पता नहीं चलता जो उन्हें पहले से पता न हो: अनुरोधों में आपकी कुंजी का नाम वैसे भी होता है। आपके अपने रिले और Blossom की सूचियां सार्वजनिक हैं और आपकी पहचान बताए बिना मांगी जाती हैं, और ईमेल लिंक में बताए गए रिले के साथ भी ऐसा ही होता है।
• पढ़े जाने की स्थिति और फ़ोल्डर सार्वजनिक मेटाडेटा हैं (फ़िलहाल)। किसी ईमेल को पढ़ा गया, तारांकित, संग्रहित या कहीं ले जाया गया मार्क करने पर एक बिना एन्क्रिप्शन वाला NIP-32 लेबल इवेंट प्रकाशित होता है, जो आपकी सार्वजनिक कुंजी से जुड़ा होता है, जिसमें आपके बनाए फ़ोल्डर के नाम भी शामिल हैं। जो भेजने वाला आपको भेजे गए ईमेल की id जानता है, वह बता सकता है कि आपने उस पर कब कार्रवाई की। इन लेबल को एन्क्रिप्ट करने की योजना है; तब तक, फ़ोल्डर के नामों को सार्वजनिक मानें।
• पुश सूचनाएं और शेड्यूल करके भेजना तीसरे पक्ष की सेवाओं का इस्तेमाल करते हैं। पुश सर्वर (डिफ़ॉल्ट रूप से api.nmail.li) को आपकी सार्वजनिक कुंजी, एक पुश टोकन और यह पता चलता है कि आपको मेल कब मिलता है; शेड्यूलर DVM को आपकी सार्वजनिक कुंजी और वे पहले से एन्क्रिप्ट किए गए संदेश पता चलते हैं जिन्हें उसे प्रकाशित करना है। दोनों वैकल्पिक हैं और PRIVACY.md में दर्ज हैं। पुश सूचना का टेक्स्ट पुश सर्वर चुनता है, और Herkos उस पर तभी भरोसा करता है जब UnifiedPush उसे एन्क्रिप्ट करके (RFC 8291) डिलीवर करे; बिना एन्क्रिप्शन वाला पेलोड सिर्फ़ ऐप को जगाता है, ताकि वह ख़ुद मेल ले आए।
• वेब वर्शन आपकी कुंजी ब्राउज़र में रखता है, जो उसके लिए सबसे कमज़ोर जगह है। इंस्टॉल किए गए ऐप आपकी गुप्त कुंजी ऑपरेटिंग सिस्टम के सुरक्षित स्टोरेज (Android Keystore, Windows Credential Manager, libsecret, iOS/macOS Keychain) को सौंपते हैं। ब्राउज़र में इनमें से कुछ भी नहीं होता: कुंजी ओरिजिन के स्टोरेज में रहती है और हर हस्ताक्षर पर JavaScript से गुज़रती है, यानी पेज में चलने वाले किसी भी कोड की पहुंच में — हर साइट तक पहुंच वाला ब्राउज़र एक्सटेंशन, ऐप या किसी डिपेंडेंसी में XSS बग, छेड़छाड़ किया गया डिप्लॉयमेंट — और ब्राउज़र प्रोफ़ाइल कॉपी करने वाले किसी भी इन्फ़ोस्टीलर की पहुंच में भी। ऐसा कोई पल भी नहीं आता जब आप कोड को एक बार जांच लें: साइन की गई बाइनरी इंस्टॉल के समय जांची जाती है, जबकि वेब पेज हर बार खोलने पर नया कोड भेजता है। वेब वर्शन में रिमोट साइनर (NIP-46 बंकर, Amber) से लॉग इन करें, ताकि कुंजी कभी ब्राउज़र तक न पहुंचे, या उसे एक फेंकने लायक पहचान मानें और अपनी असली कुंजी किसी इंस्टॉल किए गए ऐप में रखें।
• ब्रिज से आया मेल उतना ही भरोसेमंद है जितना ब्रिज। Herkos यह जांचता है कि ब्रिज से आया बताया गया संदेश सच में किसी ऐसे ब्रिज ने साइन किया है जिसे आपने सेट किया है (या डिफ़ॉल्ट में से किसी एक ने)। ब्रिज जो पारंपरिक From: पता आगे भेजता है, उसके बारे में यह कुछ भी जांच नहीं सकता।
• अटैचमेंट ऑपरेटिंग सिस्टम खोलता है। Herkos कभी भी एक्ज़ीक्यूटेबल या स्क्रिप्ट फ़ाइल टाइप लॉन्च नहीं करता और किसी भी दूसरे ऐसे अटैचमेंट को, जिसका प्रीव्यू नहीं हो सकता, सिस्टम के डिफ़ॉल्ट ऐप को सौंपने से पहले पूछता है, लेकिन फ़ाइल खोलने वाला ऐप हमारे नियंत्रण से बाहर है।

समर्थित वर्शन

सुरक्षा सुधार नवीनतम रिलीज़ किए गए वर्शन पर लागू किए जाते हैं। प्रोजेक्ट के आकार को देखते हुए, पुराने वर्शन मेंटेन नहीं किए जाते — कृपया रिपोर्ट करने से पहले अपडेट करें।