मूल रूप से ब्राउज़रों के लिए विकसित, एसएसएल / टीएलएस प्रोटोकॉल बाद में सभी सुरक्षित इंटरनेट संचारों के लिए वास्तविक मानक बन गया। अब इसका उपयोग क्लाउड में तैनात वर्चुअल इन्फ्रास्ट्रक्चर के दूरस्थ प्रशासन के लिए किया जाता है, ग्राहक के भुगतान विवरण को ई-कॉमर्स सर्वर से भुगतान प्रोसेसर जैसे पेपाल और अमेज़ॅन पर स्थानांतरित करने के लिए, स्थानीय डेटा को क्लाउड स्टोरेज में भेजने के लिए, तत्काल दूतों में पत्राचार को सहेजना और मोबाइल अनुप्रयोगों में सर्वर प्रमाणीकरण। iOS और Android।

उन स्थितियों की सूची जहां अत्यधिक संवेदनशील सूचनाओं के आदान-प्रदान के लिए अधिकतम सुरक्षा की आवश्यकता होती है, वे काफी प्रभावशाली हैं। इस लेख में, हम जांच करेंगे कि इन संचारों की सुरक्षा व्यवहार में कैसे सुनिश्चित होती है।

- एसएसएल / टीएलएस प्रोटोकॉल: वे सबसे अच्छा चाहते थे ...
- ... लेकिन यह हमेशा की तरह निकला: असफल एसएसएल / टीएलएस प्रमाणपत्र सत्यापन के उदाहरण
- एसएसएल / टीएलएस प्रोटोकॉल की तार्किक कमजोरियां
- अन्य सामान्य एसएसएल / टीएलएस प्रोटोकॉल कार्यान्वयन कमजोरियां
एसएसएल / टीएलएस प्रोटोकॉल में कमजोरियों का मूल कारण
- एक बैरल टार में एक चम्मच शहद

एसएसएल / टीएलएस प्रोटोकॉल: हम सबसे अच्छा चाहते थे ...

सिद्धांत रूप में, एक सुरक्षित एसएसएल / टीएलएस प्रोटोकॉल कनेक्शन को क्लाइंट और सर्वर सॉफ्टवेयर संचार की गोपनीयता, विश्वसनीयता और अखंडता सुनिश्चित करना चाहिए, यहां तक ​​कि नेटवर्क से एक सक्रिय उन्नत हमलावर की उपस्थिति में: जब नेटवर्क पूरी तरह से दुश्मन द्वारा लिया जाता है, तो DNS जहर होता है, और पॉइंट और राउटर, स्विच का उपयोग करता है। और वाईफाई को एक हमलावर द्वारा नियंत्रित किया जाता है; एक हमलावर, जो अन्य बातों के अलावा, एक एसएसएल / टीएलएस बैकएंड को नियंत्रित करता है। इसके अलावा, जब क्लाइंट सॉफ़्टवेयर एक वैध सर्वर से जुड़ने की कोशिश करता है, तो एक हमलावर सर्वर के नेटवर्क पते (उदाहरण के लिए, डीएनएस विषाक्तता के माध्यम से) को बदल सकता है, और एक वैध सर्वर के बजाय ग्राहक को उसके दुर्भावनापूर्ण सर्वर पर पुनर्निर्देशित कर सकता है।

ऐसी कठोर परिस्थितियों में संचार की सुरक्षा, जैसा कि आप जानते हैं, पूरी तरह से कनेक्शन स्थापित करते समय सर्वर द्वारा प्रदान किए गए क्रिप्टोग्राफिक प्रमाण पत्र के सत्यापन की पर्याप्तता पर निर्भर करता है। जिसमें सिफर्स (सिपर्सुइट) के सेट के कार्यान्वयन की पर्याप्तता शामिल है, जो ग्राहक और सर्वर डेटा का आदान-प्रदान करते समय उपयोग करते हैं। एसएसएल / टीएलएस कनेक्शन पूरी तरह से सुरक्षित होने के लिए, क्लाइंट सॉफ्टवेयर, अन्य बातों के अलावा, इसे सावधानीपूर्वक सत्यापित करना चाहिए:

