SSL / TLS 101 за начинаещи

Задълбочен поглед върху криптирането, което осигурява нашите интернет връзки


Докато първоначално Netscape е изобретил SSL в средата на 90-те, той не стана задължителен за всеки уебсайт да инсталира SSL / TLS сертификат до лятото на 2018 г., когато Google започна да маркира незашифровани сайтове “Не е сигурно.”

Въпреки че Google – със своята търсачка, браузър Chrome и Android OS – може да предефинира едностранно интернет, той не беше сам на този мандат. Apple, Microsoft, Mozilla и другите основни заинтересовани страни в технологичната индустрия взеха съгласувано решение за мандат на SSL / TLS сертификати и HTTPS.

Причината за това е проста: без SSL / TLS и възможността за сигурно свързване чрез HTTPS, цялата комуникация между уебсайтове и техните посетители ще бъде обменена в открит текст и лесно четима от трета страна.

Единственият недостатък на този скорошен тласък за универсално криптиране е, че той принуждава приток на нови клиенти към непознат пазар, който прави много малко, за да се превърне в по-малко объркващ за обикновения собственик на уебсайт или бизнес.

Тази статия ще служи като изчерпателно ръководство за всички неща SSL / TLS, ще поставим основата, като преминем основни понятия като криптиране, HTTPS и естеството на интернет връзките.

Надяваме се, че до края ще се почувствате уверени при избора, закупуването и внедряването на TLS сертификат и не забравяйте дали имате някакви въпроси, които можете да ги оставите в коментарите по-долу.

Основни елементи

Нека започнем с обсъждането на концепцията, която е в основата на всичко това: криптиране.

Шифроването, в най-честата си итерация, е малко повече от кодирането на данни – с помощта на предварително определен шифър или ключ – така че да бъде направено нечетливо от всеки, освен друга страна със същия частен ключ.

През цялата история криптирането на частния ключ е най-често използваният модел. При криптиране на частния ключ и двете страни трябва да притежават или поне да обменят частен ключ, който може да се използва както за криптиране, така и за декриптиране на информация.

В началото повечето от шифрите, залегнали в основата на тези криптосистеми, бяха примитивни, разчитайки на прости замествания или заменяйки общи думи с символи. Но с течение на времето шифрите станаха по-повлияни от математиката и нарастваха в сложност.

Например, в средата на 1600 г. във Франция криптографът на крал Луи XIV създаде шифър, който беше толкова добре проектиран, че не беше разбит чак след 250 години и едва тогава частично. И до днес във френските архиви има записи на стойност стотици години, които никога не могат да бъдат дешифрирани.

Но докато историческото криптиране е било средство за скрито или тайно, появата на интернет е превзела концепцията по-масово. Интернет е повсеместен и той се справя с редица критични функции. Всеки ден милиарди хора го използват за достъп и изпращане на чувствителна информация, управление на финансите им, сключване на сделки с бизнеса – ти го казваш.

Проблемът е, че интернет не е бил изцяло проектиран да мащабира това, което е станал. В началото, в дните, когато академичните среди и правителството на САЩ за първи път разработват мрежови протоколи, интернет се разглежда само като механизъм за безплатен обмен на информация между правителството и академичните институции. В този момент търговската дейност беше незаконна онлайн. Електронната търговия не беше дума, която дори беше изобретен още. И уебсайтът беше по-скоро географско понятие.

Така че, когато HTTP или протоколът за прехвърляне на хипертекст беше представен за първи път през 1991 г., фактът, че връзките, които образуваха, обменяха данни в незабележим текст, не представляваше дисквалифициращ проблем.

Днес нещата са много по-различни. Информацията, която се обменя онлайн, не е академично изследване или свободно достъпна информация, това е лично идентифицираща информация и чувствителни данни, които могат да струват пари на хората или дори в някои региони живота им. Това изисква по-сигурен подход.

Отговорът беше криптиране.

Проблем с размяната на ключове

Един проблем, който исторически измъчва дори най-добрите криптосистеми, продължава да съществува и до днес.

Това, което обсъждахме по-рано, и това, което традиционно е стандарт за криптиране, е криптирането с частен ключ. Това се нарича също симетрично криптиране, или двупосочно криптиране – с частни ключове, обработващи както функциите за криптиране, така и декриптиране, необходими за комуникация.

За да работи криптирането на частния ключ, частният ключ трябва да бъде прехвърлен между страните или и двете страни трябва да притежават свое копие. Така или иначе сигурността на частния ключ беше от решаващо значение за целостта на криптосистемата и, както можете без съмнение да предполагате, обменът на ключове е проблем, толкова стар, колкото и самото криптиране.

