Въведение
HTTPS (чрез SSL /TLS) използва криптиране с публичен ключ за защита на комуникациите в браузъра от четене или промяна при транзит през Интернет. Сървърите предоставят на посещаващите браузъри публичен ключ, който се използва за установяване на криптирана връзка за всички последващи обмени на данни.
Само че получаването на a работа публичният ключ сам по себе си не гарантира, че той (и чрез разширението на сървъра) наистина е собственост на правилното дистанционно предмет (т.е. лице, компания или организация). Човек-в-средата нападателите могат да манипулират мрежи, за да обслужват собствените си ключове, като по този начин компрометират всяка комуникация.
Браузърите предотвратяват това чрез при удостоверяването HTTPS сървъри, използващи сертификати, които са цифрови документи, които обвърже публичен ключ към отделен предмет. Обвързването се потвърждава, като се има доверие сертифициращ орган (CA), като например SSL.com проверка на самоличността на потенциалните собственици на сертификати чрез автоматизирани и ръчни проверки на квалифицирани бази данни.
Това доверие означава, че сигурността на потребителите в мрежата не е абсолютна; по-скоро изисква потребителите да се доверяват на браузъри и сертифициращи органи за защита на тяхната сигурност. Затова смятаме, че е в интерес на всеки потребител да има основно разбиране за това как работи валидирането на сертификата.
Обърнете внимание, че процесът на валидиране на сертификата (описан подробно в стандартен документ RFC 5280) е доста объркан. В тази статия ще се опитаме да ви преведем по един път (браузър, утвърждаващ SSL на хоста /TLS сертификат) и се придвижвайте в минали сложни детайли, които са несъществени за повечето потребители.
Сертификати и формат X.509
Сертификатите са цифрови файлове във всяко отношение, което означава, че те трябва да следват файлов формат, за да съхраняват информация (например подписи, ключове, издатели и т.н.). Докато частна PKI конфигурациите могат да внедрят всеки формат за своите сертификати, публично доверени PKIs (т.е. тези, на които се вярва на браузърите) трябва да съответстват на RFC 5280, което изисква използването на X.509 v3 формат.
X.509 v3 позволява на сертификатите да включват допълнителни данни, като например ограничения за използване или информация за политиката разширения, като всяко разширение е едно или друго критичен or некритични, Браузърите могат да игнорират невалидни или неразпознати некритични разширения, но те са длъжни да обработват и валидират всички критични.
Пътеки за сертифициране и обработка на пътя
СА използват частен ключ за криптографско подписване на всички издадени сертификати. Подобни подписи могат безвъзвратно да докажат, че сертификат е издаден от конкретен орган на CA и че той не е бил променен след подписването му.
Отговорните органи установяват собствеността върху своя ключ за подпис, като притежават сертификат за самостоятелно издаване (наречен корен) за съответния публичен ключ. КС трябва да спазват строго контролирани и одитирани процедури за създаване, управление и използване на корен, а за да се намали експозицията, обикновено се използва корен за издаване междинен сертификати. След това тези междинни продукти могат да се използват за издаване на сертификати на техните клиенти.
Браузърите се доставят с вграден списък с надеждни корени. (Това са корени от CA, които са преминали строгите критерии на браузъра за включване.) За да провери сертификат, браузърът ще получи поредица от сертификати, всеки от които е подписал следващия сертификат в последователността, свързвайки корена на подписващия CA към сървъра удостоверение.
Тази последователност на сертификати се нарича a сертификационен път. Коренът на пътя се нарича a доверете се котва и сертификатът на сървъра се нарича листо or крайно образувание сертификат.
Пътно строителство
Често браузърите трябва да обмислят множество пътища за сертифициране, докато не намерят валиден за даден сертификат. Въпреки че пътят може да съдържа сертификати, които се „свързват“ правилно към известна котва, самият път може да бъде отхвърлен поради ограничения върху дължината на пътя, името на домейна, използването на сертификата или политиката.
Конструирането и оценяването на всички възможни пътища е скъп процес, изпълняван за всеки нов сертификат, с който браузър се сблъсква. Браузърите са внедрили различни оптимизации, за да сведат до минимум броя на отхвърлените пътеки за кандидат, но задълбочаването на такива подробности е далеч извън обхвата на тази статия.
Валидиране на пътя
След изграждането на път за сертифициране на кандидат, браузърите го валидират, използвайки информация, съдържаща се в сертификатите. Път е валиден, ако браузърите могат да докажат криптографски, че като се започне от сертификат, директно подписан от доверителен котва, съответният частен ключ на всеки сертификат е бил използван за издаване на следващия в пътя, чак до сертификата на листа.
Алгоритъм за валидиране на пътя на сертифициране
RFC 5280 описва a стандартен алгоритъм които браузърите следват, за да валидират пътя на сертифициране на X.509 сертификати.
По принцип браузърите итерират през всички сертификати в пътя, започвайки с доверителния котва (т.е. основния сертификат), като валидират основната информация за всеки сертификат и критичните разширения.
Ако процедурата приключи с последния сертификат в пътя без грешки, тогава пътят се приема като валиден. Ако се генерират грешки, пътят се маркира като невалиден.
Основна обработка на сертификати
Независимо от разширенията, браузърите трябва винаги да проверяват основна информация за сертификата, като подпис или издател. Следващите раздели показват последователността на проверките, които браузърите извършват.
1. Браузърът проверява целостта на сертификата
- подпис върху сертификата може да се провери с помощта на нормална криптография с публичен ключ. Ако подписът е невалиден, сертификатът се счита за модифициран след издаването му и следователно се отхвърля.
2. Браузърът проверява валидността на сертификата
Сертификат срок на валидност е интервалът от време, през който подписващият CA гарантира, че ще поддържа информация за състоянието си. Браузърите отхвърлят всякакви сертификати с период на валидност, който завършва преди или започва след датата и часа на проверката за валидиране.
3. Браузърът проверява състоянието на отмяна на сертификата
Когато се издава сертификат, се очаква той да бъде използван през целия му срок на валидност. Разбира се, различни обстоятелства могат да накарат даден сертификат да стане невалиден, преди естествено да изтече.
Такива обстоятелства могат да включват промяна на името на субекта или съмнение за компрометиране на личния им ключ. В случаи като този CA трябва да отмени съответния сертификат и потребителите също така се доверяват на CA, за да уведомят браузърите за състоянието на оттегляне на техните сертификати.
RFC 5280 препоръчва на ЦО да използват списъци за анулиране за тази цел.
Списъци за анулиране на сертификати (CRL)
ЦО периодично издават подписан, подпечатан във времето списък на отменени сертификати, наречен a списък за отмяна на сертификат (CRL). CRL се разпространяват в публично достъпни хранилища и браузърите могат да придобиват и да се консултират с най-новата CRL на CA при валидиране на сертификат.
Един недостатък на този метод е, че времевата детайлност на отмяната е ограничена до периода на издаване на CRL. Браузърът ще бъде уведомен за оттегляне само след като всички планирани CRL са планирани да бъдат актуализирани. В зависимост от политиката на подписващия CA това може да отнеме час, ден или дори до седмица.
Протокол за онлайн сертификат (OCSP)
Съществуват и други алтернативни методи за придобиване на информация за статута на анулиране, като най-популярният е този Протокол за състояние на сертификата онлайн (OCSP).
Описано е в стандартен документ RFC6960, OCSP позволява на браузър да поиска специфичен статус на оттегляне на сертификат от онлайн OCSP сървър (наричан още a репондер). Когато е правилно конфигуриран, OCSP е много по-незабавен и избягва споменатия по-горе проблем с закъсненията за актуализация на CRL. В допълнение, OCSP Сшиване подобрява производителността и скоростта.
4. Браузърът проверява издателя
Сертификатите обикновено се свързват с две организации:
- - емитент, което е субектът, който притежава ключа за подписване и
- - предмет, който се отнася до собственика на публичния ключ, който удостоверява удостоверението.
Браузърите проверяват дали сертификатът е емитент полето е същото като предмет поле на предишния сертификат в пътя. За допълнителна сигурност най-много PKI изпълненията също така проверяват дали ключът на издателя е същият като ключа, подписал текущия сертификат. (Обърнете внимание, че това не е вярно за доверителния котва, тъй като корените са самоиздадени - т.е. те имат един и същ издател и предмет.)
Обработка на ограничения
Форматът X.509 v3 позволява на CA да определя ограничения или ограничения за това как всеки сертификат е валидиран и използван като критични разширения. Всеки сертификат в пътя може да наложи допълнителни ограничения, на които трябва да се спазват всички следващи сертификати.
Ограниченията на сертификатите рядко засягат обикновения потребител на Интернет, въпреки че те са доста често срещани в корпоративните SSL решения. Функционалните ограничения могат да служат на няколко оперативни цели, но най-значимото им използване е за смекчаване на известни проблеми със сигурността.
5. Браузърът проверява ограниченията на имената
Частен (но публично доверен) междинен сертификат със съответния ограничения на имената може да осигури на организация фин контрол върху управлението и издаването на сертификати. Сертификатите могат да бъдат ограничени до определен домейн или дърво на домейна (т.е. включително поддомейни) за име на домейн на компания или организация. Ограниченията на имената често се използват за междинни CA сертификати, закупени от публично доверен CA, за да попречат на междинния CA да издава напълно валидни сертификати за домейни на трети страни (напр. google.com).
6. Браузърът проверява ограниченията на политиката
Политиката за сертификати е правен документ, публикуван от СО, официално описва подробно процедурите, които следват за издаване и управление на техните сертификати. CA могат да издадат сертификат по една или повече политики и връзките към тях са включени във всеки издаден сертификат, така че разчитащите се страни могат да оценят тези правила, преди да решат да се доверят на този сертификат.
По правни и оперативни причини сертификатите могат да налагат ограничения върху кои политики могат да бъдат подложени. Ако се установи, че сертификат съдържа критични ограничения на политиката, браузърите трябва да ги валидират, преди да продължат. (Въпреки това в реалния свят рядко се срещат критични ограничения на политиката и затова ще бъдат пренебрегвани в останалата част от тази статия.)
7. Браузърът проверява основните ограничения (известни още като дължина на пътя)
Форматът X.509 v3 позволява на издателите да определят максималната дължина на пътя, която сертификатът може да поддържа. Това осигурява контрол върху това до каква степен всеки сертификат може да бъде поставен в пътя на сертифициране. Това всъщност е важно - през 2009 г. браузърите са пренебрегвали дължината на пътя на сертифициране, докато изследовател не демонстрира представяне, как е използвал сертификата за листа на своя уебсайт, за да подправи валиден сертификат за голям уебсайт за електронна търговия.
8. Браузърът проверява използването на ключовете
Разширението „Използване на ключ“ посочва целта на ключа, съдържащ се в сертификата. Примери за такива цели включват шифроване, подписи, подписване на сертификати и т.н. Браузърите отхвърлят сертификати, нарушаващи ограниченията им за използване на ключове, като например да срещнат сертификат на сървър с ключ, предназначен само за подписване на CRL.
9. Браузърът продължава да обработва всички останали критични разширения
След обработка на разширенията, споменати по-горе, браузърите продължават да валидират всички останали разширения, които текущият сертификат определя като критични, преди да преминат към следващото. Ако браузърът достигне сертификат за листа на пътя без грешка, тогава пътят се приема за валиден. Ако се появят някакви грешки, пътят е маркиран като невалиден и не е установена защитена връзка.
Заключение
World Wide Web е сложна система от взаимосвързани и постоянно развиващи се движещи се части. По този начин сигурността на браузъра не е решен проблем и се надяваме, че тази статия е предоставила известна представа за сложността дори на един компонент, който разгледахме тук. Доверието играе основна роля за поддържането на сигурността ви онлайн и поради тази причина ви призоваваме да попитате повече за политиката за сертифициране на вашия CA. (Чувствайте се свободни за преглед Правилата на SSL.com тук, всъщност.)
Благодарим ви, че избрахте SSL.com, където вярваме, че a по-безопасно Интернет е а по-добре Интернет.
