ССЛ / ТЛС 101 за почетнике

Детаљни поглед на шифрирање које обезбеђује наше интернетске везе


Док је Нетсцапе оригинално изумио ССЛ средином 90-их, није било обавезно свако веб место да инсталира ССЛ / ТЛС сертификат до лета 2018. када је Гоогле почео да обележава нешифроване веб локације “Нот Сецуре.“

Иако Гоогле – са својим претраживачем, прегледачем Цхроме и ОС-ом Андроид – може једнострано редефинисати Интернет, то мандат није био сам. Аппле, Мицрософт, Мозилла и други велики актери у технолошкој индустрији донијели су заједничку одлуку за додјелу ССЛ / ТЛС сертификата и ХТТПС.

Разлог је једноставан: без ССЛ / ТЛС и могућности сигурног повезивања путем ХТТПС-а, сва комуникација између веб локација и њихових посетилаца размењивала би се у отвореном тексту и лако би их могла прочитати трећа страна.

Једина мана овог недавног напора за универзалну енкрипцију јесте да је приморан прилив нових купаца на непознато тржиште, оно које чини врло мало да би се учинило мање збуњујућим за просечног власника веб локација или предузећа.

Овај чланак послужиће као свеобухватан водич за све ствари ССЛ / ТЛС, поставићемо темељ тако што ћемо прећи основне концепте попут шифрирања, ХТТПС и природе интернет веза.

Надамо се да ћете до краја бити сигурни у избор, куповину и имплементацију ТЛС сертификата и сетите се ако имате било каквих питања која ћете их моћи оставити у коментарима испод.

Темељни елементи

Започнимо расправом о концепту који лежи у средишту свега овога: шифровању.

Шифровање, у својој најравнијој итерацији, је нешто више од кодирања података – коришћењем унапред одређеног шифре или кључа – тако да га чини нечитљивим било ко осим неке друге стране са истим приватним кључем.

Кроз историју шифрирање приватних кључева био је најчешћи модел који се користио. У шифрирању приватног кључа обе стране морају имати или барем разменити приватни кључ који се може користити и за шифровање и за дешифровање информација.

Већ на почетку већина шифри подупирући ове криптосистеме били су примитивни, ослањајући се на једноставне замјене или замјену уобичајених ријечи словима. Али с временом су шифре постале све више под утицајем математике и постале све сложеније.

На пример, средином 1600-их у Француској, криптограф краља Луја КСИВ створио је шифер који је био тако добро осмишљен да није разбијен до 250 година касније и тек тада делимично. До данас у француским архивима постоје записи вредни стотине година које можда никада неће бити дешифровани.

Али док је историјско шифрирање представљало средство за прикривено или прикривено, појава интернета поимање је преузела концепт више. Интернет је свеприсутан и обрађује низ критичних функција. Сваког дана милијарде људи га користе за приступ и слање осетљивих информација, управљање финансијама, посао са предузећима – назовите га.

Проблем је што Интернет није био у потпуности дизајниран да би се прилагодио ономе што је постао. У рано доба, у време када су академије и влада САД-а први пут развијали мрежне протоколе, Интернет се доживљавао само као механизам за слободну размену информација између владе и академских институција. У том тренутку, комерцијална активност је била незаконита на мрежи. е-трговина није била реч која је још измишљена. А веб локација је била више географски појам.

Дакле, када је ХТТП или протокол преноса хипертекста први пут представљен 1991. године, чињеница да су везе које је он формирао размењивао податке у отвореном тексту није представљао дисквалификујући проблем.

Данас су ствари много другачије. Информације које се размењују на мрежи нису академска истраживања или информације које су слободно доступне, то су лично препознатљиви подаци и осетљиви подаци који могу коштати људе или чак, у неким регионима, живота. Ово је захтевало сигурнији приступ.

Одговор је био шифровање.

Проблем са разменом кључева

Један проблем који је историјски мучио чак и најбоље криптосистеме и даље постоји до дан данас.

Оно о чему смо разговарали раније и оно што је традиционално стандард за шифровање је шифрирање приватним кључевима. То се такође назива симетрична енкрипција или двосмерна енкрипција – са приватним кључевима који управљају и функцијама шифрирања и дешифровања потребним за комуникацију.

Да би шифровање приватног кључа деловало, приватни кључ мора да се пребаци између страна или обе стране морају да поседују сопствену копију. Било како било, сигурност приватних кључева била је критична за интегритет криптосистема и, као што можете сумњати претпоставити, размјена кључева је проблем стар колико и сама енкрипција..

Тада је 1970-их – технички два различита времена, читав океан, одвојено – конципиран и оживљен нови облик шифрирања: шифрирање јавним кључем.

