Шта је ТЛС и како функционише?

Шта је ТЛС енкрипција и како функционише

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

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

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

Шта ТЛС ради?

При слању информација путем Интернета наилазимо на три главна сигурносна проблема:

  • Како можемо знати да ли је особа с којом комуницирамо заиста онаква за коју кажу да јесте?
  • Како можемо знати да подаци нису спрећени од тренутка када су их послали?
  • Како можемо спречити друге људе да виде и приступе подацима?

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

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

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

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

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

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

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

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

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

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

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

ТЛС вс. ССЛ

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

Историја ТЛС-а

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

ССЛ 1.0 никада није пуштен јер је садржавао озбиљне рањивости. Верзија 2.0 је изашла са Нетсцапе Навигатор 1.1 1995. године, међутим, она је још увек имала низ озбиљних недостатака. ССЛ 3.0 је био јако редизајнирана верзија и изашао је 1996. године, са многим безбедносним проблемима је решен.

1996, ИЕТФ је објавио нацрт ССЛ 3.0 у РФЦ 6101. ИЕТФ је формирао радну групу за стандардизацију ССЛ-а, објавивши резултате 1999. године као ТЛС 1.0. То је документовано у РФЦ 2246, а стандардизација је подразумевала неке промене оригиналног протокола, као и промену имена. Ове модификације су настале као резултат преговора између Нетсцапе-а, Мицрософта и ИЕТФ радне групе.

ИЕТФ је 2006. године објавио РФЦ 4346, који документује ТЛС 1.1. Ова верзија садржи нове безбедносне одредбе и низ других ажурирања. Верзија 1.2 објављена је само две године касније у 2008. Укључила је подршку за оверене шифриране шифре, низ промена у начину на који се користе хасх функције и многа друга побољшања.

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

ТЛС 1.0 и 1.1 сада су застарели да буду 2020., али верзија 1.2 је у широкој употреби. Верзија 1.3 почиње са повећаним усвајањем.

ТЛС: Технички детаљи

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

тлс-3

Дијаграм који приказује ТЛС стацк. ТЛС стог протокола од Јеффреитедјосукмоно. Лиценцирано под ЦЦ0.

Протокол за снимање садржи пет засебних подпротокола, од којих је сваки обликован као записи:

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

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

ТЛС протокол руковања

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

Постоје три основне врсте руковања ТЛС-ом: тхе основно руковање ТЛС-ом, тхе тхе клијентски овјеровљени ТЛС стисак руке и тхе скраћено руковање.

Основни ТЛС стисак руке

тлс-2

Дијаграм који приказује ТЛС процес руковања. Потпуно руковање ТЛС 1.2 компаније ФлесхГриндер. Лиценцирано под ЦЦ0.

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

Порука Поздрав клијента је примљена са Поздрав сервера порука. Овај одговор садржи ИД сесије, верзију протокола, шифрирани пакет и компресију (ако се користи) који је сервер изабрао са листе клијента. Такође укључује различит случајни број.

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

Ако се користе ефемерне Диффие-Хеллман или анонимне Диффие-Хеллман-ове размене кључева, онда следи Размена тастера сервера порука. Остале методе размене кључева прескачу овај део. Када сервер заврши са својом страном преговора, он шаље а Поздрав сервера сервера порука.

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

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

Клијент тада шаље Промените Ципхер Спец порука. Ово говори серверу да ће следеће поруке сада бити оверене и шифроване (мада се понекад шифровање можда неће користити).

Клијент затим следи ово са Готов порука, која је шифрована и садржи код за потврду идентитета поруке (МАЦ) за аутентификацију. Сервер дешифрује ову поруку и верификује МАЦ. Ако било који од ових процеса не успе, везу треба одбити.

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

Клијент ТЛС овјерен од стране клијента

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

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

Скраћени ТЛС стисак руке

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

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

Процес започиње с Здраво клијента порука. Много је слична ранијој апликацији Цлиент Хелло, али садржи и ид сесије од раније везе. Ако сервер зна ИД сесије, укључује га у свој Поздрав сервера порука. Ако не препозна ИД сесије, вратиће другачији број, а уместо њега мораће да се изврши потпуно ТЛС руковање.