Тогава, през 70-те години на миналия век – технически два различни времена, цял океан разделен – беше създадена нова форма на криптиране и оживена: криптиране с публичен ключ.

Докато криптирането на частния ключ е двупосочна функция, симетрична, с частния ключ, който може да криптира и декриптира данни, криптирането на публичния ключ е асиметрично; еднопосочен. Вместо единичен частен ключ има двойка публично-частни ключове. Публичният ключ се справя с криптирането и, както подсказва името, е публично достъпен, докато частният ключ, който обработва декриптирането, се пази в тайна от неговия собственик. Използвайки публичния ключ, човек може да кодира част от данните и да го изпрати до собственика на ключа, където само те ще могат да го декриптират.

Страхотно, но как е полезно?

Е, еднопосочното криптиране не е идеално за криптиране на интернет връзки, е трудно да се комуникира, когато едната страна може само да шифрова, а другата може само да дешифрира. Не, за да шифровате интернет връзка, ще трябва да използвате симетрично криптиране с частен ключ.

Но как да разменяте ключове? Особено онлайн?

Криптиране на публичния ключ.

И това, дестилирано до самата му същност, е това, което SSL / TLS представлява: сигурна размяна на ключове.

Тук ще свържем всички тези понятия заедно. Ако искате комуникацията ви с уебсайт да е частна, тогава трябва да се свържете с нея сигурно. Ако искате да се свържете сигурно с този уебсайт, тогава трябва да обмените симетрични частни ключове, за да можете да ги използвате за комуникация. SSL / TLS (и PKI като цяло) е просто фантастичен механизъм за създаване и обмен на този сесиен ключ.

Използвайки SSL / TLS, можете да удостоверите сървъра или организацията, с която ще се свържете, и да гарантирате, че сигурно обменяте личните ключове, които ще използвате, за да шифровате комуникацията си с желаната страна.

За съжаление, SSL / TLS и PKI имат много терминология и движещи се части, които лесно могат да объркат хората, но тези вярват, че когато премахнете цялата математика и технически жаргон, това е просто елегантно модерно технологично решение за една епоха -остарен проблем: размяна на ключове.

Сега да преминем към няколко ключови думи

Преди да продължим по-нататък, нека разгледаме няколко други ключови думи. Вече въведохме HTTP, протокол за прехвърляне на хипертекст, който е основата на интернет от десетилетия. Но както обсъждахме, интернетът се превърна в нещо много по-различно, отколкото беше, когато HTTP беше публикуван за първи път през 1991 г..

Необходим беше по-сигурен протокол. По този начин HTTPS.

HTTPS, който понякога се нарича HTTP през TLS, използва криптиране, за да направи данните, които се обменят по време на връзка, да не могат да бъдат четими на никого, освен на предвидената страна. Това е особено важно, когато вземете предвид естеството на модерна интернет връзка.

Докато в първите дни на интернет връзката беше разумно директна, сега връзките се пренасочват през десетки устройства на път към крайното им местоназначение. Ако някога сте искали практическа демонстрация на това, отворете командния ред на вашата ОС и въведете командата „tracert geekflare.com“.

Това, което ще видите, е пътят, по който връзката ви е пропътувала по пътя си до местоназначението. До 30 скока. Това означава, че вашите данни преминават през всяко едно от тези устройства, преди да достигнат до уебсайта или приложението, с което се свързвате. И ако някой има пакетиращ пакет или слушател, инсталиран на което и да е от тези устройства, той може да открадне всички предадени данни и дори да манипулира връзката в някои случаи.

Това се нарича атака “човек в средата” (MITM).

Ако искате да научите за атаката на MITM, тогава вижте този онлайн курс.

Има много повече повърхностна площ, която се покрива с модерни интернет връзки, отколкото осъзнава по-голямата част от хората, поради което криптирането на данните по време на предаването е от решаващо значение. Нямате представа кой би могъл да слуша или колко тривиално лесно е да се направи.

HTTP връзка се осъществява през порт 80. За нашите цели можете да мислите за портове като конструкции, които показват мрежова услуга или протокол. Стандартният уебсайт, който се обслужва чрез HTTP, използва порт 80. HTTPS обикновено използва порт 443. Когато уебсайт инсталира сертификат, той може да пренасочи своите HTTP страници към HTTPS и браузърите на потребителите ще се опитат да се свържат сигурно чрез порт 443, в очакване на удостоверяване.

За съжаление, термините SSL / TLS, HTTPS, PKI и криптиране всички се хвърлят много, понякога дори се използват взаимозаменяемо, така че за да изчистите всяко трайно объркване, ето едно бързо ръководство:

  • SSL – Secure Sockets Layer – оригиналният протокол за криптиране, използван с HTTPS
  • TLS – Transport Layer Security – по-новият протокол за криптиране, който замени SSL
  • HTTPS – Защитената версия на HTTP, използвана за създаване на връзки с уебсайтове
  • PKI – Инфраструктура на публичните ключове, се отнася до целия модел на доверие, който улеснява криптирането на публичния ключ