Док је шифрирање приватног кључа двосмерна функција, симетрична, с приватним кључем који може и шифрирати и дешифрирати податке, шифрирање јавног кључа је асиметрично; једносмерно. Уместо једног приватног кључа, постоји пар јавно-приватних кључева. Јавни кључ управља шифровањем и, као што му име каже, јавно је доступан, док приватни кључ, који обрађује дешифрирање, власник тајне. Помоћу јавног кључа човек може да шифрира део података и пошаље га власнику кључа, само тако ће га моћи дешифровати.

Одлично, али како је то корисно?

Па, једносмерна енкрипција није идеална за шифрирање интернетских веза, некако је тешко комуницирати када једна страна може само шифрирати, а друга само дешифрирати. Не, за шифрирање интернетске везе морали бисте користити симетрично шифрирање приватним кључем.

Али како разменити кључеве? Нарочито на мрежи?

Шифрирање јавног кључа.

А то је, дестилирано до саме суштине, оно што ССЛ / ТЛС ради: сигурна размена кључева.

Овде ћемо повезати све те концепте заједно. Ако желите да ваша комуникација са веб локацијама буде приватна, тада је потребно да се на њу сигурно повежете. Ако се желите сигурно повезати с том веб страницом, тада требате размијенити симетричне приватне кључеве како бисте их могли користити за комуникацију. ССЛ / ТЛС (и ПКИ уопште) је само фантастични механизам за креирање и размену тог сесијског кључа.

Кориштењем ССЛ / ТЛС-а можете овјерити сервер или организацију с којом ћете се повезати и осигурати да сигурно размјењујете приватне кључеве које ћете користити за шифрирање комуникације с намјераваном страном.

Нажалост, ССЛ / ТЛС и ПКИ имају пуно терминологије и покретних делова који лако могу збунити људе, али они верују у чињеницу да када скинете сву математику и технички жаргон, ово је само елегантно модерно технолошко решење за старост -олд проблем: размјена кључева.

Сада прелазимо на неколико кључних термина

Пре него што наставимо даље, пређимо на неколико других кључних услова. Већ смо увели ХТТП, протокол преноса хипертекста, који је деценијама био окосница интернета. Али док смо разговарали, Интернет се развио у нешто много другачије него што је био случај када је ХТТП први пут објављен 1991. године.

Био је потребан сигурнији протокол. Дакле, ХТТПС.

ХТТПС, који се понекад назива и ХТТП преко ТЛС-а, користи шифровање како би подаци који се размењују током везе учинили нечитљивима било коме осим одреденој страни. Ово је посебно важно када се узме у обзир природа модерне интернетске везе.

Док је у првим данима интернета веза била прилично директна, сада су везе проведене кроз десетине уређаја на путу до њиховог крајњег одредишта. Ако сте икада желели практичну демонстрацију овога, отворите командни редак на вашем ОС-у и унесите наредбу „трацерт геекфларе.цом“.

Оно што ћете видети је пут којим је ваша веза путовала до њеног одредишта. До 30 скокова. То значи да ваши подаци пролазе кроз сваки од тих уређаја пре него што дођу до било које веб локације или апликације са којом се повезујете. А ако неко има снајпер за пакете или неки слушалац инсталиран на било ком од тих уређаја, може украсти било који пренети податак, па чак и манипулирати везом у неким случајевима.

То се назива нападом човека у средини (МИТМ).

Ако желите да сазнате о МИТМ нападу, онда погледајте овај курс на мрежи.

Има много више површине која се прекрива модерним интернетским везама него што их велика већина људи схвата, због чега је пресудно шифрирање података током преноса. Немате појма ко би могао слушати или колико је то тривијално лако.

ХТТП веза врши се преко порта 80. За наше потребе портове можете замислити као конструкције које означавају мрежни сервис или протокол. Стандардна веб локација која се користи преко ХТТП-а користи порт 80. ХТТПС обично користи порт 443. Када веб локација инсталира сертификат, може да преусмери своје ХТТП странице на ХТТПС и корисници ће прегледачи покушати да се повежу преко порта 443, у ишчекивању аутентификације.

Нажалост, појмови ССЛ / ТЛС, ХТТПС, ПКИ и енкрипција се много губе, понекад се чак и наизменично користе, тако да уклоните све трајне забуне, ево кратког водича:

  • ССЛ – Сецуре Соцкетс Лаиер, оригинални протокол шифрирања који се користи са ХТТПС
  • ТЛС – Транспорт Лаиер Сецурити, новији протокол шифровања који је заменио ССЛ
  • ХТТПС – Сигурна верзија ХТТП-а, која се користи за успостављање веза са веб локацијама
  • ПКИ – Инфраструктура јавних кључева односи се на целокупни модел поверења који омогућава шифрирање јавних кључева

