Cloudflare ने 8 सितंबर 2026 को Automatic Key Exchange की जारी चरणबद्ध उपलब्धता के नए माप प्रकाशित किए। Cloudflare की तकनीकी घोषणा के अनुसार, स्कैन किए गए डोमेन के ओरिजिन कनेक्शनों में HelloRetryRequest की हिस्सेदारी लगभग 52% से घटकर 3.7% रह गई और 90वें प्रतिशतक पर नए TLS हैंडशेक का विलंब 150 मिलीसेकंड से अधिक घटा।
यह 8 सितंबर का बदलाव ब्राउज़र से Cloudflare तक के कनेक्शन या हर वेब अनुरोध को तेज करने का दावा नहीं है। उसी दिन प्रकाशित Tech Planet की स्वतंत्र कवरेज ने Cloudflare के इन्हीं परिणामों और जारी चरणबद्ध उपलब्धता का विवरण दिया, लेकिन आंकड़े कंपनी के अपने स्कैन किए हुए समूह से आए हैं; किसी स्वतंत्र परीक्षण से नहीं।
दूसरे ClientHello की जरूरत क्यों घटी
नया तंत्र Cloudflare से ग्राहक के ओरिजिन सर्वर तक बनने वाले TLS 1.3 कनेक्शन को बदलता है। इस प्रक्रिया में Cloudflare ग्राहक की तरह काम करते हुए शुरुआती ClientHello में समर्थित कुंजी-सहमति एल्गोरिदम और एक या अधिक कुंजी-अंश भेजता है। ओरिजिन उस चुनाव को स्वीकार कर ले तो हैंडशेक एक नेटवर्क चक्कर में पूरा हो सकता है।
पहले Cloudflare हर ओरिजिन के लिए आरंभिक कुंजी-अंश के रूप में स्थिर X25519 भेजता था। कोई ओरिजिन अलग एल्गोरिदम चाहता तो वह HelloRetryRequest लौटाता, जिसके बाद नए कुंजी-अंश के साथ दूसरा ClientHello भेजना पड़ता था। कनेक्शन सामान्यतः सफल रहता था, लेकिन सामग्री मंगाने से पहले एक अतिरिक्त नेटवर्क चक्कर जुड़ जाता था।
Automatic Key Exchange उत्पादन यातायात से अलग हल्के TLS प्रयासों द्वारा सक्रिय ओरिजिन की क्षमताएं मापता है। वह X25519, P-256, P-384, P-521 और संकर पोस्ट-क्वांटम X25519MLKEM768 में से समर्थित विकल्प पहचानता है, फिर अगले नए कनेक्शन में पसंदीदा कुंजी-अंश पहले भेजता है। चुनाव सीमित यातायात पर लगाया जाता है; विफलता या दोबारा प्रयास बढ़ने पर पुरानी प्राथमिकता लौटाई जा सकती है।
52% से 3.7% हर अनुरोध की गति नहीं है
शीर्षक का प्रतिशत पृष्ठ खुलने के कुल समय में कमी नहीं दिखाता। यह स्कैन किए गए डोमेन के उन ओरिजिन TLS कनेक्शनों की हिस्सेदारी है जिन्हें Automatic Key Exchange से पहले HelloRetryRequest चाहिए था। इसी समूह में अतिरिक्त नेटवर्क चक्कर हटने से 90वें प्रतिशतक का हैंडशेक विलंब 150 मिलीसेकंड से अधिक घटा।
लाभ केवल तब बनता है जब Cloudflare को ओरिजिन के साथ नया TLS 1.3 कनेक्शन खोलना पड़े। गतिशील अनुरोध या CDN कैश में अनुपलब्ध सामग्री ऐसा कनेक्शन मांग सकती है, जबकि पहले से खुले और दोबारा इस्तेमाल हो रहे कनेक्शन नया कुंजी-विनिमय नहीं करते। इसलिए वास्तविक उपयोगकर्ता-विलंब में बदलाव नए ओरिजिन कनेक्शनों की आवृत्ति और Cloudflare से ओरिजिन तक नेटवर्क दूरी पर निर्भर करेगा।
इन परिणामों को भारत की किसी एक वेबसाइट पर सीधे लागू नहीं किया जा सकता। कंपनी ने पूरे नेटवर्क की हर साइट या हर अनुरोध के लिए 48.3 प्रतिशत-अंक की कमी नहीं बताई; माप उस शुरुआती समूह के स्कैन किए गए ओरिजिन कनेक्शनों का है जिस पर नई प्राथमिकताएं लागू हुई थीं।
योग्यता TLS 1.3, एन्क्रिप्शन मोड और सीधे मार्ग से तय होती है
Cloudflare का विन्यास दस्तावेज दायरा सीमित करता है: क्षेत्र का मोड Full, Full (strict) या Strict (SSL-Only Origin Pull) होना चाहिए, ओरिजिन को Cloudflare के साथ TLS 1.3 तय करना चाहिए और कनेक्शन Cloudflare Tunnel से नहीं गुजरना चाहिए। सुविधा सभी योजनाओं में उपलब्ध, मौजूदा क्षेत्रों में सक्रिय और नए क्षेत्रों में पूर्वनिर्धारित रूप से सक्रिय है; यह केवल नए TLS कनेक्शनों को प्रभावित करती है।
एन्क्रिप्शन मोड और Automatic Key Exchange अलग नियंत्रण हैं। पहला तय करता है कि Cloudflare ओरिजिन तक HTTPS इस्तेमाल करेगा या नहीं और प्रमाणपत्र कैसे जांचेगा। दूसरा HTTPS कनेक्शन शुरू करते समय भेजे जाने वाले कुंजी-अंशों की प्राथमिकता बदलता है; Flexible या केवल HTTP वाले ओरिजिन को यह अपने आप योग्य TLS 1.3 ओरिजिन में नहीं बदलता।
Cloudflare Tunnel का अपवाद भी सुरक्षा की अनुपस्थिति नहीं बताता। Tunnel में cloudflared और Cloudflare के बीच अलग पोस्ट-क्वांटम कनेक्शन होता है, इसलिए सार्वजनिक ओरिजिन TLS समापन बिंदु को स्कैन करने वाली Automatic Key Exchange प्रक्रिया उस मार्ग पर लागू नहीं होती।
पोस्ट-क्वांटम लाभ ओरिजिन की क्षमता पर रुकता है
Automatic Key Exchange असंगत सर्वर में X25519MLKEM768 समर्थन जोड़ नहीं सकता। ओरिजिन और रास्ते के भार-संतुलक, वेब अनुप्रयोग सुरक्षा उपकरण तथा अन्य TLS समापन बिंदु संकर विकल्प संभाल सकें तो Cloudflare उसे प्राथमिकता दे सकता है। समर्थन न मिले तो तंत्र संगत पारंपरिक विकल्प चुनता है; अनावश्यक दोबारा प्रयास फिर भी घट सकता है, पर कनेक्शन पोस्ट-क्वांटम नहीं बनता।
संचालक के लिए लागू स्थिति इन चार बिंदुओं से स्पष्ट होती है:
Cloudflare डैशबोर्ड में SSL/TLS के तहत Origin connection & post-quantum encryption खोलकर Automatic Key Exchange की स्थिति देखें।
पुष्टि करें कि क्षेत्र Full, Full (strict) या Strict (SSL-Only Origin Pull) मोड में है और वास्तविक ओरिजिन Cloudflare के साथ TLS 1.3 तय करता है।
ओरिजिन, भार-संतुलक और TLS यातायात को समाप्त या जांचने वाले प्रत्येक उपकरण में X25519MLKEM768 संगतता जांचें।
Cloudflare Tunnel वाले क्षेत्र में इस सेटिंग को सुरक्षा-संकेतक न मानें, क्योंकि उसका कनेक्शन मार्ग अलग है।
Compliance requirements में केवल Post-quantum hybrid चुनना स्वतः चयन से अधिक कठोर नीति है। यह Cloudflare को केवल X25519MLKEM768 इस्तेमाल करने देता है, पर ओरिजिन को नई क्षमता नहीं देता। यदि कोई साझा एल्गोरिदम न बचे तो TLS 1.3 कनेक्शन विफल होंगे; इसलिए स्वतः प्राथमिकता और अनिवार्य पोस्ट-क्वांटम नीति एक ही सुविधा के दो अलग व्यवहार हैं।
अभी एक क्षेत्र के लिए एक ही प्राथमिकता
किसी क्षेत्र में कई सक्रिय ओरिजिन हों तो Cloudflare उनके यातायात-भारित परिणामों से एक साझा कुंजी-सहमति प्राथमिकता निकालता है। लगभग हर 24 घंटे होने वाला स्कैन बदले हुए सर्वर या TLS पुस्तकालय की क्षमता पकड़ सकता है, पर मौजूदा व्यवस्था में अलग-अलग ओरिजिन के लिए अलग प्राथमिकता तय नहीं की जा सकती।
Cloudflare प्रति उपडोमेन या प्रति ओरिजिन अधिक सूक्ष्म चयन और डैशबोर्ड अथवा API से मांग पर नया स्कैन देने पर काम कर रहा है; ये अभी उपलब्ध सुविधाएं नहीं हैं। फिलहाल पुष्टि इतनी है कि चरणबद्ध उपलब्धता जारी है, योग्य नए TLS 1.3 ओरिजिन कनेक्शनों में दोबारा प्रयास घटे हैं और पोस्ट-क्वांटम चुनाव तभी होता है जब पूरा ओरिजिन मार्ग X25519MLKEM768 संभाल सके।