SSL / TLS работи съвместно, за да позволи HTTPS връзки. И PKI се отнася до цялото нещо, когато намалявате.

Схванах го? Не се тревожете, ще го направите.

Изграждане на инфраструктура с публичен ключ

Сега, когато поставихме основата, нека да намалим мащаба и да разгледаме архитектурата, използвана от доверителния модел в сърцето на SSL / TLS.

Когато стигнете до уебсайт, първото нещо, което браузърът ви прави, е да провери истинността на SSL / TLS сертификата, с който сайтът го представя. Ще стигнем до това, което се случва след като това удостоверяване се проведе в няколко раздела, но ще започнем с обсъждането на модела на доверие, който прави всичко това възможно.

Така че ще започнем с въпроса: как компютърът ми знае дали да се доверя на даден SSL / TLS сертификат?

За да отговорим на това, ще трябва да обсъдим PKI и различните елементи, които го правят. Ще започнем със сертификатите и Root програми.

Органи за сертифициране

Сертифициращият орган е организация, която отговаря на набор от предварително определени стандарти в замяна на възможността за издаване на надеждни цифрови сертификати.

Има десетки CA, безплатни и търговски, които могат да издават надеждни сертификати.

Всички те трябва да спазват набор от стандарти, които са обсъдени и узаконени чрез форума на CA / Browser, който действа като регулаторен орган за TLS индустрията. Тези стандарти очертават неща като:

  • Технически предпазни мерки, които трябва да са налице
  • Най-добри практики за извършване на валидиране
  • Най-добри практики за издаване
  • Процедури и срокове за отмяна
  • Изисквания за регистрация на сертификати

Тези указания са формулирани от браузърите, съвместно с CA. Браузърите играят уникална роля в TSS екосистемата.

Никой не може да стигне до интернет навсякъде без своя уеб браузър. Като такъв, браузърът ще приема и валидира цифровия TLS сертификат и след това ще разменя ключовете със сървъра. Така че, предвид своята първостепенна роля, те оказват значително влияние.

И е важно да се има предвид, че браузърите са проектирани да бъдат възможно най-скептични. Да не се доверяваш на нищо. Това е най-добрият начин да запазят потребителите си. Така че, ако браузърът ще се довери на цифров сертификат – който потенциално може да се злоупотреби в ущърб на потребителя – той се нуждае от определени уверения, че който е издал този сертификат, е направил дължимата си проверка.

Това е ролята и отговорността на сертифициращите органи. И браузърите също не спазват грешки. Има буквално гробище на бивши СА, които са се натъкнали на браузърите и са били пуснати на пасище.

Когато сертифициращият орган е доказал съответствието си с основните изисквания на форума на CAB и е преминал всички необходими одити и прегледи, той може да подаде петиция към различните коренни програми, за да бъдат добавени своите Root сертификати.

Root програми

Коренна програма – основните от тях се управляват от Apple, Microsoft, Google и Mozilla – е устройството, което наблюдава и улеснява кореновите хранилища (понякога наричани доверителни магазини), които са колекции от сертификати Root CA, които се намират в системата на потребителя. За пореден път тези корени са невероятно ценни и невероятно опасни – в крайна сметка могат да издават надеждни цифрови сертификати – така че сигурността е от най-голямо значение.

Ето защо СА почти никога не издават директно от самите сертификати Root CA. Вместо това те въртят междинни коренни сертификати и ги използват за издаване на сертификати за крайни потребители или листове. Те могат също да предадат тези корени на Sub-CA, които са сертифициращи органи, които нямат своите специални корени, но все още могат да издават кръстосано подписани сертификати от своите междинни продукти.

Така че, нека да сложим всичко това заедно. Когато уебсайт иска да има издаден TLS сертификат, той генерира нещо наречено заявка за подписване на сертификат (CSR) на сървъра, на който е хостван. В тази заявка се съдържат всички подробности, които уебсайтът иска да бъде включен в сертификата. Както ще видите малко, количеството информация може да варира от пълни детайли за бизнеса до обикновена идентификация на сървъра, но след като CSR е завършена, тя се изпраща заедно със сертифициращия орган за издаване.

Преди да издаде сертификата, CA ще трябва да извърши надлежна проверка на CA / Browser Forum и да провери дали информацията, съдържаща се в CSR, е точна. След като това е потвърдено, той подписва сертификата със своя частен ключ и го изпраща обратно на собственика на уебсайта за инсталиране.

