د می په 30، د روټ سند د 20 کلن اعتبار موده پای ته ورسیده کوم چې د یو ترټولو لوی تصدیق کونکي چارواکو Sectigo (Comodo) څخه د کراس لاسلیک شوي سندونو رامینځته کولو لپاره. کراس لاسلیک کول د میراثي وسیلو سره د مطابقت لپاره اجازه ورکړل شوې چې نوي USERTRust روټ سند د دوی د روټ سند پلورنځي کې اضافه شوی نه و.
په تیوریکي توګه، د AddTrust روټ سند پای ته رسیدل باید یوازې د میراث سیسټمونو (Android 2.3، Windows XP، Mac OS X 10.11، iOS 9، او نور) سره د مطابقت سرغړونې لامل شي، ځکه چې د دویم روټ سند په کراس لاسلیک کې کارول کیږي. معتبر او عصري براوزرونه دا په پام کې نیسي کله چې د باور سلسله چک کوي. په تمرین کې په غیر براوزر TLS پیرودونکو کې د کراس لاسلیک تصدیق سره ستونزې ، پشمول د OpenSSL 1.0.x او GnuTLS پراساس. یو خوندي پیوستون نور د یوې غلطۍ سره ندی رامینځته شوی چې دا په ګوته کوي چې سند زوړ دی که چیرې سرور د سیکټیګو سند کاروي چې د اډ ټرسټ روټ سند سره د باور سلسله پورې تړلی وي.
که چیرې د عصري براوزرونو کاروونکو د کراس لاسلیک شوي سیکټیګو سندونو پروسس کولو پر مهال د AddTrust روټ سند ناڅرګندتیا په پام کې ونه نیوله ، نو بیا د مختلف دریمې ډلې غوښتنلیکونو او سرور اړخ هینډلرونو کې ستونزې راپورته کیدل پیل شوي ، کوم چې د دې لامل شوی. ډیری زیربناوې چې د اجزاو ترمنځ د تعامل لپاره کوډ شوي ارتباطي چینلونه کاروي.
د مثال په توګه، هلته وو په Debian او Ubuntu کې د بسته بندۍ ځینې زیرمو ته د لاسرسي سره (apt د سند تصدیق کولو غلطي رامینځته کول پیل کړل) ، د "curl" او "wget" اسانتیاو په کارولو سره د سکریپټونو څخه غوښتنې ناکامې شوې ، د Git کارولو پرمهال غلطی لیدل شوي ، د Roku سټیمینګ پلیټ فارم کار کوي ، هینډلر نور نه ویل کیږي и ، پیل شو په هیروکو ایپسونو کې، د OpenLDAP پیرودونکي نښلوي، د STARTTLS سره SMTPS او SMTP سرورونو ته د بریښنالیک لیږلو کې ستونزې کشف شوي. برسېره پردې، ستونزې په مختلفو روبي، پی ایچ پی او پایتون سکریپټونو کې لیدل کیږي چې د http مراجعینو سره ماډل کاروي. د براوزر ستونزه Epiphany، کوم چې د اعلاناتو بلاک کولو لیستونو پورته کول بند کړل.
د Go پروګرامونه د دې ستونزې لخوا اغیزمن شوي ندي ځکه چې Go وړاندیز کوي TLS.
دا ستونزه د پخوانیو توزیع خپرونو اغیزه کوي (د Debian 9، Ubuntu 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 استخراج
مګر دا طریقه د GnuTLS لپاره (د مثال په توګه، د ویجیټ یوټیلیټ چلولو پرمهال د سند تصدیق کولو تېروتنه دوام لري).
د سرور اړخ کې تاسو کولی شئ د اعتبار سلسله کې د سندونو لیست کول د سرور لخوا پیرودونکي ته لیږل شوي (که چیرې د "AddTrust External CA Root" سره تړلی سند له لیست څخه لرې شي ، نو د پیرودونکي تایید به بریالی وي). د باور نوی سلسله چیک او رامینځته کولو لپاره ، تاسو کولی شئ خدمت وکاروئ . Sectigo هم بدیل سره لاسلیک شوي منځګړیتوب سند ""، کوم چې به تر 2028 پورې اعتبار ولري او د OS پخوانیو نسخو سره مطابقت وساتي.
اضافه: ستونزه هم په LibreSSL کې.
سرچینه: opennet.ru