Let’s Encrypt की trust chain छोटी हो रही है

 (letsencrypt.org)
2 पॉइंट द्वारा GN⁺ 2023-07-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Let’s Encrypt 30 सितंबर 2024 को समाप्त होने वाले क्रॉस-साइन (cross-sign) को बढ़ाए बिना, ISRG Root X1 पर समाप्त होने वाली छोटी certificate chain में परिवर्तन कर रहा है
  • शुरुआती लॉन्च के समय इसकी अपनी root को पर्याप्त trust नहीं मिला था, इसलिए यह IdenTrust के DST Root CA X3 पर निर्भर था, लेकिन अब ISRG Root X1 का trust coverage काफी बढ़ गया है
  • 2021 में पुरानी Android compatibility के लिए जो अतिरिक्त root cross-sign जोड़ा गया था, वह एक अस्थायी उपाय था, और उसकी वजह से पुराने Android डिवाइस Let’s Encrypt certificates पर 3 साल और trust कर सके
  • पिछले 3 सालों में ISRG Root X1 पर trust करने वाले Android डिवाइसों का अनुपात 66% से 93.9% तक बढ़ा है, और cross-sign हटाने पर TLS handshake में certificate bytes भी 40% से अधिक कम हो जाते हैं
  • Android 7.0 से नीचे उपयोगकर्ताओं को Firefox Mobile इस्तेमाल करने की सिफारिश की जाती है, और site operators तथा ACME client authors को 2024 transition schedule के अनुसार chain handling की जांच करनी चाहिए

cross-sign समाप्ति की पृष्ठभूमि

  • Let’s Encrypt ने शुरुआती लॉन्च के समय certificates को व्यापक trust दिलाने के लिए IdenTrust के DST Root CA X3 से intermediate certificate को cross-sign किया था
    • यह ऐसा तरीका था जिसमें, भले ही इसकी अपनी root ISRG Root X1 अभी व्यापक रूप से trusted न हो, उस intermediate certificate द्वारा जारी certificates पर trust मिल सके
  • समय के साथ ISRG Root X1 को स्वयं व्यापक trust मिलने लगा
  • 2021 के अंत में cross-signed intermediate certificate और DST Root CA X3, दोनों के expire होने की उम्मीद थी
    • उस समय modern browsers Let’s Encrypt root पर trust करते थे, लेकिन Android डिवाइसों के एक-तिहाई से अधिक अभी भी पुराने OS versions चला रहे थे
    • ऐसे डिवाइस अचानक Let’s Encrypt certificates इस्तेमाल करने वाली websites पर trust करना बंद कर सकते थे
  • Let’s Encrypt ने 2021 में intermediate certificate के बजाय सीधे root पर cross-sign लागू किया, ताकि DST Root CA X3 से अधिक समय तक चलने वाला अस्थायी उपाय तैयार किया जा सके
    • इस कदम से पुराने Android डिवाइस Let’s Encrypt certificates पर 3 साल और trust कर सके
  • यह cross-sign 30 सितंबर 2024 को expire हो जाता है

छोटी chain में बदलने की वजह

  • Let’s Encrypt compatibility बढ़ाने के लिए नया cross-sign अब नहीं ले रहा है
    • पिछले 3 सालों में ISRG Root X1 पर trust करने वाले Android डिवाइसों का अनुपात 66% से 93.9% तक बढ़ा है
    • Android 14 पूरे OS update के बिना trust store को update कर सकता है, इसलिए यह अनुपात और बढ़ सकता है
    • cross-sign हटाने से TLS handshake में भेजे जाने वाले certificate bytes की संख्या 40% से अधिक घट जाती है
    • इससे operating costs भी काफी कम होती हैं, जिससे Let’s Encrypt privacy और security improvements पर funding अधिक केंद्रित कर सकता है