Верига за сертификати

След инсталирането на сертификата за TLS всеки път, когато някой посети сайта, на който е домакин сървърът, ще представи браузъра на потребителя със сертификата. Браузърът ще разгледа цифровия подпис на сертификата, този, който е направен от доверения сертификатен орган, който потвърждава факта, че цялата информация, съдържаща се в сертификата, е точна.

Това е мястото, където терминът верига на сертификати влиза в игра.

Браузърът ще прочете цифровия подпис и ще премести връзката по веригата – след това ще провери цифровия подпис на междинния сертификат, чийто частен ключ е използван за подписване на сертификата на листото. Той ще продължи следването на подписите, докато веригата на сертификатите завърши в един от надеждните корени в кореновия си магазин или докато веригата се прекрати без да достигне корен, в този случай ще се появи грешка в браузъра и връзката няма да се провали.

Ето защо не можете да издавате и самоподписвате сертификатите си.

Браузърите ще се доверят само на SSL / TLS сертификати, които могат да върнат обратно към своя root магазин (което означава, че са били издадени от доверено образувание). Органите за сертифициране са длъжни да спазват конкретни стандарти, за да запазят своята надеждност и дори тогава браузърите не са склонни да им се доверяват..

Браузърите нямат такива уверения за самоподписани сертификати, поради което те трябва да се разполагат само във вътрешни мрежи, зад защитни стени и в тестова среда.

Видове SSL / TLS сертификати и функционалност

Преди да разгледаме SSL / TLS в движение, нека поговорим за сертификатите и различните итерации, които са на разположение. TLS сертификатите са това, което улеснява TLS протокола и помагат да се диктуват условията на шифрованите HTTPS връзки, които уебсайтът прави.

По-рано споменахме, че инсталирането на TLS сертификат ви позволява да конфигурирате уебсайта си да осъществява HTTPS връзки през порт 443. Той също така действа като вид значка за името на сайта или сървъра, с който взаимодействате. Връщайки се на идеята, че в основата му SSL / TLS и PKI са всички изящни форми на сигурна размяна на ключове, SSL / TLS сертификатът помага да се уведоми браузъра на кого изпраща ключа на сесията – на коя страна в другия край на връзката е.

И когато разбиете различните итерации на SSL / TLS сертификати, това е уместно нещо, което трябва да имате предвид. Сертификатите варират в зависимост от функционалността и нивото на валидиране. Или казано по друг начин, те варират в зависимост от:

  • Колко самоличности да отстояват
  • Какви крайни точки за отстояване на идентичността

Отговорът на тези два въпроса ще ви даде доста ясно указание от какъв тип сертификат се нуждаете.

Колко самоличности да Assert

Съществуват три различни нива на валидиране със SSL / TLS сертификати и те варират в зависимост от това колко информация за самоличност вашият уебсайт иска да утвърди.

  • SSL сертификати за валидиране на домейн – идентификация на сървъра за сертифициране
  • SSL сертификати за валидиране на организация – Удостоверяване на частична идентичност на организацията
  • Удължени валидиращи SSL сертификати – Потвърдете пълната идентичност на организацията

SSL сертификатите за валидиране на домейни са най-популярните поради цената и скоростта, с която могат да бъдат издадени. DV SSL / TLS сертификатите изискват проста проверка на контрола на домейна, която може да се извърши по няколко различни начина, но веднага след като сертификатът може да бъде издаден. Можете също така да получите безплатно 30-дневни и 90-дневни версии на тях безплатно, което несъмнено е добавило към техния пазарен дял.

Недостатъкът е, че DV SSL сертификатите отстояват минимална идентичност. И като се има предвид, че почти половината от всички фишинг сайтове имат инсталиран DV SSL сертификат върху тях, не е задължително да ви купуват много по пътя на доверие.

SSL / TLS сертификат е оригиналният тип сертификати за валидиране на организация. Те са и единственият вид SSL сертификат, който може да защити IP адрес след решение на форума на CAB от 2016 г. за невалидни всички интранетни SSL сертификати. Валидирането на организацията изисква лека проверка на бизнеса и обикновено може да бъде издадена в рамките на ден или два – понякога и по-бързо. OV SSL сертификатите изискват някаква организационна информация, но интернет потребител трябва да щракне върху иконата на катинара и да я потърси. Днес виждате много OV SSL сертификати, разположени в големи корпоративни и корпоративни мрежи, например за връзки, направени зад защитни стени..

Тъй като нито DV, нито OV SSL сертификатите не предоставят достатъчна идентичност, за да задоволят повечето браузъри, те получават неутрално третиране.