Ако сервер препозна ИД сесије, тада ће Потврда и Размена кључева кораци се могу прескочити. Тхе Промените Ципхер Спец и Готов поруке се шаљу на исти начин као и основни ТЛС рукопис приказан горе. Након што је клијент дешифровао поруку и верификовао МАЦ, подаци се могу послати преко сигурне ТЛС везе.

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

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

Распакирање ТЛС стискања

Три најважнија корака руковања укључују:

  • параметри су одабрани,
  • проводи аутентификацију и
  • кључеви су успостављени.

Покријмо их мало детаљније да бисте могли разумети шта се заправо догађа.

Параметри

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

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

Аутентификација: Дигитални сертификати

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

Дигитални цертификати су електронски документи који показују везу између појединца или субјекта и његовог јавног кључа. Ову везу потврђује ауторитет за сертификацију (ЦА), која је поуздана организација која проверава да ли су та лица заиста повезана, а затим користи сопствену репутацију да додели поверење сертификату.   

Различити нивои сертификата представљају различите нивое поверења. Важно је знати да ако клијент или сервер имају поуздан и валидан сертификат, онда је разумно претпоставити да је јавни кључ легитиман и да не тргујете са нападачем.

Напомена о јавним кључевима

Енкрипција јавним кључем (позната и као асиметрична енкрипција) важан је део криптографије и она се увелико користи у различитим аспектима ТЛС-а. Ево кратког примера за оне који нису упознати са начином рада.

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

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

Успостављање главне тајне

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

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

Тачан поступак зависи од тога који је метод размене кључа изабран, али он следи грубих корака поменутих у Основни ТЛС стисак руке одељак.

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

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

  • Клијент напише МАЦ кључ - Овај кључ користи сервер за провјеру интегритета података које је послао клијент.
  • МАЦ тастер за писање сервера - МАЦ кључ за писање на послужитељу клијент користи за провјеру интегритета података које је послао сервер.
  • Клијент за шифрирање писања - Сервер користи овај кључ за шифрирање података које је послао клијент.
  • Кључ за шифровање писања сервера - Клијент користи овај кључ за шифровање података које је послао сервер.
  • Клијент напише ИВ кључ - кључ за писање клијента ИВ користи сервер у АЕАД шифрима, али не и када се користе други алгоритми за размену кључева.
  • ИВ тастер за писање сервера - Слично томе, овај кључ користи клијент у АЕАД шифрама, али не и када се користе други алгоритми за размену кључева.

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

Једном када су добијени кључеви за аутентификацију и енкрипцију, они се користе за заштиту оба Готов поруке, као и записе послате путем протокола апликације.

Протокол апликације

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

Алгоритми за потврду идентитета

Интегритет порука може се проверити са много различитих алгоритама. Ови укључују:

  • ХМАЦ-МД5
  • ХМАЦ-СХА1
  • ХМАЦ-СХА2
  • АЕАД

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

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

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

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

Алгоритми за шифровање

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

ТЛС може користити много различитих алгоритама, као што су Цамеллиа или АРИА, иако је најпопуларнији АЕС.

Компресија

Компресија је процес кодирања података како би заузео мање простора. ТЛС подржава компресију ако обе стране везе одлуче да га користе. Упркос овој способности, генерално се препоручује избегавање употребе ТЛС-а за компримовање података, посебно од тренутка напада ЦРИМЕ (види Питања сигурности ТЛС-а одељак испод) откривено је да може искористити компримоване податке за отмицу сесије.

Паддинг

Паддинг додаје додатне податке у поруку пре него што је шифрована. То је уобичајени криптографски процес који се користи да помогне у спречавању наговештаја у структури шифрованих података да одају своје право значење. ТЛС углавном примењује ПКЦС # 7 паддинг за записе пре него што су шифровани.

Протокол упозорења

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

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

ТЛС & ОСИ модел