ССЛ / ТЛС ради заједно да би омогућио ХТТПС везе. А ПКИ се односи на целу ствар када је умањујете.

Разумем? Не брини, хоцес.

Изградња инфраструктуре јавног кључа

Сада када смо поставили темељ, смањимо и погледамо архитектуру кориштену трустовим моделом у срцу ССЛ / ТЛС-а.

Када дођете на веб локацију, прво што прегледач уради јесте да потврди аутентичност ССЛ / ТЛС сертификата који сајт представља. Доћи ћемо до онога што се дешава након што се аутентификација изведе у неколико одељка, али почет ћемо расправом о моделу поверења који све ово омогућава.

Дакле, почет ћемо постављањем питања: како мој рачунар зна да ли да верује датом ССЛ / ТЛС сертификату?

Да бисмо одговорили на то, мораћемо да разговарамо о ПКИ-у и разним елементима који то чине. Почећемо са ауторитетима за сертификате и Роот програмима.

Ауторитети за сертификате

Ауторитет за сертификате је организација која удовољава скупу унапред одређених стандарда у замену за могућност издавања поузданих дигиталних сертификата.

Постоје десетине ЦА-ова, бесплатних и комерцијалних, које могу издати поуздане сертификате.

Сви они морају да се придржавају низа стандарда о којима се расправља и законодавствује преко форума ЦА / Бровсер, који делује као регулаторно тело за ТЛС индустрију. Ови стандарди описују следеће ствари:

  • Техничке мере заштите које морају бити на снази
  • Најбоље праксе за вршење валидације
  • Најбоље праксе издавања
  • Поступци и рокови опозива
  • Захтеви за евидентирање сертификата

Ове смернице су постављене од стране прегледача, у сарадњи са ЦА. Прегледници играју јединствену улогу у ТЛС екосистему.

Нико не може стићи било где на Интернету без свог веб прегледача. Као такав, прегледач ће примати и потврђивати дигитални ТЛС сертификат, а затим размењивати кључеве са сервером. Дакле, с обзиром на њихову најважнију улогу, они имају значајан утицај.

И важно је имати на уму да су прегледачи дизајнирани да буду што скептичнији. Не верујем ни у шта. То је најбољи начин да заштите своје кориснике. Дакле, ако прегледач жели да верује дигиталном сертификату – који се потенцијално може злоупотребити на штету корисника – потребна су одређена уверења да је онај ко је издао овај сертификат обавио своју дужну ревност..

То је улога и одговорност ауторитета за добијање сертификата. А ни претраживачи не поштују грешке. Постоји дословно гробље бивших службеника ЦА који су налетели на претраживаче и ставили на пашу.

Када Ауторитет за сертификате покаже да испуњава основне захтеве ЦАБ Форума и прође све потребне ревизије и прегледе, може поднети захтев за различите роот програме како би им се додали Роот сертификати.

Роот програми

Коренски програм – главни програм покрећу Аппле, Мицрософт, Гоогле и Мозилла – је апарат који надгледа и олакшава коријенске продавнице (који се понекад називају и продавнице поверења), а то су колекције Роот ЦА сертификата који се налазе на систему корисника. Још једном, ови корени су невероватно вредни и невероватно опасни – могу да издају поуздане дигиталне сертификате, на крају крајева – тако да сигурност представља највећу бригу..

То је разлог зашто ЦА готово никада не издају директно из самих Роот ЦА сертификата. Уместо тога, они спинују посредне роот-сертификате и користе их за издавање крајњих корисника или потврда о листи. Они такође могу да предају те корене Суб-ЦА-има, који су сертификовани органи који немају своје наменске корене, али могу и даље да издају укрштане сертификате изван својих посредника.

Дакле, хајде да ово све саставимо. Када веб локација жели да изда ТЛС сертификат, генерише нешто што се зове Захтев за потписивање сертификата (ЦСР) на серверу на коме је домаћин. У овом захтеву су сви детаљи које веб локација жели да буде укључена у сертификат. Као што ћете видети мало, количина информација може варирати од комплетних детаља о пословању до једноставног идентитета сервера, али када се испуни ЦСР, шаље се заједно са сертификационим лицем на издавање.

Пре издавања сертификата, ГА ће морати да обави свој дужни преглед и да потврди да су информације садржане у ЦСР тачне. Након што је верификовано, потписује сертификат својим приватним кључем и враћа га власнику веб локације на инсталацију.