SSL сертификатите с разширено валидиране са най-спорните, тъй като някои от технологичната общност смятат, че трябва да се направи повече, за да се засили валидирането, от което зависят. Но EV SSL утвърждава максимална идентичност. За да завърши разширеното валидиране, сертифициращият орган поставя организацията чрез строг процес на проверка, който може да отнеме повече от седмица в някои случаи.

Но ползата е неоспорима: тъй като тя предоставя достатъчна идентичност уебсайт с EV SSL сертификат получава уникално третиране на браузъра, включително това, че името му е показано в адресната лента на браузъра.

Няма друг начин за постигане на това и не можете да го фалшифицирате – адресната лента на EV е един от най-мощните визуални индикатори, с които разполагаме днес.

Какви крайни точки за отстояване на идентичността

Другият начин, по който SSL / TLS сертификатите варират, е свързан с функционалността. Уебсайтовете се развиха доста от първите дни на интернет с различни компании, разположили сайтове по различни начини. Някои имат множество домейни за различни вертикали на компанията; други използват поддомейни за множество функции и уеб приложения. Някои използват и двете.

Без значение какъв е контекста, има SSL / TLS сертификат, който може да ви помогне да го защитите.

Единичен домейн

Основният уебсайт и стандартният SSL сертификат са само един домейн. Повечето съвременни SSL / TLS сертификати ще осигуряват както WWW, така и не-WWW версии на този домейн, но той е ограничен до един домейн. Можеш Сравнете SSL сертификатите тук.

Multi-Domain

Сертификати за много домейни или Унифицирани сертификати за комуникация (в случай на Microsoft Exchange и Office Communications сървъри) също съществуват, за да дадат на организациите възможност да криптират множество домейни с един сертификат. Това може да бъде атрактивна опция, тъй като спестява пари и прави управлението на сертификатите (изтичане / подновяване) много по-просто.

Сертификатите за много домейни и UCC използват SAN, полето за алтернативно име на предмета в CSR, за да добавят допълнителни домейни към сертификата. Повечето CA позволяват до 250 различни SAN на един сертификат. И повечето сертификати за много домейни се предлагат с 2-4 безплатни SAN, като останалите се предлагат за закупуване според нуждите.

Wildcard SSL сертификати

Уайлдскард SSL сертификати са изключително полезен тип сертификат, тъй като те могат да шифроват неограничен брой поддомейни на същото ниво на URL адреса. Например, ако имате уебсайт, който използва поддомейни като:

  • app.website.com
  • portal.website.com
  • user.website.com

Можете да ги шифровате всички със същия сертификат за Wildcard, като използвате звездичка в полето FQDN на вашата КСО: * .website.com

Сега всеки поддомен, дори и този, който все още не сте добавили, може да бъде защитен с този сертификат.

Въпреки това има два недостатъка на Wildcard сертификатите. Първият е, че използвайки един и същ публичен ключ в някои крайни точки, вие сте по-уязвими към определени подвизи като атаки на Bleichenbacher.

Другото е, че няма опция EV Wildcard. Благодарение на отворения характер на Wildcard функционалността, браузърите не са наред с делегирането им на това ниво на доверие. Ако искате EV адресната лента във вашите поддомейни, ще трябва да ги шифровате поотделно или да използвате EV Multi-домейн сертификат.

Уайлдкард с много домейни

Сравнително ново допълнение към SSL / TLS екосистемата, Multi-Domain Wildcard може да кодира до 250 различни домейна, но може да използва и звездичка в полетата на SAN, което също ви позволява да криптирате 250 различни домейна И всичките им съпътстващи първо -нивни поддомейни.

Друг случай за използване на мулти-домейн Wildcard е като многостепенна Wildcard, където тя може да криптира поддомейни на множество нива на URL адреса (стандартният Wildcard може да ги шифрова само на едно ниво).

Поради функционалността на Wildcard, мулти-домейн Wildcards също не са налични в EV.

SSL / TLS в движение

Сега, когато покрихме всички важни понятия, които съставляват SSL / TLS и PKI, нека го съберем и да го видим в движение.

Валидиране и издаване

Нека започнем отначало с уебсайт, който купува SSL / TLS сертификат от CA или дистрибутор. След покупката организационният контакт, който обработва придобиването на сертификат, създава заявка за подписване на сертификат на сървъра, където ще бъде инсталиран сертификатът (сървърът, който хоства уебсайта).

Заедно с CSR сървърът ще генерира също двойка публичен / частен ключ и ще запише локалния частен ключ. Когато CA получи CSR и публичния ключ, той изпълнява необходимите стъпки за валидиране, за да гарантира, че всяка информация, съдържаща се в сертификата, е точна. По принцип за сертификатите за удостоверяване на бизнес (не DV) това включва търсене на информация за регистрация на организацията и публични записи в правителствени бази данни.