2024 transition schedule

  • गुरुवार, 8 फ़रवरी 2024: /acme/certificate API endpoint requests में default cross-sign देना बंद किया गया
    • अधिकांश subscribers के लिए ACME client ISRG Root X1 पर समाप्त होने वाली chain सेट करेगा, और web server TLS handshake में छोटी chain देगा
    • जल्द expire होने वाले cross-sign पर समाप्त होने वाली लंबी chain को alternate chain के रूप में अभी भी request किया जा सकता था
  • गुरुवार, 6 जून 2024: लंबी cross-signed chain देना पूरी तरह बंद किया गया
    • यह cross-sign expiry से 90 दिन से थोड़ा अधिक पहले का समय था, जो एक certificate lifetime के बराबर है
    • यह schedule इसलिए रखा गया ताकि subscribers को cross-signed chain से बाहर आने के लिए कम से कम एक पूरा issuance cycle मिल सके
  • सोमवार, 30 सितंबर 2024: cross-signed certificate expire हो जाता है
    • अधिकांश users के लिए यह कोई अलग घटना नहीं होनी चाहिए, और client failures पिछले 6 महीनों में पहले ही सामने आ जाने चाहिए थे

users और operators को क्या जांचना चाहिए

  • Android 7.0 से नीचे users को Let’s Encrypt certificate से सुरक्षित websites तक पहुंच जारी रखने के लिए कार्रवाई करनी पड़ सकती है
    • Let’s Encrypt Firefox Mobile को install और use करने की सलाह देता है, क्योंकि यह Android OS trust store की बजाय अपना trust store इस्तेमाल करता है
  • site operators को 2024 की दूसरी और तीसरी तिमाही में website usage statistics और active user-agent strings की जांच करनी चाहिए
    • अगर Android visits अचानक कम हो जाएं, तो संभव है कि Android 7.0 या उससे नीचे के users की संख्या काफी हो
    • ऐसे users को Firefox Mobile इस्तेमाल करने का मार्गदर्शन देना recommended है
  • ACME client authors को हर certificate issuance और renewal के समय API द्वारा दी गई certificate chain को सही तरीके से download और install करना चाहिए
    • पहले देखी गई failure types में ऐसे मामले शामिल थे जहाँ chain को बिल्कुल download नहीं किया गया और केवल end-entity certificate serve किया गया
    • कुछ मामलों में chain download किए बिना hardcoded chain serve की गई
    • कुछ मामलों में chain केवल पहली issuance के समय download की गई और renewal पर दोबारा download नहीं की गई
  • transition से जुड़े सवाल Let’s Encrypt community forum में पूछे जा सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-11
