30 مئي تي، روٽ سرٽيفڪيٽ جي 20 سالن جي صحيح مدت ختم ٿي وئي ته ھڪڙي وڏي سرٽيفڪيشن اٿارٽيز Sectigo (Comodo) جي ھڪڙي ڪراس سائن ان سرٽيفڪيٽ ٺاھيو. ڪراس-سائننگ جي اجازت ڏني وئي آھي مطابقت لاءِ ورثي جي ڊوائيسز جن وٽ نئون USERTRust روٽ سرٽيفڪيٽ شامل نه آھي انھن جي روٽ سرٽيفڪيٽ اسٽور ۾.
نظرياتي طور تي، AddTrust جي روٽ سرٽيفڪيٽ جي ختم ٿيڻ کي صرف ورثي واري نظام سان مطابقت جي خلاف ورزي ڪرڻ گهرجي (Android 2.3، Windows XP، Mac OS X 10.11، iOS 9، وغيره)، ڇاڪاڻ ته ٻئي روٽ سرٽيفڪيٽ ڪراس-دستخط ۾ استعمال ٿيل رهي ٿو. صحيح ۽ جديد برائوزر ان کي حساب ۾ وٺن ٿا جڏهن اعتماد جي زنجير کي چيڪ ڪريو. مشق تي غير برائوزر TLS ڪلائنٽ ۾ ڪراس دستخط جي تصديق سان مسئلا، بشمول OpenSSL 1.0.x ۽ GnuTLS تي ٻڌل. هڪ محفوظ ڪنيڪشن هاڻي قائم نه ڪيو ويو آهي هڪ غلطي سان جيڪو ظاهر ڪري ٿو ته سرٽيفڪيٽ تاريخ کان ٻاهر آهي جيڪڏهن سرور استعمال ڪري رهيو آهي هڪ Sectigo سرٽيفڪيٽ جيڪو اعتماد جي زنجير سان ڳنڍيل آهي AddTrust روٽ سرٽيفڪيٽ سان.
جيڪڏهن جديد برائوزرن جي استعمال ڪندڙن AddTrust روٽ سرٽيفڪيٽ جي غيرمعمولي کي نوٽيس نه ڪيو جڏهن ڪراس سائن ٿيل Sectigo سرٽيفڪيٽن کي پروسيس ڪيو ويو، پوء مسئلا مختلف ٽئين پارٽي ايپليڪيشنن ۽ سرور-سائڊ هينڊلرن ۾ پاپ اپ ٿيڻ شروع ڪيا، جنهن جي نتيجي ۾ ڪيتريون ئي انفراسٽرڪچر جيڪي اجزاء جي وچ ۾ رابطي لاءِ انڪرپٽ ٿيل ڪميونيڪيشن چينلز استعمال ڪن ٿا.
مثال طور، اتي هئا Debian ۽ Ubuntu ۾ ڪجهه پيڪيج جي ذخيرن تائين رسائي سان (apt هڪ سرٽيفڪيٽ جي تصديق جي غلطي پيدا ڪرڻ شروع ڪيو)، "curl" ۽ "wget" يوٽيلٽيز استعمال ڪندي اسڪرپٽ مان درخواستون ناڪام ٿيڻ شروع ٿي ويون، غلطيون ڏٺيون ويون جڏهن Git استعمال ڪندي، Roku اسٽريمنگ پليٽ فارم ڪم ڪري رهيو آهي، هينڊلر هاڻي نه سڏبا آهن и ، شروع ڪيو هيروڪو ايپس ۾، OpenLDAP کلائنٽ ڳنڍڻ، SMTPS ڏانهن ميل موڪلڻ ۾ مسئلا ۽ SMTP سرور سان STARTTLS معلوم ڪيا ويا آهن. ان کان سواء، مسئلا مختلف روبي، پي ايڇ ۽ پٿون اسڪرپٽ ۾ مشاهدو ڪيا ويا آهن جيڪي ماڊل استعمال ڪندا آهن http ڪلائنٽ سان. برائوزر مسئلو Epiphany، جيڪو اشتهار بلاڪ ڪرڻ جي لسٽن کي لوڊ ڪرڻ بند ڪيو.
گو پروگرام هن مسئلي کان متاثر نه آهن ڇو ته گو پيش ڪري ٿو TLS.
اهو مسئلو پراڻن تقسيم رليز کي متاثر ڪري ٿو (بشمول ديبين 9، اوبنٹو 16.04، ) جيڪي مشڪلاتي OpenSSL شاخون استعمال ڪن ٿا، پر مسئلو جڏهن ته APT پيڪيج مئنيجر هلندڙ آهي موجوده رليز ۾ Debian 10 ۽ Ubuntu 18.04/20.04، جتان APT استعمال ڪري ٿو GnuTLS لائبريري. مسئلو اهو آهي ته ڪيتريون ئي TLS/SSL لائبريريون هڪ سرٽيفڪيٽ کي لڪير واري زنجير جي طور تي پارس ڪن ٿيون، جڏهن ته RFC 4158 جي مطابق، هڪ سرٽيفڪيٽ ڪيترن ئي اعتماد واري اينڪرز سان گڏ هڪ هدايتي ورهايل سرڪيولر گراف جي نمائندگي ڪري سگهي ٿو جنهن کي حساب ۾ رکڻ جي ضرورت آهي. OpenSSL ۽ GnuTLS ۾ هن نقص بابت . OpenSSL ۾ مسئلو حل ڪيو ويو برانچ 1.1.1، ۽ ان ۾ رهي ٿو .
هڪ حل جي طور تي، اهو سسٽم اسٽور مان "AddTrust External CA Root" سرٽيفڪيٽ کي هٽائڻ جي صلاح ڏني وئي آهي (مثال طور، هٽايو /etc/ca-certificates.conf ۽ /etc/ssl/certs، ۽ پوء هلايو "update-ca -certificates -f -v")، جنهن کان پوءِ OpenSSL پنهنجي شموليت سان ڪراس سائن ٿيل سرٽيفڪيٽن کي عام طور تي پروسيس ڪرڻ شروع ڪري ٿو. APT پيڪيج مئنيجر استعمال ڪرڻ وقت، توهان پنهنجي خطري تي انفرادي درخواستن لاءِ سرٽيفڪيٽ جي تصديق کي بند ڪري سگهو ٿا (مثال طور، "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false") .
ان مسئلي کي روڪڻ لاءِ и اهو تجويز ڪيل آهي AddTrust سرٽيفڪيٽ کي بليڪ لسٽ ۾ شامل ڪرڻ:
trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract
پر هي طريقو GnuTLS لاءِ (مثال طور، ويجٽ يوٽيلٽي هلائڻ دوران سرٽيفڪيٽ جي تصديق جي غلطي ظاهر ٿيندي رهي ٿي).
سرور جي پاسي توهان ڪري سگهو ٿا سرٽيفڪيٽن جي لسٽنگ اعتماد واري زنجير ۾ سرور طرفان ڪلائنٽ ڏانهن موڪليو ويو (جيڪڏهن "AddTrust External CA Root" سان لاڳاپيل سرٽيفڪيٽ لسٽ مان هٽايو ويو آهي، پوء ڪلائنٽ جي تصديق ڪامياب ٿي ويندي). چيڪ ڪرڻ ۽ اعتماد جي هڪ نئين زنجير پيدا ڪرڻ لاء، توهان خدمت استعمال ڪري سگهو ٿا . Sectigo پڻ متبادل ڪراس دستخط ٿيل وچولي سرٽيفڪيٽ ""، جيڪو 2028 تائين صحيح هوندو ۽ او ايس جي پراڻن ورزن سان مطابقت برقرار رکندو.
اضافو: مسئلو پڻ LibreSSL ۾.
جو ذريعو: opennet.ru