След като валидирането приключи, CA използва един от частните ключове от един от своите сертификати за издаване, обикновено междинен корен, и подписва сертификата, преди да го върне на собственика на сайта.

Сега собственикът на уебсайта може да вземе току-що издадения SSL / TLS сертификат, да го инсталира на сървъра си и да конфигурира уебсайта да прави HTTPS връзки на порт 443 (използвайки 301 пренасочвания за изпращане на трафик от вече съществуващите HTTP страници към новите им HTTPS колеги).

Удостоверяване и SSL ръкостискане

След като SSL / TLS сертификатът е инсталиран и уебсайтът е конфигуриран за HTTPS, нека разгледаме как ще улесни шифрованите връзки с посетителите на сайта..

След като пристигне на уебсайта, сървърът ще представи SSL / TLS сертификат на браузъра на потребителя. След това браузърът на потребителя извършва серия от проверки.

Първо, ще удостоверите сертификата, като видите неговия цифров подпис и следвате веригата на сертификатите. Той също така ще се увери, че сертификатът не е изтекъл и ще провери дневниците за прозрачност на сертификата (CT) и списъците за отмяна на сертификати (CRL). При условие, че веригата води обратно към един от корените в магазина за доверие на системата и че е валиден, браузърът ще се довери на сертификата.

Сега е време за ръкостискане.

SSL / TLS ръкостискане е серията от стъпки, в които клиентът (потребителят) и сървърът (уебсайтът) договарят параметрите на своята сигурна връзка, генерират и след това обменят симетрични ключове за сесия.

Първо, те ще решат за шифров пакет. Шифров пакет е групата от алгоритми и шифри, които ще бъдат използвани за връзката. SSL / TLS сертификатът предоставя списък на пакети от шифри, които сървърът поддържа. Обикновено шифровият пакет включва алгоритъм за криптиране на публичен ключ, алгоритъм за генериране на ключове, алгоритъм за удостоверяване на съобщения и симетричен или групов алгоритъм за криптиране – въпреки че това е прецизирано в TLS 1.3.

След като бъде представен със списъка на поддържаните шифри, клиентът ще избере подходящ и ще го съобщи на сървъра. Оттам клиентът ще генерира симетричен ключ на сесията, ще го шифрира с публичния ключ и след това ще го изпрати до сървъра, който притежава частния ключ, необходим за дешифриране на сесионния ключ.

След като и двете страни имат копие на ключа на сесията, комуникацията може да започне.

И това е SSL / TLS.

Можете да видите как всички концепции, които преживяхме по-рано, си взаимодействат помежду си, за да създадат сложна, но елегантна система за осигуряване на интернет връзки. Използваме криптографията с публичен ключ, за да обменяме ключовете на сесията сигурно, с които ще общуваме. Сертификатите, които отстояват сървърната или организационната идентичност, могат да се доверят на инфраструктурата, която имаме между различните CA, браузъри и root програми.

И комуникацията се получава в резултат на симетрично, криптиране на частен ключ, което е низходящо от класическите криптосистеми от древността.

Има много движещи се части, но когато ги забавите и разберете всички поотделно, е много по-лесно да видите как всичко работи заедно.

Преди да продължите, нека завършим с няколко хода, свързани с SSL / TLS, които можете да направите след инсталиране / конфигурация, за да извлечете максимума от вашата инвестиция.

След SSL / TLS – Извличане на максимума от вашата реализация

Просто инсталирането на сертификат и правилното конфигуриране на уебсайта ви не означава, че уебсайтът ви е в безопасност. TLS е само един компонент от по-широка, цялостна стратегия за киберзащита. Но все пак важен компонент. Нека да разгледаме няколко неща, които можете да направите, за да гарантирате, че ще извлечете максимума от внедряването.

Деактивирайте поддръжката на сървър за стари протоколи

Като се удвоим към разговора, който имахме по-рано за Cipher Suites, част от конфигурирането на вашия сървър решава какви шифрови пакети и SSL / TLS версии да се поддържат. Задължително е да деактивирате поддръжката за по-стари SSL / TLS версии, както и специфични алгоритми, за да предотвратите уязвимост към няколко известни експлоатации.

И SSL 2.0 и SSL 3.0 са на възраст над 20 години. Най-добрата практика беше да се отнема подкрепата за тях преди години, но и до днес около 7% от топ 100 000 Alexa все още им позволяват. Това е опасно, защото ви излага на SSL събличане и понижаване атаки като POODLE.

TLS 1.0 и TLS 1.1 също са в заемно време.