Ланац сертификата

Након инсталирања ТЛС сертификата, сваки пут када неко посети веб локацију на којој је домаћин сервер ће представити прегледач корисника са сертификатом. Прегледач ће прегледати дигитални потпис на сертификату, онај који је направио поуздан ауторитет за сертификат, који потврђује да су све информације садржане у сертификату тачне.

Овде долази у употребу појам ланаца сертификата.

Прегледач ће прочитати дигитални потпис и преместити везу на ланцу – следеће ће проверити дигитални потпис на пролазном сертификату чији је приватни кључ коришћен за потписивање потврде о листи. Настављаће са следећим потписима све док се ни ланчић сертификата не заврши на једном од поузданих коренова у његовој роот складишту или док се ланац не прекине без постизања роот-а, у том случају ће се појавити грешка у прегледачу и веза неће успети.

Због тога не можете да издајете и самопотписујете своје сертификате.

Прегледници ће веровати само ССЛ / ТЛС сертификате које могу да повежу у своје матичне продавнице (што значи да их је издао поверени ентитет). Власти за сертификате морају се придржавати специфичних стандарда да би одржале своју поузданост, па чак и тада их прегледачи не воле да им верују..

Прегледачи немају таква уверења о самопотписаним потврдама, због чега их треба распоређивати само у унутрашњим мрежама, иза фиревалл-а и у тестним окружењима.

Врсте и функционалност ССЛ / ТЛС цертификата

Пре него што погледамо ССЛ / ТЛС у покрету, разговарајмо о сертификатима и различитим понављањима која су доступна. ТЛС сертификати су оно што олакшава ТЛС протокол и помажу у диктирању услова шифрованих ХТТПС веза које веб локација прави.

Раније смо споменули да инсталирање ТЛС сертификата омогућава конфигурисање веб локације за успостављање ХТТПС веза путем порта 443. Такође делује као врста значке за веб локацију или сервер са којим комуницирате. Враћајући се идеји да су ССЛ / ТЛС и ПКИ у свом срцу изврсни облици сигурне размене кључева, ССЛ / ТЛС сертификат помаже у обавештавању прегледача коме шаље кључ сесије – коме странка на другом крају веза је.

А када разбијете различите итерације ССЛ / ТЛС сертификата, то је важно имати на уму. Сертификати се разликују у зависности од функционалности и нивоа валидације. Или другачије речено, разликују се овисно о:

  • Колико идентитета треба тврдити
  • Које су крајње тачке за потврђивање идентитета

Ако одговорите на ова два питања, дат ћете прилично јасан показатељ која врста сертификата вам је потребна.

Колико идентитета да се утврди

Постоје три различита нивоа валидације са ССЛ / ТЛС сертификатима, а они се разликују у зависности од података о идентитету које ваша веб локација жели да потврди..

  • ССЛ сертификати за проверу домена – Провери идентитет сервера
  • ССЛ сертификати о валидацији организације – Потврдите делимични идентитет организације
  • ССЛ сертификати са проширеном валидацијом – Увери цео идентитет организације

Валидација домена ССЛ сертификати далеко су најпопуларнији због цене и брзине којом се могу издати. ДВ ССЛ / ТЛС сертификати захтевају једноставну контролу домене, што се може постићи на више различитих начина, али чим се сертификат може издати. Такође можете добити неке верзије ових 30 и 90 дана, што је несумњиво додало њихов удио на тржишту.

Лоша страна је да ДВ ССЛ сертификати потврђују минималан идентитет. А с обзиром на то да готово половина свих пхисхинг веб локација има на себи инсталиран ДВ ССЛ сертификат, не морају вам купити много на начин поверења..

ССС / ТЛС сертификат је оригинална врста ССЛ сертификата. Они су такође једина врста ССЛ сертификата који може да осигура ИП адресу након одлуке ЦАБ форума о 2016. да поништи све интранет ССЛ сертификате. Провјера организације захтијева лагано провјеравање пословања и обично се може издати у року од дан или два – понекад и брже. ОВ ССЛ сертификати садрже неке организационе информације, али корисник интернета би морао да кликне икону катанца и тражи их. Данас видите пуно ОВ ССЛ сертификата распоређених на великим пословним и корпоративним мрежама, на пример за везе направљене иза фиревалл-а..

Како ни ДВ ни ОВ ССЛ сертификати не дају довољан идентитет да би задовољили већину прегледача, они добијају неутралан третман.