• वर्तमान प्रमाणन निकाय द्वारा जारी प्रमाण पत्र;
• इसकी वैधता अवधि समाप्त नहीं हुई है (या प्रमाणपत्र को रद्द नहीं किया गया है);
• प्रमाणपत्र में सूचीबद्ध नामों की सूची में वह डोमेन है जिसमें आप कनेक्ट कर रहे हैं।

... लेकिन यह हमेशा की तरह निकला: असफल एसएसएल / टीएलएस प्रमाणपत्र सत्यापन के उदाहरण

हालाँकि, कई अनुप्रयोगों और पुस्तकालयों में जिनके लिए संचार सुरक्षा बहुत महत्वपूर्ण है, एक SSL / TLS प्रमाणपत्र की पुष्टि करने की प्रक्रिया - और यहां तक ​​कि EV-SSL, एक उन्नत सत्यापन प्रमाणपत्र [4] - पूरी तरह से असफल है। सभी लोकप्रिय ऑपरेटिंग सिस्टम में: लिनक्स, विंडोज, एंड्रॉइड और आईओएस। कमजोर सॉफ्टवेयर, पुस्तकालयों और मिडलवेयर सेवाओं के बीच, निम्नलिखित को प्रतिष्ठित किया जा सकता है:

• अमेज़न के EC2 जावा पुस्तकालय और इसके आधार पर निर्मित सभी क्लाउड-आधारित फ्रंट-एंड क्लाइंट।
• गेटवे से भुगतान करने के लिए साइटों (जिस पर ऑनलाइन कॉमर्स का बुनियादी ढांचा तैनात है) से भुगतान विवरणों की डिलीवरी के लिए जिम्मेदार अमेज़ॅन और पेपाल की ट्रेडिंग एसडीके।
• एकीकृत "बास्केट", जैसे कि ओस्काम, ज़ेनकार्ट, उबर्कार्ट और प्रेस्टाशॉप, जो कि प्रमाण पत्र को मान्य नहीं करते हैं।
• प्रासंगिक विज्ञापन प्रदर्शित करने के लिए मोबाइल सॉफ्टवेयर द्वारा AdMob कोड का उपयोग किया जाता है।
• क्लाउड स्टोरेज के साथ इंटरैक्ट करने के लिए जिम्मेदार एलीफेंटड्राइव और फाइल्सऐनएयर इंटरफेस को सामने रखें।
• पुशर एंड्रॉइड लाइब्रेरी और सभी सॉफ्टवेयर जो इंस्टेंट मैसेजिंग (उदाहरण के लिए, GitHub's Gaug.es) को नियंत्रित करने के लिए Pusher API का उपयोग करते हैं।
• अपाचे HttpClient (संस्करण 3.x); अपाचे Libcloud और Apache ActiveMQ सर्वर, आदि के लिए सभी क्लाइंट कनेक्शन
• Apache Axis, Axis 2, Codehaus XFire सहित Java SOAP मिडलवेयर सेवाएं; साथ ही साथ सभी सॉफ्टवेयर जो इन मिडिलवेयर सेवाओं के आधार पर बनाए गए हैं।
• लोचदार लोड संतुलन एपीआई उपकरण
• वेबबर्क्स का वेबरनेच कार्यान्वयन।
• साथ ही ऊपर सूचीबद्ध पुस्तकालयों और मिडलवेयर सेवाओं के आधार पर निर्मित सभी मोबाइल सॉफ़्टवेयर (यह समझने के लिए कि मिडलवेयर सेवाएँ क्या हैं, चित्र 1 देखें); होस्टिंग प्रदाता रैकस्पेस के आईओएस क्लाइंट सहित।

चित्र 1. मिडलवेयर सेवाएं क्या हैं

इसके अलावा, [2] में भी सौ से अधिक असुरक्षित मोबाइल एप्लिकेशन सूचीबद्ध हैं (देखें। अंजीर। २)। जिनमें शामिल हैं: Android के Google क्लाउड मैसेजिंग, एंजी की सूची व्यापार केंद्र पासवर्ड, एटी एंड टी ग्लोबल नेटवर्क क्लाइंट, कैपिटलऑन स्पार्क पे, सिस्को ओनप्लस (रिमोट एक्सेस), सिस्को टेक्निकल सपोर्ट, सिस्को वीबेक्स, सिस्को वीएक्स पासवर्ड, डोमिनोज पिज्जा, ई-ट्रेड, फ्रीलांसर , गूगल अर्थ, हंटिंगटन मोबाइल (बैंक), इनटैक टैक्स ऑनलाइन अकाउंटेंट, आईट्यून्स कनेक्ट, माइक्रोसॉफ्ट स्काइप, ओरेकल नाउ, पिंटरेस्ट, सेफनेट (वीपीएन क्लाइंट), साउथवेस्ट एयरलाइंस, उबेर, यूएस बैंक - ऑनलाइन एक्सेस, वेस्टर्नयूनियन, वर्डप्रेस, याहू! वित्त, याहू! मेल।

चित्रा 2. कमजोर मोबाइल अनुप्रयोगों की सूची में से एक छोटा सा चयन

एसएसएल / टीएलएस तार्किक कमजोरियाँ

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

मोबाइल सॉफ़्टवेयर विक्रेता, जो AdMob खाते के साथ अपने अनुप्रयोगों को जोड़ने के लिए AdMob नमूना कोड लेते हैं, वे भी असुरक्षित हैं - वे एक हमलावर को क्रेडेंशियल्स पर कब्जा करने और उसकी सभी Google सेवाओं तक पहुंच प्राप्त करने की अनुमति देते हैं। उदाहरण के लिए, ट्रिलियन और एआईएम जैसे दूतों में प्रमाणपत्रों के गलत सत्यापन के कारण, एक MiTM- हमलावर सभी Google सेवाओं (जीमेल सहित), याहू के लिए लॉगिन क्रेडेंशियल्स चुरा सकता है! और विंडोज लाइव सेवाओं (स्काईड्राइव सहित) के लिए भी। आधुनिक गैर-ब्राउज़र वेब सॉफ़्टवेयर को प्रभावित करने वाली अन्य कमजोरियों में शामिल हैं: होस्ट नाम की तुलना करते समय गलत नियमित अभिव्यक्तियों का उपयोग; प्रमाणपत्र सत्यापन परिणामों की अनदेखी; सत्यापन का आकस्मिक या जानबूझकर बंद करना। [1]

अन्य सामान्य एसएसएल / टीएलएस प्रोटोकॉल कार्यान्वयन कमजोरियां

और निश्चित रूप से, हमें यह नहीं भूलना चाहिए कि भले ही एसएसएल / टीएलएस प्रोटोकॉल के कार्यान्वयन में कोई तार्किक त्रुटि न हो (जब तक कि कोई व्यक्ति अभी भी इस पर विश्वास नहीं करता है), निजी कुंजी को चोरी करके बाईपास किया जा सकता है [12], 0day का उपयोग करके। कीबोर्ड, ब्राउज़र, ऑपरेटिंग सिस्टम, उपयोगिताओं और फर्मवेयर [3] जैसी चीजों के लिए शोषण; बीजीपी रूटिंग [10] से समझौता करके; या हार्डवेयर पर एसएसएल / टीएलएस पर हमला (चित्र 3 देखें) [8] और / या सॉफ्टवेयर [9] बायपास चैनल।

चित्र 3. हार्डवेयर बाईपास पर एसएसएल हमला

इसके अलावा, हमलावर SSLSessionCache वर्ग में लागू SSL / TLS सत्र कैशिंग तंत्र का दुरुपयोग करते हुए व्यावहारिक रूप से अदृश्य MiTM हमलों को अंजाम दे सकते हैं। यह तंत्र प्रारंभिक कनेक्शन पर केवल प्रमाण पत्र की वैधता की जांच करता है; न ही यह डिवाइस से प्रमाणपत्र हटाने के बाद संचार सत्र को ठीक से रद्द करने में सक्षम है। इसके अलावा, एंड्रॉइड डिवाइस ("रिस्टार्ट" या "पावर ऑफ" विकल्पों के माध्यम से) को रिबूट करने के बाद, आप कुछ एप्लिकेशन के एन्क्रिप्ट किए गए ट्रैफ़िक को देखना जारी रख सकते हैं जो रिबूट के बाद शुरू नहीं हुए, लेकिन रिबूट से पहले काम किया। इसलिए उदाहरण के लिए Google मैप्स होता है। [२] में, यह वर्णित किया गया है कि, इन कैशिंग दोषों के लिए धन्यवाद, एक हमलावर पूरी तरह से पारदर्शी रूप से उपयोगकर्ता के लिए "अदृश्य प्रमाण पत्र" को सेट और निकाल सकता है, और फिर किसी भी एप्लिकेशन के साथ नेटवर्क कनेक्शन स्थापित कर सकता है।

चित्रा 4. कमजोर एन्क्रिप्शन का पूर्वव्यापी

एसएसएल / टीएलएस प्रोटोकॉल कार्यान्वयन में अन्य सामान्य कमजोरियों में असुरक्षित एन्क्रिप्शन (चित्र 4 देखें) [5], जीसीएम का पुन: उपयोग (गैल्विस / काउंटर मोड; गैलोज प्रमाणीकरण के साथ काउंटर) [6], सीएनजी (क्रिप्टोकरंसी-एनजी) के साथ चाल शामिल है ) स्कैनेल में (देखें। छवि 5) [7], ट्रस्ट चेन का गलत सत्यापन [2], मेजबान नाम का गलत सत्यापन [11]।