Най-големите технологични компании, Apple, Microsoft, Google и Mozilla, направиха съвместно съобщение тази есен, че в началото на 2020 г. те ще оттеглят поддръжката за TLS 1.0 и 1.1..

Версиите на протокола са податливи на уязвимости като POODLE, FREAK, BEAST и CRIME (това са съкращения). TLS 1.2 съществува от десет години и трябва да бъде стандартът. TLS 1.3 беше финализиран миналото лято и оттогава приемането се движи с постоянен темп.

Освен това има специфични алгоритми, които също не трябва да се използват. DES, например, може да се счупи за няколко часа. RC4 е по-уязвим, отколкото се смяташе досега, и вече е извън закона от стандартите за сигурност на данните на индустрията за разплащателни карти. И накрая, като се имат предвид новини за последните експлоатации, не е препоръчително да се използва RSA за обмен на ключове.

Предложени алгоритми / шифри:

  • Размяна на ключове: Елиптична крива Diffie-Helman (ECDH)
  • Удостоверяване: Алгоритъм за цифров подпис на елиптична крива (ECDSA)
  • Симетрично / насипно криптиране: AES 256 в режим на Galois Counter (AES256-GCM)
  • MAC алгоритъм: SHA-2 (SHA384)

Винаги включен SSL

В миналото уебсайтовете понякога са мигрирали само уеб страниците, които събират информация към HTTPS, докато обслужват останалата част от сайта чрез HTTP. Това е лоша практика.

В допълнение към факта, че Google ще маркира тези страници „Не е сигурно“, вие също потенциално излагате посетителите на вашия сайт на риск, като браузърите им прескачат напред и назад между криптирани страници и HTTP.

Трябва да конфигурирате целия си уебсайт за HTTPS. Това се нарича Винаги включен SSL. В крайна сметка, не е като да плащате от страницата, вашият SSL / TLS сертификат може да шифрова целия ви сайт. Затова го направете така.

Създайте запис на разрешение за сертифициране (CAA)

Един от най-съществените рискове, които крият цифровите сертификати, е погрешното издаване. Ако страна, различна от вас, е издала SSL / TLS сертификат за ВАШИЯ уебсайт, те могат ефективно да ви представят и да причинят всякакви проблеми.

Записите на CAA помагат за намаляване на този риск, като ограничават това, което сертифициращите органи могат да издават цифрови сертификати за вашия уебсайт. Органите за сертифициране са длъжни от форума на CA / Browser да проверят записи на CAA, преди да издадат сертификат. Ако CA няма разрешение за издаване на този сайт, той не може. Това ще се счита за пропускане и ще събуди гнева на общността на браузърите.

Добавянето на CAA запис е сравнително лесно, това е прост DNS запис, който може да бъде добавен чрез интерфейса на повечето хостинг платформи. Можете да ограничите CA, които могат да издават за вашия домейн, както и дали могат да се издават и сертификати Wildcard за него.

Добавете уебсайта си към списъка за предварително зареждане на HSTS

HTTP Strict Transport Security или HSTS е HTTP заглавие, което принуждава браузърите да осъществяват HTTPS връзки с даден сайт. По този начин, дори ако уеб потребителят се опита да премине към HTTP версията на страницата, те ще посетят само HTTPS версията. Това е важно, тъй като той затваря прозореца на няколко известни подвига, като пристъп на понижаване и отвличане на бисквитки.

За съжаление, миниатюрен вектор за атака остава с HSTS, поради което трябва да добавите уебсайта си към списъка с предварително зареждане. Обикновено, когато посетител пристигне на вашия уебсайт, техният браузър ще изтегли HTTP заглавката и след това ще го спазва, колкото и дълго да е била зададена политиката. Но при това първо посещение, преди да бъде получено заглавката, все още има малък отвор за нападател.

Списъкът с HSTS предварително зареждане на записа се управлява от Google и някои негови варианти, използвани от всички основни браузъри. Тези браузъри знаят само да се свързват чрез HTTPS към всеки уебсайт, който е в списъка, дори ако той никога не е посещаван там преди. Може да отнеме седмица или две, за да се покаже сайтът ви в списъка поради факта, че актуализациите на списъка се изтласкват заедно с графиците за пускане на браузърите.

SSL / TLS FAQ

Какво е X.509 сертификат?

X.509 се отнася до вида на цифровия сертификат, който се използва с SSL / TLS и други видове PKI. X.509 е стандарт за криптиране с публичен ключ. Понякога ще видите, че компаниите използват X.509 сертификат вместо „цифров сертификат“ или „PKI сертификат.“

Защо изтичат SSL / TLS сертификатите?

Има две причини за това.