Проширена валидација ССЛ сертификата далеко је најспорнија, јер неки у технолошкој заједници сматрају да треба учинити више како би се ојачала валидација од које зависе. Али, ЕВ ССЛ потврђује максимални идентитет. Да би завршио продужену валидацију, Ауторитет за сертификат проводи организацију кроз ригорозни поступак провјере који у неким случајевима може трајати и више од једне седмице..

Али корист је неспорна: јер потврђује довољан идентитет веб локација са ЕВ ССЛ сертификатом добија јединствен третман прегледача, укључујући и његово име приказано у адресној траци прегледача..

Нема другог начина да се то постигне, а не можете је лажирати – ЕВ адреса је једна од најснажнијих визуелних индикатора коју данас имамо.

Које су крајње тачке за потврђивање идентитета

Други начин на који се ССЛ / ТЛС сертификати разликују је у погледу функционалности. Веб странице су прилично еволуирале од раних дана на Интернету, а различите компаније су на различите начине поставиле сајтове. Неки имају више домена за различите компаније; други користе поддомене за више функција и веб апликација. Неки користе и једно и друго.

Без обзира на контекст, постоји ССЛ / ТЛС сертификат који вам може помоћи да га осигурате.

Сингле Домаин

Примарна веб локација и стандардни ССЛ сертификат су само једна домена. Већина модерних ССЛ / ТЛС сертификата осигурава и ВВВ и не-ВВВ верзије тог домена, али је ограничена на један домен. Можете упоредите ССЛ сертификате овде.

Вишедомена

Сертификати са више домена или Обједињени сертификати за комуникацију (у случају сервера Мицрософт Екцханге и Оффице Цоммуницатионс) такође пружају организацијама могућност шифрирања више домена једним цертификатом. Ово може бити атрактивна опција јер штеди новац, а управљање сертификатима (истеци / обнављања) чини много једноставнијим.

За више домена и УЦЦ сертификате користи се САН, поље Субјецт Алтернативе Наме у ЦСР-у за додавање додатних домена у сертификат. Већина ЦА дозвољава до 250 различитих САН на једном сертификату. И већина Мулти-Домаин сертификата поседује 2-4 бесплатне САН-ове, а остатак је доступан за куповину по потреби.

Вилдцард ССЛ сертификати

Вилдцард ССЛ сертификати су изузетно корисна врста сертификата јер могу да шифрирају неограничен број поддомена на истој разини УРЛ-а. На пример, ако имате веб локацију која користи поддомене као што су:

  • апп.вебсите.цом
  • портал.вебсите.цом
  • усер.вебсите.цом

Можете их шифрирати истим Вилдцард цертификатом користећи звездицу у ФКДН пољу вашег ЦСР-а: * .вебсите.цом

Сада било који поддомен, чак и онај који још нисте додали, може бити обезбеђен тим цертификатом.

Постоје двије недостатке Вилдцард сертификата. Први је да користите исти јавни кључ у неким крајњим тачкама, ви сте рањивији на одређене подвиге попут напада Блеицхенбацхер-а.

Други је да не постоји ЕВ Вилдцард опција. Због отворене природе Вилдцард функционалности, претраживачи нису у реду, делегирајући им тај ниво поверења. Ако желите да се ЕВ адреса налази на вашим поддоменама, мораћете да их шифрирате појединачно или користите ЕВ Мулти-Домаин сертификат.

Вилдцард с више домена

Релативно нов додатак ССЛ / ТЛС екосистему, Мулти-Домаин Вилдцард може шифровати до 250 различитих домена, али може користити и звездицу у САНс пољима, која вам такође омогућава да шифрирате 250 различитих домена и све пратеће прве -диве поддомене.

Још један случај употребе за Мулти-Домаин Вилдцард је као Вилд-ниво на више нивоа, где може да шифрира поддомене на више нивоа УРЛ-а (стандардни Вилдцард их може шифровати само на једном нивоу).

Због функције Вилдцард, Мулти-Домаин Вилдцардс нису доступне ни у ЕВ-у.

ССЛ / ТЛС у покрету

Сада када смо обухватили све значајне концепте који чине ССЛ / ТЛС и ПКИ, ставимо то све заједно и видимо га у покрету.

Валидација и издавање

Кренимо од почетка у потпуности са веб локације која купује ССЛ / ТЛС сертификат од ЦА или продавца. Након куповине, организациони контакт који руководи набавком сертификата креира Захтев за потписивање сертификата на серверу на коме ће се сертификат инсталирати (сервер који домаћин је веб локација).

Уз ЦСР, сервер ће такође генерисати пар јавних / приватних кључева и локално сачувати приватни кључ. Кад ЦА прими ЦСР и јавни кључ, извршава потребне кораке за валидацију како би осигурао да су све информације садржане у сертификату тачне. Генерално, за потврде о аутентификацији пословања (не ДВ) то укључује тражење информација о регистрацији организације и јавних записа у државним базама података.