चित्रा 5. सीएनजी चाल: स्कैनेल से रहस्यों को खींचना

विश्वास श्रृंखला का एक गलत सत्यापन एक ऐसी स्थिति है जब वेब एप्लिकेशन बिल्कुल किसी भी प्रमाण पत्र को स्वीकार करता है जो सही मेजबान नाम को इंगित करता है, यह जांचे बिना कि किस प्रमाण पत्र प्राधिकरण के साथ हस्ताक्षर किए गए थे। इससे आप पासवर्ड और / या क्रेडिट कार्ड नंबर को इंटरसेप्ट और डिक्रिप्ट कर सकते हैं। और कुछ मामलों में दुर्भावनापूर्ण कोड का एक इंजेक्शन भी लगाते हैं। एंड्रॉइड सॉफ़्टवेयर में, यह भेद्यता प्रवेश करती है, उदाहरण के लिए, जब एक अनुकूलित X509TrustManger इंटरफ़ेस बनाया जाता है जो सर्टिफ़िकेट अपवाद अपवादों की उपेक्षा करता है। या जब कोई सॉफ्टवेयर डेवलपर किसी WebViews घटक के कोड में SslErrorHandler.proceed () विधि में एक कॉल सम्मिलित करता है। [2]

एक गलत होस्ट नाम सत्यापन एक ऐसी स्थिति है जब एक वेब एप्लिकेशन यह सुनिश्चित किए बिना एक प्रमाण पत्र स्वीकार करता है कि जिस होस्ट से यह प्रमाणपत्र आया है वह विश्वसनीय होस्ट की सूची में है। एंड्रॉइड सॉफ़्टवेयर में, यह भेद्यता प्रवेश करती है, उदाहरण के लिए, जब एक HostnameVerifier इंटरफ़ेस बनाया जाता है, जो किसी भी परिस्थिति में TRUE लौटाता है। या जब कोई सॉफ्टवेयर डेवलपर किसी WebViews घटक के कोड में SslErrorHandler.proceed () विधि में एक कॉल सम्मिलित करता है। [2]