Първият е, че интернет непрекъснато се променя, идват уебсайтове и уебсайтове. И като се има предвид колко чувствителни са браузърите да се доверят на тези сертификати, на първо място искат да знаят, че уебсайтовете, представящи сертификатите, преминават редовно валидиране. Това не е толкова различно от това как понякога се налага да се регистрирате, за да актуализирате информацията в шофьорската си книжка.

Другата причина е по-техническа. По-трудно е да разпространявате актуализации и технически промени, когато сертификатите не изтичат за 3-5 години. Като има предвид, че ако сертификатите изтичат на всеки 24 месеца, най-дълго всеки сертификат може да бъде остарял е две години. През 2017 г. максималната валидност беше намалена от три години на две. Вероятно скоро ще бъде съкратен до 12 месеца.

Как да подновите SSL / TLS сертификат?

Подновяването може да е малко погрешно, защото заменяте стария сертификат с новоиздаден. Правенето на това редовно ви позволява да бъдете в крак с новите подобрения с технологията за криптиране и гарантира, че информацията за валидирането ви остава актуална. СА могат да използват повторно информацията за валидиране, която първоначално е била предоставена толкова дълго, преди основните изисквания да ги принудят да я валидират отново.

Когато обновявате, можете или да запазите същия тип сертификат, който сте имали преди, или можете да отидете с нещо ново, дори можете да промените CA. Голямото е колко време оставаш на изтичащия сертификат – можеш да преносиш до три месеца. Докато подновите, преди да изтече срокът на сертификата, можете да пренасяте останалото време и да използвате повторно всяка информация за валидиране, която не е изтекла след последното ви потвърждение. Ако оставите да изтече, започвате от нулата.

Какво е HTTPS инспекция?

Много по-големи компании с по-големи мрежи обичат да имат видимост над трафика си. В това отношение HTTPS е меч с две остриета. Той защитава личния живот на хората, но също така може да помогне на киберпрестъпниците да се скрият. Много организации ще дешифрират HTTPS трафика си на крайно устройство или средна кутия и след това или ще го изпратят в открит текст зад защитната си стена, или ще го шифроват отново и ще го изпратят по пътя си. Когато не шифровате отново трафика, това се нарича SSL прекратяване. Когато повторно шифровате, това се нарича SSL мост.

Какво е SSL разтоварване?

Разтоварването на SSL е друга корпоративна практика. В мащаб, извършването на хиляди ръкостискания и след това криптиране и дешифриране на всички тези данни може да обложи данъците на мрежата. Така че много по-големи мрежи ще разтоварят SSL функциите на друго устройство, така че сървърът на приложения да може да се съсредоточи върху основните си задачи. Това понякога се нарича балансиране на натоварването.

Защо ми CA изпрати междинен сертификат?

Помнете по-рано, когато обсъждахме root програми?

Very OS има root магазин, който използва за вземане на PKI преценки за доверие. Но CA не издават сертификати за крайни потребители от тези корени от страх какво ще се случи, ако някой някога трябва да бъде отменен. Вместо това те въртят междинни корени и ги издават. Проблемът е, че междинните корени не се намират в доверие на системата.

Така че, ако уебсайтът не представя междинния сертификат заедно с листовия SSL / TLS сертификат, много браузъри няма да могат да завършат веригата на сертификати и ще отправят предупреждение. Някои браузъри правят кеш междинни сертификати, но все още се счита за най-добра практика да инсталирате междинни продукти заедно с вашия сертификат за листове.

Каква документация ми трябва за SSL сертификат за разширено валидиране?

В повечето случаи Сертифициращият орган, извършващ разширеното валидиране, първо ще се опита да получи достъп до информацията чрез публично достъпни ресурси на „държавния орган“.

На някои места обаче това може да не е възможно. Има няколко неща, които могат да помогнат за ускоряване на валидирането. Въпреки че наскоро е намален броят на проверките за валидиране, които може да удовлетвори писмото за професионално мнение, но притежаването на адвокат или счетоводител с добър репутационен знак все още може да помогне значително.

Освен това можете да предоставите издаден от правителството бизнес идентификационен документ или документ „Доказателство за право“, който дава на вашата организация правото да прави бизнес под изброеното име. Някои примери за тези документи са:

  • Учредителен акт
  • Удостоверения за формиране
  • Лицензи за бизнес / продавач / търговци
  • Харта документи
  • Споразумения за партньорство
  • Регистрация на търговско или предполагаемо име
  • Регистратор Меркантил

В заключителната

Надявам се това ви дава представа за SSL / TLS. Ако се интересувате да научите повече, тогава бих препоръчал като вземете този онлайн курс.

Тази публикация бе допринесена от Патрик Ное, редактор на Отнесени от SSL Store, блог, който обхваща новини и тенденции в киберсигурността.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map