ОСИ модел је начин да се концептуалише и стандардизује начин на који посматрамо наше различите комуникационе системе и протоколе. Важно је напоменути да је то само модел, а неки од наших протокола се не уклапају у њега.

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

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

Употреба ТЛС-а

ТЛС се користи да осигура значајан део наше мрежне комуникације. Обично се имплементира преко протокола попут Протокол контроле преноса (ТЦП), али се такође може користити у протоколу за контролу загушења Датаграма (ДЦЦП) и протоколу корисничког датаграма (УДП).

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

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

Друга његова употреба је да сигурну пошту путем СТАРТТЛС-а. Када се ТЛС имплементира, спречава нападаче да могу приступити порукама док путују између послужитеља поште.

Питања сигурности ТЛС-а

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

Прошле верзије, као што су ССЛ 2.0 и 3.0 (и ТЛС 1.0, који је у основи исти као ССЛ 3.0), имају бројне недостатке у сигурности, али пошто су стари и застарјели протоколи, нећемо улазити у детаље. Уместо тога, требало би да користите ТЛС 1.2 и 1.3 да бисте осигурали своје везе.

Новије верзије ТЛС-а имају бројне надоградње које га чине мање рањивим од ССЛ-а. Упркос томе, протокол је и даље имао следећа питања безбедности:

Напади за поновно преговарање

Једна од карактеристика ТЛС-а је што омогућава паровима клијента и сервера да преговарају о параметрима своје постојеће везе. У 2009. години откривено је да то нападачи могу искористити како би убацили саобраћај како би изгледали као да долази од клијента. Сервери ће прихватити захтев као легитиман, што значи да нападачи потенцијално могу да манипулишу одлазним порукама.

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

ЗВЕР

Бровсер Екплоит Агаинст ССЛ / ТЛС (БЕАСТ) напад први су открили истраживачи у 2011. години. Користи предност шифреног блока који улаже рањивост у ТЛС-у, а који се може користити за дешифровање порука. Овај напад погађа само ТЛС 1.0, што је стара и слабија верзија протокола. Иако се неће обуставити до 2020. године, корисници би уместо њега требало да користе верзије 1.2 и 1.3.

Временски напади

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

ЗЛОЧИН & ПОВРАТАК

КРИМЕ напад делује против низа протокола. Када се подаци компресују, они могу да извуку садржај из колачића за аутентификацију. Ове информације се могу користити за отмицу сесија. Иако утиче на бројне протоколе, напад је посебно забрињавајући када се користи ХТТП компресија јер не постоје ефикасне стратегије ублажавања.

У 2013. години пронађено је да претраживач Рецоннаиссанце анд Екфилтратион помоћу адаптивног компресије хипертекста (БРЕАЦХ) утиче на ХТТП компресију на сличан начин. Овом верзијом напада могу се опоравити адресе е-поште и други вредни подаци који су шифровани помоћу ТЛС-а. Напад БРЕАЦХ може се ублажити онемогућавањем ХТТП компресије или употребом техника попут заштите од фалсификовања захтева на више локација (ЦСРФ).

Пад напада

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

Хеартблеед

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

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

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

УТОПИТИ

Дешифровање РСА напада са застарелом и ослабљеном еНкрипцијом (ДРОВН) најављено је 2016. године и користи предност подршке сервера за ССЛ 2.0. Користи одабрани шифрирани текст против сервера који и даље подржавају ССЛ 2.0, као и оне који деле исти сертификат јавног кључа са другим сервером који подржава ССЛ 2.0.

Када је напад најављен, могао би се покренути са почетним трошковима подешавања од око 18 000 УСД и око 400 УСД за сваки одвојени напад. Када је напад ДРОВН успешан, он добија кључеве за сесију.

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

Унхоли ПАЦ

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

Да ли је ТЛС безбедан?

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

Бизнис технологија за цибер сигурност аутор: ТхеДигиталАртист под лиценцом под ЦЦ0

Brayan Jackson
Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

About the author

Leave a Reply

Your email address will not be published. Required fields are marked *

53 − 47 =

Adblock
detector