एसएसएल / टीएलएस प्रोटोकॉल में कमजोरियों का मूल कारण

इन भेद्यताओं के विशाल बहुमत का मूल कारण SSL / TLS पुस्तकालयों (JSSE, OpenSSL, और GnuTLS सहित) का भयानक API डिज़ाइन है। साथ ही डेटा ट्रांसफर लाइब्रेरी (जैसे कि cURL, Apache HttpClient और urllib) की समान रूप से भयानक डिज़ाइन, जिनमें से प्रत्येक SSL / TLS लाइब्रेरीज़ के लिए एक उच्च-स्तरीय आवरण है। मिडिलवेयर सेवाओं (जैसे कि अपाचे एक्सिस, एक्सिस 2, या कोडहॉस एक्सफायर) का उल्लेख नहीं करना चाहिए, जो कि एक उच्च स्तरीय आवरण भी हैं, और जो भयानक डिजाइन के "स्नोबॉल" को और भी अधिक बढ़ाते हैं। अनुप्रयोग डेवलपर (अक्सर सिस्टम प्रोग्रामिंग से दूर) के साथ उस भाषा में संवाद करने के बजाय जिसे वह समझता है (गोपनीयता और प्रमाणीकरण के संदर्भ में), एसएसएल / टीएलएस प्रोटोकॉल कार्यान्वयन के निम्न-स्तरीय विवरणों से सारगर्भित, ये एपीआई गरीब आदमी पर निम्न-स्तरीय एसएसएल / टीएलएस मापदंडों का एक गुच्छा डंप करते हैं। उसे समझ से बाहर है। उन्हें निम्न-स्तरीय विकल्पों को सही ढंग से उजागर करने के लिए उच्च-स्तरीय सॉफ़्टवेयर की आवश्यकता होती है; कार्यान्वयन नाम सत्यापन कार्यों की मेजबानी करता है और निम्न-स्तरीय संचालन द्वारा लौटाए गए मूल्यों की व्याख्या का ध्यान रखता है।