Hacker News की राय

  • याद है कि Let's Encrypt ने 2019 की गर्मियों में कहा था कि वह यह बदलाव करेगा, लेकिन community feedback सुनने के बाद इसे टाल दिया था
    उस समय मैं उन लोगों में से एक था जो ज़ोर देकर कह रहे थे कि इसे फिर से सोचा जाए, लेकिन इस मामले में उम्मीद से कहीं ज़्यादा बढ़कर साढ़े 4 साल की देरी होगी, यह नहीं सोचा था। TLS ecosystem को इतनी सावधानी से संभालने के लिए आभारी हूँ

    • क्या कोई समझा सकता है? मैं इसका इस्तेमाल करता हूँ, लेकिन अक्सर भूल जाता हूँ कि Let's Encrypt मेरी वेबसाइट के लिए कितना महत्वपूर्ण है

  • Android डिवाइसों के 95% को कवर करने के लिए अगस्त 2016 के Android 7.0 Nougat तक support चाहिए
    https://en.wikipedia.org/wiki/Android_Nougat
    iOS डिवाइसों के 95% कवरेज के लिए सितंबर 2020 का iOS 14 ही काफी है, और 90% देखें तो Android 8.1 (2017) है, जबकि iOS 15 (2021)
    https://iosref.com/ios-usage
    https://en.wikipedia.org/wiki/IOS_14
    लगता है Apple लोगों को नए operating system पर जाने के लिए मनाने या अनुमति देने में ज़्यादा बेहतर है

    • Apple विकासशील देशों में 10 डॉलर वाले फोन नहीं बेचता। अगर प्रमुख manufacturer या carrier के उसी price range वाले डिवाइसों की तुलना करें, तो अंतर इतना चरम नहीं होगा
    • बात और सरल है। Apple तीसरे पक्ष को iPhone बनाने नहीं देता, जबकि Google तीसरे पक्ष को Android फोन बनाने देता है
      डिवाइस update न होने की वजह यह है कि manufacturer updates देना बंद कर देता है
    • operating system upgrade को Google और device manufacturer मिलकर खराब तरीके से संभालते हैं, लेकिन CA bundle को operating system version से बंधा होना चाहिए, इसकी कोई वजह नहीं है
      curl के CA bundle पेज के मुताबिक Mozilla bundle, decompress करने पर, लगभग 200KB है, और मेरे Android में Chrome app 25MB का है, इसलिए app size में 1% बढ़ोतरी करके इसे updated रखना तर्कसंगत लगता है
      बेशक, दूसरे apps भी नया CA चाह सकते हैं, लेकिन यह भी देखने लायक है कि क्या सभी CA चाहिए, या सिर्फ वही CA काफी हैं जिनके वास्तव में इस्तेमाल होने की संभावना है
    • अगर आप hardware और software की पूरी stack को नियंत्रित करते हैं, तो ग्राहकों के पुराने डिवाइसों को updated रखना बहुत आसान हो जाता है
      अगर कोई low-cost manufacturer तय कर ले कि वह customers को updates नहीं देगा, तो Google बहुत कुछ नहीं कर सकता। Android certification पाने या बनाए रखने के लिए वह कुछ समय तक updates देने की शर्त रख सकता है, लेकिन किसी बिंदु पर वह manufacturer खुद Android छोड़ भी सकता है
      ऊपर से Qualcomm भी पुराने chipsets के लिए समय के साथ updated kernel और blobs देना बंद कर देता है। Google ने पहले के दयनीय 18 महीनों से ज़्यादा अवधि दिलवाने के लिए बातचीत की, लेकिन Qualcomm पर और सहयोग करने की कोई बाध्यता नहीं है। Google ने अपने chipsets बनाने शुरू किए, तो इस समस्या में उसकी रुचि भी कुछ कम हो गई
      इसका मतलब यह नहीं कि यह अच्छा है, लेकिन Android के मॉडल में आम तौर पर यही होना तय है, और Apple का मॉडल इन बातों पर ज़्यादा नियंत्रण देता है
    • मेरे मामले में वजह बेहतर camera है

  • पुराने cross-sign को लगातार काम करता रखने का तरीका काफ़ी दिलचस्प था
    नया cross-sign कुछ असामान्य था, क्योंकि वह DST Root CA X3 की expiry के बाद तक भी चलता था। यह इसलिए संभव था क्योंकि Android, trust anchor के रूप में इस्तेमाल होने वाले certificate की expiry date को जानबूझकर लागू नहीं करता
    वास्तव में trust anchor दूसरे certificates की तुलना में काफ़ी अलग तरह से काम करते हैं, और यह हैरान कर सकता है
    [1] https://letsencrypt.org/2020/12/21/extending-android-compati...
    [2] https://alexsci.com/blog/name-non-constraint/

    • यह समाधान पूरी तरह परफेक्ट नहीं था। ज़्यादातर चीज़ें काफ़ी जल्दी सुलझ गईं, लेकिन इससे LE फ़ोरम पर मेरी देखी सबसे लंबी threads में से एक बन गई: https://community.letsencrypt.org/t/help-thread-for-dst-root...
      याद पड़ता है कि बड़ी समस्याओं में से एक यह थी कि पुराने OpenSSL ने root anchor expiry की जाँच की थी। और बस वही नहीं, उस समय हमारी कंपनी में Ubuntu को इस स्थिति को संभालने के लिए कुछ patch करना पड़ा था, और patch expiry से कुछ दिन पहले ही आया, इसलिए कुछ systems में थोड़ी देर के लिए outage हुआ। समस्या ठीक करने के लिए Docker images को बड़े पैमाने पर फिर से build करना पड़ा
      यह workaround इतना आक्रामक और अभूतपूर्व था कि लगता है इसे सिर्फ इसलिए चुना गया होगा क्योंकि इसकी तुलना में ऐसी root से cross-sign लेने की लागत बहुत अधिक थी जो expired न हो और व्यापक रूप से compatible हो। शायद भारी testing भी करनी पड़ी होगी। यह पूरी तरह flawless नहीं था, लेकिन कुल मिलाकर इसका काफ़ी smooth तरीके से निकल जाना प्रभावशाली था
    • यह थोड़ा हैरान करने वाला था कि Android का तरीका दूसरी जगहों पर सामान्य तरीका नहीं है। मैं सोचता था कि TLS certificate chain C0 -> C1 -> C2 ... -> Cn की time validation लगभग इस pseudocode की तरह चलती होगी
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 time_check = cert.issue_time
      6 return NOT_EXPIRED
      लेकिन खोजने पर पता चला कि असल में यह 5वीं पंक्ति के बिना चलता है, इसलिए सभी time checks मौजूदा समय के आधार पर होते हैं। chain के सभी certificates अभी वैध होने चाहिए
      code signing certificate उस तरीके से काम करते हैं जैसा मैं समझता था कि TLS भी करेगा। अगर code पर timestamp लगा है, तो root certificate expire हो जाने के बाद भी, अगर timestamp के समय root वैध था, तो वह अब भी वैध रहता है

  • उम्मीद है कि cross-signing certificate की expiry ज़्यादातर लोगों के लिए बिना किसी असर के गुज़रेगी, लेकिन पिछली DST cross-sign expiry ऐसी नहीं थी
    याद पड़ता है कि GnuTLS expiry के बाद path building सही तरीके से नहीं कर पाया था। लगता है उसने सिर्फ expired certificate तक जाने वाला path बनाया, उसे expired बताया, और बाकी संभव paths को नज़रअंदाज़ करके रुक गया
    इससे भी बुरी बात यह थी कि apt में HTTPS इस्तेमाल होने पर GnuTLS वही TLS library थी। HTTPS default नहीं था, लेकिन हमारी security team चाहती थी कि सभी packages को vendoring करके सुरक्षित तरीके से दिया जाए, और यह अपने आप में उचित था, लेकिन इसकी कीमत outages के रूप में चुकानी पड़ी। लगता है Bullseye में यह ठीक हुआ था, और वह भी महज़ किस्मत से expiry से लगभग एक हफ़्ता पहले। Azure को भी उस expiry से जुड़े कई outages झेलने पड़े थे

    • क्या सभी apt mirror operators certbot से लगभग महीने में एक बार LE certificate renew नहीं करते? अगर ऐसा है, तो 6 जून 2024 के बाद उन्हें ऐसे certificates मिलने चाहिए जो expired न हों और cross-signed भी न हों, बल्कि नए LE root से signed हों — या मैं कुछ मिस कर रहा हूँ?

  • unencrypted HTTP इस्तेमाल करने के अलावा, क्या कोई प्रस्तावित समाधान है जिससे TLS वेब का सबसे कमज़ोर घटक न रहे?
    protocol deprecation, certificate expiry, replacement जैसी लगातार बदलती चीज़ें planned obsolescence को हद से ज़्यादा बढ़ाती हुई लगती हैं

    • मैं TLS को वेब का सबसे कमज़ोर घटक नहीं मानता। वह ख़िताब शायद DNS, BGP, या मानदंड के अनुसार us-east-1 को मिलेगा
    • समस्या यह नहीं है कि TLS बदलता रहता है। सुरक्षा के लिए उसका बदलना ज़रूरी है
      planned obsolescence वाली बुरी बात यह है कि devices बहुत जल्दी manufacturer updates से वंचित हो जाते हैं, और third parties भी उन्हें update नहीं कर सकतीं
      मेरा पसंदीदा समाधान यह है कि अगर कोई manufacturer बिक्री बंद होने के 10 साल पूरे होने से पहले security updates बनाना बंद करता है या करना चाहता है, तो उसे सब कुछ open source करना होगा, या फिर सभी buyers को पूरा refund देना होगा
    • TLS में ज़्यादातर असुविधा शायद certificate reissuance को लगातार follow करते रहने की ज़रूरत से आती है
      इसकी वजह यह है कि वैश्विक स्तर पर distributed revocation एक बेहद मुश्किल समस्या है। users और certificates के बीच कुछ हद तक जुड़ाव ऐसा है कि उसे व्यवहार में revoke करना लगभग असंभव हो जाता है, इसलिए certificate lifetime छोटा करके blast radius कम किया जाता है
      यह कोई बहुत बड़ा दिलासा नहीं है, लेकिन ACME के बाद की short-lived certificate दुनिया, लंबे समय तक चलने वाले Verisign certificates की दुःस्वप्न जैसी दुनिया की तुलना में developer experience के लिहाज़ से बेहतर है। यह याद रखने लायक है कि TLS के alternatives को भी लगभग ऐसी ही समस्याओं का सामना करना पड़ेगा
    • मूल रूप से मेरा मानना है कि किसी भी entity पर हमेशा के लिए भरोसा नहीं किया जा सकता। सबसे अच्छा समाधान यह है कि सामान्य update path से अलग certificate updates दिए जाएँ
      x509 certificate format वास्तव में बहुत लंबे समय से बदला नहीं है
      protocol changes अब स्थिर होते दिखते हैं। TLS 1.2, 2008 में आया था और आज भी ठीक माना जाता है, इसलिए उसे अब नया कहना मुश्किल है। बहुत लोगों ने उसे गहराई से देखा है, इसलिए उम्मीद है कि ज़्यादातर समस्याएँ सामने आ चुकी होंगी
    • DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named...
      मेरी राय में Let's Encrypt जो करता है, वह मूल रूप से DANE जैसा भी माना जा सकता है, तो फिर उसे बस support क्यों न किया जाए। हाँ, हो सकता है कुछ use cases ऐसे हों जहाँ DANE उपयुक्त न हो
      perfect को good enough का दुश्मन बनने की ज़रूरत नहीं है, और जो लोग चाहें उन्हें DANE इस्तेमाल करने देना चाहिए

  • “operating costs को काफ़ी घटाकर privacy और security improvements के लिए funding केंद्रित की जा सकती है” — क्या इसका मतलब है कि वे cross-signing पर सैकड़ों हज़ार या लाखों डॉलर जैसी राशि दे रहे हैं?

    • 2021 के Form 990 के अनुसार, Identrust को “Internet Services” मद में 434,000 डॉलर दिए गए थे। मुझे नहीं पता कि Identrust से cross-signing के अलावा और क्या लिया गया था, लेकिन संभव है कि यह राशि cross-signing की लागत हो
      उसी साल कुल खर्च 5.1 million डॉलर था, इसलिए यह व्यय बजट का लगभग 10% बैठता है
      [0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...

  • क्या किसी को यह अंदरूनी कहानी पता है कि certificate company cross-signing के लिए कैसे राज़ी हुई? क्या Let’s Encrypt उनका business model पूरी तरह खत्म नहीं कर देता?

    • Let's Encrypt ने जिस business model को मारा, वह सालाना 10 डॉलर वाले domain-validated certificates बेचने का मॉडल था। wildcard चाहिए होता तो वह काफ़ी ज़्यादा महँगा पड़ता
      RapidSSL या GoDaddy जैसी कंपनियाँ शायद Let’s Encrypt को cross-signing तब तक न देतीं, जब तक उन्हें “हमारा पूरा CA business ही खरीद लो” स्तर की रकम न मिलती
      लेकिन DV certificates बेचना IdenTrust का business model नहीं था, इसलिए जैसा कुछ और लोगों ने अनुमान लगाया है, वह शायद 6-figure से कम रकम में cross-signing देने को तैयार था। TLS root certificates के काम करने के तरीके के कारण, IdenTrust की cross-signing भी LE के लिए उतनी ही उपयोगी थी जितनी किसी बेहद लाभदायक CA की cross-signing होती
    • अगर मैं ऐसी certificate company होता जिसका target market enterprise है, और जहाँ Let’s Encrypt के इस्तेमाल की संभावना कम है, तो मैं Let’s Encrypt को cross-signing इसलिए देता ताकि उन competitors को कमज़ोर कर सकूँ जो small businesses या दूसरे projects पर ज़्यादा निर्भर हैं, और जिन्हें Let’s Encrypt ज़्यादा आकर्षित करता है
    • शायद उन्हें पैसे देकर मनाया गया होगा। अगर उन्होंने नहीं किया होता, तो कोई और कर देता
      ऐसा भी नहीं लगता कि IdenTrust डूब गया हो
      1 IdenTrust 48.5% 53.6%
      2 DigiCert Group 13.1% 14.5%
      3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
      4 GlobalSign 6.1% 6.7%
      5 Let's Encrypt 5.8% 6.4%
      6 GoDaddy Group 4.8% 5.3%
      https://en.wikipedia.org/wiki/Certificate_authority
    • बिल्कुल नहीं। बड़े certificate authorities सभी enterprise customers को बेचते हैं, और आगे भी बेचते रहेंगे। Letsencrypt के ज़्यादातर users व्यक्तिगत या hobbyist क्षेत्र के ज़्यादा क़रीब हैं

  • 2021 के अंत में जब cross-signed intermediate certificate और DST Root CA X3 खुद expire हुए, तब सभी आधुनिक browsers LE root पर भरोसा करते थे, लेकिन एक-तिहाई से ज़्यादा Android devices अभी भी पुराने operating system चला रहे थे, इसलिए ऐसी स्थिति बन गई थी कि LE certificate इस्तेमाल करने वाली websites पर वे अचानक भरोसा नहीं कर पाते।
    कुछ हफ्ते पहले ही पता चला, ubiquiti users भी शायद प्रभावित हुए थे

  • हाल ही में AWS से backend को local server पर शिफ्ट करते समय, हमेशा की तरह Letsencrypt इस्तेमाल करने के बजाय ZeroSSL पर जाना पड़ा।
    वजह यह थी कि support में मौजूद 2016 के IoT उपकरणों में LE certificate validation के लिए ज़रूरी root certificate था ही नहीं। शायद यह LE द्वारा इस्तेमाल किए गए R3 root certificate की 2021 expiry से जुड़ा मामला था।
    यह काफ़ी चौंकाने वाली बात थी कि सिर्फ एक certificate expire होने से बेचे गए पूरे products ईंट के समान बेकार हो सकते हैं। इस मामले में किसी दूसरे provider का valid root certificate मौजूद था, इसलिए बड़ी समस्या नहीं हुई।

    • जब SHA-1 को चरणबद्ध तरीके से हटाया जा रहा था, तब medical devices और POS systems में SHA-1 certificate डाल चुके और उन्हें update करने का लगभग कोई तरीका न रखने वाले कई CAs ने mozilla.dev.security.policy में खूब शिकायतें की थीं।
      उन्होंने CA/Browser Forum द्वारा तय की गई तारीख़ के बाद भी उन्हें जारी रखना जारी रखा। मुझे लगा था कि तब सबको समझ आ गया था कि Web PKI का इस्तेमाल करते हुए update push करने का कोई तरीका न होना साथ-साथ नहीं चल सकता, लेकिन शायद ऐसा नहीं था

  • cross-signing शुरू होने के तुरंत बाद से ही desktop-उन्मुख sites में cross-signed certificate हटाए जाते रहे हैं।
    क्योंकि इससे ऐसी compatibility problems पैदा हुईं जो पहले नहीं थीं, और कुछ certificate validators expired root certificate पर अटक जाते थे। प्रभावित users तकनीकी नहीं थे, इसलिए वे अंत तक मूल कारण जान ही नहीं सके