Након завршетка провере, ЦА користи један од приватних кључева из једног од својих сертификата за издавање, обично средњи корен и потписује сертификат пре него што га врати власнику веб локације..

Сада власник веб локације може преузети ново издат ССЛ / ТЛС сертификат, инсталирати га на њихов сервер и конфигурирати веб локацију за успостављање ХТТПС веза на луци 443 (помоћу 301 преусмеравања за слање промета са постојећих ХТТП страница на њихове нове ХТТПС колеге).

Аутентификација и ССЛ руковање

Сада када је инсталиран ССЛ / ТЛС сертификат и веб локација је конфигурисана за ХТТПС, погледајмо како ће олакшати шифроване везе са посетиоцима сајта.

Након доласка на веб локацију, сервер ће приказати ССЛ / ТЛС сертификат прегледачу корисника. Корисников прегледач тада извршава низ провера.

Прво ће потврдити идентитет сертификата тако што ће прегледати његов дигитални потпис и пратити ланац сертификата. Такође ће се увјерити да цертификат није истекао и провјерити записнике о транспарентности цертификата (ЦТ) и листе опозива цертификата (ЦРЛ). Под условом да ланац доведе до једног од корена у мрежи поверења система и да је валидан, прегледач ће веровати сертификату.

Сада је време за руковање.

ССЛ / ТЛС стисак руке је низ корака у којима клијент (корисник) и сервер (веб локација) договарају параметре своје сигурне везе, генеришу и затим размењују симетричне сесијске кључеве.

Прво ће одлучити о шифарском пакету. Пакет шифри је група алгоритама и шифри које ће се користити за везу. ССЛ / ТЛС сертификат пружа листу шифарних пакета које сервер подржава. Опћенито, шифровани пакет укључује алгоритам шифрирања јавног кључа, алгоритам генерисања кључева, алгоритам провјере идентитета поруке и алгоритам симетричног или скупно шифрирања – иако је то прецизирано у ТЛС 1.3.

Након што му се представи листа подржаних шифри, клијент ће одабрати погодну и пренети је серверу. Одатле ће клијент генерисати симетрични сесијски кључ, шифрирати га јавним кључем, а затим га послати на сервер који поседује приватни кључ потребан за дешифровање сесијског кључа.

Једном када обе стране примере кључ сесије, комуникација може започети.

А то је ССЛ / ТЛС.

Можете видети како сви концепти које смо прошли раније међусобно делују како би створили софистициран, али елегантан систем за обезбеђивање интернетских веза. Криптографију јавног кључа користимо за размјену кључева сесије са којима ћемо сигурно комуницирати. Сертификатима који потврђују идентитет сервера и организације може се веровати због инфраструктуре коју имамо између различитих ЦА, прегледача и роот програма.

А комуникација настаје као резултат симетричне енкрипције приватних кључева која потиче од класичних криптосистемских система антике.

Постоји пуно покретних делова, али када успорите и разумете их све појединачно, много је лакше видети како то све заједно функционише.

Пре него што кренете, завршимо са неколико потеза повезаних са ССЛ / ТЛС-ом које можете извршити након инсталације / конфигурације да бисте максимално искористили улагања.

Након ССЛ / ТЛС – Извући максимум из своје имплементације

Једноставно постављање сертификата и правилно конфигурисање веб локације не значи да је ваша веб локација безбедна. ТЛС је само једна компонента шире, холистичке стратегије за сајбер одбрану. Али ипак важна компонента. Покријмо неколико ствари које можете учинити да бисте искористили максимум у имплементацији.

Онемогућите подршку сервера за старе протоколе

Повраћајући разговору о Ципхер Суитес-у који смо имали раније, део конфигурисања вашег сервера одлучује које шифарске пакете и ССЛ / ТЛС верзије треба да подржавају. Неопходно је да онемогућите подршку старијим верзијама ССЛ / ТЛС-а, као и посебне алгоритме како бисте спречили рањивост на неколико познатих подвига.

ССЛ 2.0 и ССЛ 3.0 обоје су старији од 20 година. Најбоља пракса је била да се њихова подршка одузме пре много година, али до данас их око 7% од најбољих 100.000 Алека још увек дозвољава. Ово је опасно јер вас излаже ССЛ скидању и паду напада попут ПООДЛЕ.

ТЛС 1.0 и ТЛС 1.1 такође су посуђени.

Највеће технолошке компаније, Аппле, Мицрософт, Гоогле и Мозилла, заједнички су најавили ову јесен да ће почетком 2020. године обуставити подршку за ТЛС 1.0 и 1.1..