परिणामस्वरूप, एप्लिकेशन डेवलपर्स गलत तरीके से SSL / TLS API का उपयोग करते हैं: वे गलती से अपने मापदंडों, विकल्पों, दुष्प्रभावों और वापसी मूल्यों की विविधता की व्याख्या करते हैं। उदाहरण के लिए [1]:

• अमेज़न की लचीली भुगतान सेवा PHP लाइब्रेरी TRUE (CURL लाइब्रेरी में) CURLOPT_SSL_VERIFYHOST पैरामीटर सेट करके होस्ट नाम सत्यापन को सक्षम करने का प्रयास करती है। हालाँकि, इस पैरामीटर के लिए सही डिफ़ॉल्ट मान 2 है; यदि आप इसे TRUE का मान प्रदान करते हैं, तो यह पैरामीटर अदृश्य रूप से डेवलपर के लिए मान 1 निर्दिष्ट करता है, और इसी तरह। प्रमाणपत्र सत्यापन अक्षम है।
• PHP लाइब्रेरी पेपल पेमेंट स्टैंडर्ड - एक ही त्रुटि मिली; इसके अलावा, उस समय जब पिछली, असुरक्षित, कार्यान्वयन अपडेट किया गया था (यानी, एक त्रुटि को हटा दिया गया था, दूसरा जोड़ा गया था)।
• एक अन्य उदाहरण लिंक्स, एक पाठ-उन्मुख ब्राउज़र है। यह स्व-हस्ताक्षरित प्रमाणपत्रों की पुष्टि करता है - लेकिन केवल अगर GnuTLS प्रमाणपत्र सत्यापन फ़ंक्शन नकारात्मक मान लौटाता है। हालाँकि, यह फ़ंक्शन कुछ त्रुटियों के लिए 0 देता है; उन मामलों में शामिल हैं जहां प्रमाण पत्र पर हस्ताक्षर किए गए हैं। इस वजह से, लिंक्स में विश्वास श्रृंखला टूट गई है।

इसके अलावा, एप्लिकेशन डेवलपर्स अक्सर गलत समझ लेते हैं कि किस तरह की सुरक्षा किसी विशेष एसएसएल / टीएलएस लाइब्रेरी की गारंटी देती है। इसलिए, जंगली एक में नैदानिक ​​मामलों का सामना कर सकता है जब अनुप्रयोगों में जिन्हें मूल रूप से सुरक्षित संचार की आवश्यकता होती है (उदाहरण के लिए, भुगतान प्रोसेसर के साथ बातचीत), एक एसएसएल / टीएलएस पुस्तकालय का उपयोग किया जाता है जो एसएसएल / टीएलएस प्रमाणपत्रों की बिल्कुल भी जांच नहीं करता है। अधिक अभियुक्त, लेकिन इससे भी अधिक जानलेवा मामले तब होते हैं, जब किसी भी इंटरमीडिएट सॉफ्टवेयर लेयर के डेवलपर एसएसएल / टीएलएस प्रमाणपत्रों की जांच करने की प्रक्रिया को चुपचाप निष्क्रिय कर देते हैं (वह ऐसा कर सकते हैं, उदाहरण के लिए, सिस्टम का परीक्षण करने के लिए, और परीक्षण के बाद इसे फिर से सक्षम करना भूल जाते हैं)। उसी समय, इस मध्यवर्ती परत का उपयोग करने वाले उच्च-स्तरीय प्रोग्राम कोड सुनिश्चित होते हैं कि प्रमाणपत्र सत्यापन किया जाता है। इस प्रकार एसएसएल / टीएलएस त्रुटियां अक्सर एक ही समय में पुस्तकालयों की एक या कई मध्यवर्ती परतों की गहराई में छिपी होती हैं - जिससे इस समस्या का पता लगाना लगभग असंभव हो जाता है।

उदाहरण के लिए, JSSE (जावा सिक्योर सॉकेट एक्सटेंशन) में, SSLSocketFactory एपीआई विस्तारित इंटरफ़ेस चुपचाप होस्ट नाम की जाँच करता है यदि SSL क्लाइंट में "एल्गोरिथ्म" फ़ील्ड NULL या खाली स्ट्रिंग पर सेट है, और HTTPS से नहीं। यद्यपि यह तथ्य JSSE संदर्भ गाइड में उल्लिखित है, कई जावा एसएसएल प्रोटोकॉल कार्यान्वयन होस्टनाम सत्यापन के बिना SSLSocketFactory का उपयोग करते हैं ...

एक बैरल टार में एक चम्मच शहद

इस प्रकार, वास्तव में, यह पता चला है कि अधिकांश आधुनिक गैर-ब्राउज़र वेब सॉफ्टवेयर में एसएसएल / टीएलएस प्रमाणपत्रों का सत्यापन या तो पूरी तरह से अक्षम है या गलत तरीके से लागू किया गया है। चित्र 7 वर्तमान एसएसएल / टीएलएस प्रोटोकॉल कमजोरियों के वर्गीकरण को दर्शाता है। इन कमजोरियों में से कुछ, लेकिन सभी नहीं, ऊपर वर्णित और / या वर्णित हैं। आप ग्रंथ सूची में सूचीबद्ध सामग्रियों को पढ़कर अपने आप को उल्लेखित लेकिन अवांछनीय कमजोरियों से परिचित कर सकते हैं।

चित्रा 6. एसएसएल / टीएलएस के लिए प्रासंगिक कमजोरियों का वर्गीकरण

खैर, टार बैरल में एक चम्मच शहद जोड़ने के लिए, यह ध्यान देने योग्य है कि [1] में विस्तार से वर्णन किया गया था / समझ से / लोकप्रिय / सक्षम रूप से कैसे एसएसएल को लागू किया जाना चाहिए, आरएफसी के संदर्भ में। हम एक बेहतर विवरण के साथ कभी नहीं आए हैं, जो तकनीकी रूप से सटीक होगा और एक ही समय में समझ में आएगा। इसके अलावा [1] में, सबसे आम एसएसएल लाइब्रेरीज़ का विश्लेषण किया जाता है, जिसमें एब्सट्रैक्शन (निम्न-स्तर / उच्च-स्तर) के स्तर के अनुसार वर्गीकरण होता है। सभी छद्म कोड में आरेख और संक्षिप्त एल्गोरिदम के साथ। विशिष्ट उत्पादों की कमजोरियों को गलत कोड और त्रुटि कोड के साथ विस्तार से वर्णित किया गया है। इसलिए अगर अचानक किसी को एक बार फिर एसएसएल / टीएलएस फ्रेमवर्क के ऐसे कार्यान्वयन को बनाने की इच्छा है, जो यह कहने के लिए एक अपवाद होगा कि "वे सबसे अच्छा चाहते थे, लेकिन यह हमेशा की तरह निकला", तो [1] इसके लिए एक आदर्श शुरुआत है।