Верзије протокола су осјетљиве на рањивости попут ПООДЛЕ, ФРЕАК, БЕАСТ и ЦРИМЕ (све су то акроними). ТЛС 1.2 постоји већ десет година и требао би бити стандард. ТЛС 1.3 је финализиран прошлог љета и од тада се усвајање креће сталним темпом.

Поред тога, постоје и специфични алгоритми који се не би требали користити. ДЕС се, на пример, може сломити за неколико сати. РЦ4 је рањивији него што се некада веровало и већ су га забранили Стандарди безбедности података платних картица. И на крају, с обзиром на недавне подвиге, није препоручљиво више користити РСА за размену кључева.

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

  • Размена кључева: Елиптичка крива Диффие-Хелман (ЕЦДХ)
  • Аутентификација: Алгоритам дигиталног потписа елиптичне криве (ЕЦДСА)
  • Симетрично / скупно шифрирање: АЕС 256 у режиму Галоис Цоунтер-а (АЕС256-ГЦМ)
  • МАЦ алгоритам: СХА-2 (СХА384)

Увек укључен ССЛ

У прошлости су веб локације понекад мигрирале само веб странице које прикупљају информације на ХТТПС, док остатак сајта послужују путем ХТТП-а. То је лоша пракса.

Поред чињенице да ће Гоогле те странице означити „Није безбедно“, потенцијално излажете и посетиоцима своје веб локације ризику тако што ће њихови прегледачи прескочити напред и назад између шифрованих страница и ХТТП страница.

Требали бисте конфигурисати целокупну веб локацију за ХТТПС. Ово се зове увек укључени ССЛ. На крају, није да плаћате по страници, ваш ССЛ / ТЛС сертификат може да шифрује целокупну веб локацију. Па нека буде тако.

Поставите запис о ауторизацији ауторитета за сертификате (ЦАА)

Један од најзначајнијих ризика који представљају дигитални сертификати уопште је погрешно издавање. Ако нека друга страна осим вас изда ССЛ / ТЛС сертификат за ВЕЛИКУ веб локацију, може вас ефективно лажно представљати и узроковати све врсте проблема.

ЦАА записи помажу у смањењу овог ризика ограничавањем онога што ауторитети за цертифицирање могу издати дигиталне цертификате за вашу веб локацију. Органи власти морају да провере ЦАА записе пре издавања било ког сертификата. Ако ЦА нема овлашћење за издавање за ту веб локацију, не може. То би се сматрало погрешним издавањем и прикупљало гнев заједнице прегледача.

Додавање ЦАА записа релативно је једноставно, то је једноставан ДНС запис који се може додати преко интерфејса већине хостинг платформи. Можете да ограничите ЦА који могу да издају за ваш домен, као и да ли се такође могу издати Вилдцард сертификати за то.

Додајте своју веб страницу на ХСТС листу за учитавање

ХТТП строга транспортна безбедност или ХСТС је ХТТП заглавље које присиљава прегледаче само да успоставе ХТТПС везе са одређеном веб локацију. На овај начин, чак и ако веб корисник покуша да пређе на ХТТП верзију странице, само ће посјетити ХТТПС верзију. То је важно јер затвара прозор на неколико познатих подвига, попут напада слабијег напада и отмице колачића.

Нажалост, малени вектор напада остаје са ХСТС-ом, због чега би требало да додате своју веб локацију на листу за претходно учитавање. Када посетилац стигне на вашу веб локацију, њихов прегледач ће преузети ХТТП заглавље и потом га поштовати колико год трајала политика. Али у тој првој посети, пре него што је заглавље примљено, још увек постоји мали отвор за нападача.

Листу записа ХСТС претходно учитавање води Гоогле, а неке њене варијације користе све главне прегледаче. Ти прегледачи знају да се повезују само путем ХТТПС-а на било коју веб локацију која је на листи – чак и ако је тамо никада раније није посећивала. Може проћи недељу или две да се ваша веб локација појави на листи због чињенице да се ажурирања листе избацују заједно са плановима пуштања прегледача..

ССЛ / ТЛС ФАК

Шта је Кс.509 сертификат?

Кс.509 се односи на врсту дигиталног сертификата који се користи са ССЛ / ТЛС и другим врстама ПКИ. Кс.509 је стандард шифрирања јавног кључа. Повремено ћете видети да компанија користи Кс.509 сертификат уместо „дигиталног сертификата“ или „ПКИ сертификата“.

Зашто ССЛ / ТЛС цертификати истичу?

Постоје два разлога за то.

Прво је да се Интернет непрестано мења, да долазе веб странице и да раде веб локације. А с обзиром на то колико су претраживачи осетљиви на поверење у ове сертификате, пре свега желе да знају да веб локације које представљају ове цертификате редовно проверавају. То се не разликује од повременог пријављивања да бисте ажурирали информације о возачкој дозволи.

Други разлог је више технички. Теже је проширити ажурирања и техничке промене када сертификати не истекну 3-5 година. Док, уколико цертификати истекну свака 24 месеца, најдуже било које време може да застаре је две године. У 2017. години максимална важност је смањена са три године на две. Вероватно ће ускоро бити скраћено на 12 месеци.

Како обнављате ССЛ / ТЛС сертификат?

Обнављање може бити мало погрешно, јер стари сертификат замењујете новоиздатим. Редовно ово омогућава вам да будете у току са новим напретком технологије шифрирања и омогућава да ваши подаци о валидацији буду ажурирани. Надзорни органи могу поново користити само информације о валидацији које су првобитно биле испоручене толико дуго пре него што их основни захтеви натерају да их поново провере..

Када обнављате, можете да задржите исти тип сертификата који сте имали раније, или можете да кренете са нечим новим, чак можете да промените и ЦА. Велика је ствар колико вам времена остаје на сертификату који истиче: можете да га пребаците до три месеца. Све док обнављате пре истека сертификата, можете пренијети преостало време и поново употријебити све податке о валидацији који нису истекли од ваше задње потврде. Ако пустите да ми истекне, крећете од нуле.

Шта је ХТТПС инспекција?

Много веће компаније са већим мрежама воле да имају видљивост над својим прометом. У том погледу, ХТТПС је мач са две оштрице. Штити приватност људи, али такође може помоћи и сајбер-криминалцима да се сакрију. Многе организације ће дешифровати свој ХТТПС саобраћај на рубном уређају или у средњем сандучићу, а затим ће га послати у отвореном тексту иза заштитног зида или га поново шифрирати и послати на пут. Када не шифрирате саобраћај, то се зове ССЛ раскид. Када поново шифрирате, то се зове ССЛ премошћивање.

Шта је ССЛ учитавање?

Пребацивање ССЛ-а је још једна пракса предузећа. У опсегу, вршење хиљада руковања рукама, затим шифровање и дешифровање свих тих података могу опорезовати ресурсе мреже. Дакле, пуно већих мрежа ће преточити ССЛ функције на други уређај тако да се сервер апликација може фокусирати на своје основне задатке. То се понекад назива и балансирање оптерећења.

Зашто ми је ЦА послао посредничку потврду?

Сетите се раније када смо разговарали о роот програмима?

Врло ОС поседује роот складиште које користи за доношење ПКИ веровања. Али ЦА не издају сертификате крајњим корисницима из тих корена из страха од тога шта би се догодило ако би неко икада морао бити опозван. Уместо тога, они спинују посредне корене и издају их. Проблем је у томе што они посредни корени не живе у систему поверења у систем.

Дакле, ако веб локација не представља посредни сертификат заједно са ССЛ / ТЛС цертификатом с листом, многи прегледачи неће моћи да доврше ланац сертификата и издаће упозорење. Неки прегледачи спремају привремене сертификате у кеширање, али још увек се сматра најбољом праксом да инсталирате било који интермедијар заједно са вашим лист сертификатом..

Која ми је документација потребна за ССЛ цертификат за продужену валидацију?

У већини случајева, сертификациони орган који врши продужену валидацију прво ће покушати да приступи информацијама путем јавно доступних извора „државних органа“.

Међутим, на неким локацијама то можда није могуће. Неколико ствари могу вам помоћи у убрзавању валидације. Иако је у последње време смањен број провере ваљаности које Писмо професионалног мишљења може да има, адвокат или рачуновођа у добром знаку још увек може значајно да помогне.

Поред тога, можете приложити пословни документ који је издала влада или документ „Доказ о праву“ који вашој организацији даје право да послује под наведеним називом. Неки примери ових докумената су:

  • Статутом
  • Потврде о формирању
  • Лиценце за пословање / продавце / трговце
  • Повеља докумената
  • Споразуми о партнерству
  • Регистрација трговачког или претпостављеног имена
  • Регистратор Мерцантил

На крају

Надам се да вам ово даје представу о ССЛ / ТЛС-у. Ако сте заинтересовани да сазнате више, онда бих препоручио похађање овог курса на мрежи.

Ову поруку је допринео Патрицк Нохе, уредник Избрисао ССЛ Сторе, блог који покрива вести и трендове кибернетичке сигурности.

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