Сигурността на транспортния слой (TLS) е един от най-важните и широко използвани протоколи за сигурност. Той защитава значителен дял от данните, които се предават онлайн. Това е най-важното използва се за защита на данните, които пътуват между уеб браузър и уебсайт чрез HTTPS, но може да се използва и за защита на имейл и множество други протоколи.
TLS е ценен, защото гарантира, че другата страна във връзка е това, за което казват, че е, показва дали данните запазват първоначалната си цялост и осигурява конфиденциалност чрез криптиране.
TLS използва набор от различни алгоритми и схеми за постигане на тези цели. Може да изглежда сложно, но тази статия ще обхване един аспект в даден момент, за да ви даде задълбочен поглед върху това как работи TLS за осигуряване на връзки.
Какво прави TLS?
Когато изпращаме информация онлайн, срещаме три основни проблема със сигурността:
- Как можем да разберем дали човекът, с когото общуваме, наистина е такъв, за когото казват?
- Как можем да разберем, че данните не са били подправени, откакто са го изпратили?
- Как можем да попречим на други хора да виждат и да имат достъп до данните?
Тези въпроси са от решаващо значение, особено когато изпращаме чувствителна или ценна информация. TLS използва набор от криптографски техники за справяне с всеки от тези три проблема. Заедно те позволяват на протокола да удостоверете другата страна във връзка, проверете целостта на данните и осигурете криптирана защита.
Нека опростим нещата и се преструваме, че се опитвате да прехвърляте информация напред и назад с приятел, който живее в цялата страна. Ако информацията е чувствителна, ще бъдете много притеснени от трите основни проблема, споменати по-горе.
Не можете просто да изпратите писмо и да се надявате на най-доброто, особено ако подозирате, че вашите комуникации ще бъдат насочени от нападатели. Вместо това ви трябва система, която ви позволява да проверите дали вашият получател е легитимен, начин, по който можете да проверите дали съобщенията са променени и начин да ги защитите от любопитни очи.
TLS изпълнява тези изисквания, използвайки редица различни процеси. Започва с това, което е известно като a TLS ръкостискане, където се извършва удостоверяването и се установяват ключовете.
За да се върнем към нашата аналогия с писма, частта за удостоверяване на TLS би било нещо като изпращане на писмо чрез куриер, който изисква идентификация. Когато куриерът достави писмото, те ще сравнят идентификационния номер на лицето с лицето му и ще проверят дали получателят е правилният човек или не.
Ключовата фаза за установяване би била малко като ако писмото ви съдържа половината от пинов номер, който възнамерявате да използвате в бъдещи комуникации. Бихте помолили получателя си да излезе с втората половина от номера и да ви го изпрати в писмото си за връщане.
След като куриерът потвърди самоличността и номера на пин-кода е установен, ще имате всичко необходимо, за да изпратите сигурно информация. В действителност тези етапи са много по-сложни, но ще стигнем до това по-късно.
TLS обменя сигурно информация с протокола за приложение. Провеждането на нашата аналогия сигурно предаване на данни през TLS би било като изписване на съобщение и поставянето му в плик. Вие ще напишете подписа си през печата, така че ако писмото е било подправено, получателят ви ще може да разбере по разкъсания подпис (това всъщност става с математика, но отново, ще го покрием в дълбочина по-късно).
След това бихте сложили писмото в малка метална кутия с комбинирано заключване, задавайки комбинацията като номер на щифт, който сте установили съвместно с вашия получател. Бихте изпратили кутията чрез куриера, който проверява идентификацията, когато се доставят пакети. Вашият получател ще отговори по същия начин и всяка бъдеща комуникация ще следва същите стъпки.
TLS решава и трите наши проблеми по сравнително подобен начин. Куриерът служи за удостоверяване на получателя и да се увери, че кутията се доставя на нейното предназначение. Заключената кутия служи като форма на криптиране, като не позволява на всеки, освен партньора ви, да получи достъп до писмата. Подписаният плик ви позволява да знаете дали съобщението не е било подправено.
Това е много грубо сближаване на това, което прави TLS. В действителност, TLS се осъществява между клиенти и сървъри, а не двама души, които изпращат поща един на друг. Аналогията е само да ви даде визуализация на случващото се и разсъжденията зад него. В следващите раздели ще разгледаме подробно какво всъщност се случва.
TLS срещу SSL
Когато четете за TLS, често ще видите споменаването на SSL или дори като TLS / SSL. Слоят за сигурни сокети (SSL) е старата версия на TLS, но мнозина в бранша все още препращат към TLS под стария инструмент. Тази статия ще използва термина TLS през цялото време, но е важно да се отбележи, че имената често се използват взаимозаменяемо. Можете да прочетете повече за SSL в нашето ръководство.
Историята на TLS
Всичко започна с необходимостта от закрепване на транспортния слой. Както споменахме по-горе, предшественикът на TLS беше SSL. Първите версии на SSL са разработени през деветдесетте години от Netscape, компания, която изгради един от ранните уеб браузъри.
SSL 1.0 никога не е бил пуснат, защото съдържа сериозни уязвимости. Версия 2.0 излезе с Netscape Navigator 1.1 през 1995 година, въпреки това той все още съдържа редица сериозни недостатъци. SSL 3.0 беше силно преработена версия и излезе през 1996 г. с много проблеми със сигурността.
През 1996г, IETF пусна чернова на SSL 3.0 в RFC 6101. IETF сформира работна група за стандартизиране на SSL, публикувайки резултатите през 1999 г. като TLS 1.0. Той е документиран в RFC 2246 и стандартизацията включва някои промени в оригиналния протокол, както и промяна на името. Тези модификации станаха в резултат на преговори между Netscape, Microsoft и работната група IETF.
През 2006 г. IETF пусна RFC 4346, който документира TLS 1.1. Тази версия съдържа нови разпоредби за сигурност и редица други актуализации. Версия 1.2 беше пусната само две години по-късно през 2008 г. Тя включва поддръжка за автентифицирани шифриращи шифри, редица промени в начина на използване на хеш функциите и много други подобрения.
Следващата версия е пристигнала чак през [year] г., когато е дефиниран TLS 1.3. Той включва множество промени, включително принудителна секретна информация, премахване на поддръжка за по-слаби алгоритми и много други.
TLS 1.0 и 1.1 вече са поставени за оттеглени през [year] г., но версия 1.2 се използва широко. Версия 1.3 започва да вижда увеличено приемане.
TLS: Техническите подробности
TLS се състои от много различни елементи. Основната част е протоколът за запис, основният протокол, отговорен за общата структура на всичко останало.
Диаграма, показваща стека TLS. TLS стек от протоколи от Jeffreytedjosukmono. Лицензиран под CC0.
Протоколът за запис съдържа пет отделни подпротокола, всеки от които е форматиран като записи:
- ръкостискане – Този протокол се използва за настройка на параметрите за сигурна връзка.
- Приложение – Протоколът за кандидатстване започва след процеса на ръкостискане и там данните са сигурно предадени между двете страни.
- Тревога – Протоколът за предупреждение се използва от всяка страна във връзка за уведомяване на другата, ако има грешки, проблеми със стабилността или потенциален компромис.
- Промяна на спецификациите на шифъра – Този протокол се използва от клиента или от сървъра за промяна на параметрите на криптиране. Това е доста просто, така че няма да го разгледаме задълбочено в тази статия.
- Сърдечен пулс – Това е TLS разширение, което позволява на едната страна на връзката да знае дали нейният партньор е все още жив и не позволява на защитните стени да затварят неактивни връзки. Това не е основна част от TLS, така че ще го пропуснем в това ръководство.
Всеки от тези подпротоколи се използва на различни етапи за предаване на различна информация. Най-важните от тях трябва да се разберат са протоколите за ръкостискане и приложенията, защото те са отговорни за установяване на връзката и след това сигурно предаване на данните.
Протоколът за ръкостискане TLS
Тук връзката се установява по сигурен начин. Може да изглежда сложно, ако сте нови за някои от понятията, но всяко от тях е разгледано по-нататък в статията, ако трябва да се обърнете към тях.
Има три основни типа ръкостискане на TLS: the основно TLS ръкостискане, на клиент, удостоверен с клиент TLS и на съкратено ръкостискане.
Основното ръкостискане TLS
Диаграма, показваща процеса на TLS ръкостискане. Пълен TLS 1.2 ръкостискане от FleshGrinder. Лицензиран под CC0.
При този тип ръкостискане се удостоверява само сървърът, а не клиентът. Той започва с фазата на договаряне, при която клиент изпраща a Клиент Здравейте съобщение. Това съдържа най-високата версия на TLS, която клиентът поддържа, възможни пакети от шифри, индикация дали поддържа компресия, произволно число и някаква друга информация
Съобщението за поздрав на клиента е изпълнено с a Сървър Здравейте съобщение. Този отговор съдържа идентификационния номер на сесията, версията на протокола, шифровия пакет и компресирането (ако има такъв), които сървърът е избрал от списъка на клиента. Включва и различно произволно число.
Зависи от шифрования пакет, който е избран, но сървърът обикновено ще следва това чрез изпращане на сертификат съобщение за удостоверяване Това потвърждава неговата идентичност и съдържа неговия публичен ключ.
Ако се използват ефемерни размени Diffie-Hellman или анонимни клавиши Diffie-Hellman, тогава това е последвано от Обмен на сървърни ключове съобщение. Други методи за обмен на ключове пропускайте тази част. Когато сървърът приключи със своята страна на договарянето, той изпраща a Сървър Здравейте Готово съобщение.
Сега отново е ред на клиента. В зависимост от избрания шифров пакет, той ще изпрати a Обмен на клиентски ключове съобщение. Това може да съдържа публичен ключ или секрет на администратора, който е криптиран с публичния ключ на сървъра.
След това и двете страни използват случайните числа и тайната на майсторите, за да измислят главна тайна. Ключовете са извлечени от основната тайна, която след това се използва за удостоверяване и криптиране на комуникациите.
След това клиентът изпраща a Промяна на спецификациите на шифъра съобщение. Това казва на сървъра, че следните съобщения вече ще бъдат удостоверени и кодирани (въпреки че понякога може да не се използва криптиране).
След това клиентът следва това с a завършен съобщение, което е криптирано и съдържа също код за удостоверяване на съобщение (MAC) за удостоверяване. Сървърът дешифрира това съобщение и потвърждава MAC. Ако някой от тези процеси се провали, връзката трябва да бъде отхвърлена.
Сега е ред на сървъра да изпрати Промяна на спецификациите на шифъра съобщение, както и a завършен съобщение със същото съдържание като по-горе. След това клиентът също се опитва да дешифрира и провери съдържанието. Ако това приключи успешно, ръкостискането приключи. На този етап се установява протоколът за кандидатстване. След това данните могат да бъдат обменяни сигурно по същия начин като завършен съобщение отгоре, с удостоверяване и незадължително криптиране.
TLS ръкостискане, удостоверено от клиента
Това ръкостискане много прилича на основното ръкостискане с TLS, но клиентът също е удостоверен. Основната разлика е, че след като сървърът го изпрати сертификат съобщение, то също изпраща a Заявка за сертификат съобщение с искане за сертификата на клиента. След като сървърът е завършен, клиентът изпраща сертификата си в a сертификат съобщение.
След това клиентът го изпраща Обмен на клиентски ключове съобщение, точно както в основното ръкостискане TLS. Това е последвано от Сертификат Потвърждаване съобщение, което включва цифровия подпис на клиента. Тъй като се изчислява от личния ключ на клиента, сървърът може да провери подписа, като използва публичния ключ, който е изпратен като част от цифровия сертификат на клиента. Останалите TLS ръкостискане, удостоверено от клиента следва по същите линии като основното ръкостискане TLS.
Съкратено TLS ръкостискане
След като вече е направено ръкостискане, TLS позволява голяма част от процеса да бъде изрязана, вместо това да се използва съкратено ръкостискане. Тези ръкостискания използват идентификационния номер на сесията, за да свържат новата връзка с предишните параметри.
Съкратеното ръкостискане позволява на двете страни да възобновят сигурната връзка със същата настройка, която беше договорена по-рано. Тъй като част от криптографията, която обикновено участва в инициирането на ръкостискане, може да бъде доста тежка за изчислителни ресурси, това спестява време и прави връзката по-лесна.
Процесът започва с Клиент Здравейте съобщение. Много прилича на по-ранното съобщение за поздрав на клиента, но съдържа и сесиен идентификатор от по-ранната връзка. Ако сървърът знае идентификационния номер на сесията, той го включва в своя Сървър Здравейте съобщение. Ако не разпознае идентификационния номер на сесията, той ще върне различен номер и вместо това ще трябва да се извърши пълно TLS ръкостискане.
Ако сървърът разпознае идентификационния номер на сесията, тогава сертификат и Размяна на ключове стъпките могат да бъдат пропуснати. Най- Промяна на спецификациите на шифъра и завършен съобщенията се изпращат по същия начин като основното ръкостискане TLS, показано по-горе. След като клиентът дешифрира съобщението и потвърди MAC, данните могат да бъдат изпращани през защитената TLS връзка.
Има и TLS разширение, което позволява връзките да се възобновят с билети за сесия вместо идентификационни номера на сесията. Сървърът криптира данни за сесията и ги изпраща на клиента. Когато клиентът иска да възобнови тази връзка, той изпраща билет за сесия на сървъра, който го дешифрира, за да разкрие параметрите.
Билетите за сесия не се използват толкова често, защото изискват удължаване. Въпреки това, те могат да бъдат изгодни в определени ситуации, тъй като сървърът не трябва да съхранява нищо.
Разопаковане на TLS ръкостискане
Трите най-важни стъпки от ръкостискането включват:
- параметрите са избрани,
- той проверява удостоверяването и
- ключовете са установени.
Нека ги разгледаме малко по-подробно, за да разберете какво всъщност се случва.
Параметрите
В началото на ръкостискането клиентът и сървърът договарят параметрите на връзката по взаимно съгласие. Първият от тях е коя версия на TLS ще се използва. Това е най-високата версия, която и двете страни поддържат, която е най-сигурна.
Страните също решават кой алгоритъм за обмен на ключове ще използват за установяване на главния ключ. Хеш функцията, алгоритъмът за криптиране и методът на компресия също са договорени на този етап. Те ще бъдат разгледани подробно, когато обсъждаме Протокол за приложение по-късно в статията.
Удостоверяване: Цифрови сертификати
Удостоверяването е ключова част от осигуряването на канал за комуникация, тъй като дава възможност на двете страни да знаят, че всъщност говорят с кого смятат, а не са измамници. В TLS и много други механизми за сигурност това се постига с това, което е известно като цифрови сертификати.
Цифровите сертификати са електронни документи, които показват връзката между физическо или юридическо лице и техния публичен ключ. Тази връзка е утвърдена от сертифициращ орган (CA), който е доверена организация, която проверява дали двете са действително свързани, след това използва собствената си репутация, за да предостави доверие на сертификата.
Различните нива на сертификати представляват различна степен на доверие. Важното е да знаете, че ако клиент или сървър има надежден и валиден сертификат, тогава е разумно да се предполага, че публичният ключ е легитимен и че не се занимавате с нападател.
Бележка за публичните ключове
Криптирането с публичен ключ (известно още като асиметрично криптиране) е важна част от криптографията и се използва широко в различните аспекти на TLS. Ето бърз грунд за тези, които не са запознати с начина на работа.
Краткото обяснение е, че криптографията с публичен ключ използва двойка ключове за криптиране и декриптиране, а не само един ключ. Подателят използва публичния ключ на предвидения получател, за да криптира данните. След като бъде кодиран, той може да бъде дешифриран само от съответстващия частен ключ на получателя. Разбира се, публичният ключ може да бъде споделен публично, докато частният ключ трябва да се пази в тайна.
Шифроването с публичен ключ позволява на страните да споделят информация по сигурен начин, дори ако те никога не са се срещали или са имали възможност предварително да обменят ключове. Това прави чрез някои уникални свойства на прости числа. Можете да разберете повече в нашата статия за криптирането с публичен ключ.
Създаване на главна тайна
Както видяхме по-горе, когато обсъждахме процеса на основното ръкостискане на TLS, след като страна (или и двете страни) докаже своята идентичност с публичния си сертификат, следващата стъпка е да се установи главната тайна, известна още като споделена тайна. Главната тайна е основата за извличане на ключовете, използвани както за криптиране, така и за проверка на целостта на данните, предавани между двете страни.
TLS ръкостискането може да използва няколко различни механизма, за да сподели безопасно тази тайна. Те включват RSA, няколко различни типа обмен на ключове Diffie-Hellman, PSK, Kerberos и други. Всяка от тях има своите предимства и недостатъци, като например предоставяне на секретна информация, но тези разлики са извън обхвата на тази статия.
Точният процес ще зависи от това кой метод за обмен на ключове е избран, но следва грубите стъпки, споменати в Основното ръкостискане TLS раздел.
Тайната на премастър се извлича според метода за обмен на ключове, който преди това е бил избран. Клиентът криптира тайната на премастъра с публичния ключ на сървъра, за да го изпрати безопасно през връзката.
След това клиентът и сървърът използват тайната на премастъра и случайните числа, които са изпратили в началото на комуникацията, за да излязат с основната тайна. След като главният ключ е изчислен, той се използва за създаване на четири или шест отделни ключа. Тези са:
- Клиентът пише MAC ключ – Този ключ се използва от сървъра за проверка на целостта на данните, изпратени от клиента.
- MAC ключ за запис на сървър – MAC ключът за запис на сървъра се използва от клиента за проверка на целостта на данните, изпратени от сървъра.
- Клиентски ключ за криптиране – Сървърът използва този ключ за криптиране на данни, изпратени от клиента.
- Ключ за криптиране на запис от сървъра – Клиентът използва този ключ за криптиране на данни, изпратени от сървъра.
- Клиентът пише IV ключ – Ключът за запис на клиент IV се използва от сървъра в AEAD шифри, но не и когато се използват други алгоритми за обмен на ключове.
- Ключ за запис на сървъра – По същия начин този ключ се използва от клиента в AEAD шифри, но не и когато се използват други алгоритми за обмен на ключове.
Установяването на главния ключ е важна част от ръкостискането на TLS, тъй като позволява на двете страни на връзката да извлекат сигурно ключове, които могат да се използват както за автентификация, така и за криптиране. Отделни клавиши се използват и за двата процеса като предпазна мярка.
След като са получени ключовете за удостоверяване и криптиране, те се използват за защита на двете завършен съобщения, както и записи, изпратени чрез протокола за приложение.
Протоколът за кандидатстване
След като се установи сигурна връзка чрез ръкостискане на TLS, протоколът на приложението се използва за защита на предаваните данни. Тя може да бъде конфигурирана да използва широк спектър от алгоритми, за да отговаря на различни сценарии.
Алгоритми за удостоверяване
Целостта на съобщенията може да се провери с много различни алгоритми. Те включват:
- HMAC-MD5
- HMAC-SHA1
- HMAC-SHA2
- AEAD
За да докаже целостта на изпращаните данни, изпращачът управлява информацията чрез хеш функция, за да върне уникален низ от знаци. Това са специални формули, които винаги ще връщат един и същ резултат всеки път, когато получат един и същи вход.
Изпращачът подписва тези данни с личния си ключ, за да формира онова, което е известно като цифров подпис, След това цифровият подпис се прикрепя към съобщението и се изпраща на получателя. За да проверите дали данните запазват целостта си и не са били подправени, получателят дешифрира хеша с публичния ключ на подателя. След това те използват същата хеш функция на изпратените данни. След това получателят сравнява двете стойности.
Ако те са еднакви, това означава, че данните не са променени, тъй като са били подписани от подателя. Ако те са различни, е вероятно данните да са били подправени или е имало някаква друга грешка.
Това е кратката версия за това как хеш функциите могат да бъдат използвани за показване целостта на данните. Ако искате по-задълбочено разбиране, разгледайте нашата статия за криптирането, осоляването и хеширането.
Алгоритми за криптиране
TLS използва криптиране на симетричен ключ, за да осигури конфиденциалност на данните, които предава. За разлика от криптирането с публичен ключ, само един ключ се използва както в процесите на криптиране, така и в декриптирането. След като данните са шифровани с алгоритъм, те ще се появят като смесица от шифротекст. Докато се използва подходящ алгоритъм, нападателите няма да имат достъп до действителните данни, дори и да го прихванат.
TLS може да използва много различни алгоритми, като Camellia или ARIA, въпреки че най-популярният е AES.
компресия
Компресирането е процесът на кодиране на данни, за да заеме по-малко място. TLS поддържа компресия, ако и двете страни на връзката решат да я използват. Въпреки тази способност, обикновено се препоръчва да се избягва използването на TLS за компресиране на данни, особено след криминалната атака (виж Проблеми със сигурността на TLS раздел по-долу) беше установено, че може да се възползва от компресирани данни за отвличане на сесия.
подложка
Padding добавя допълнителни данни към съобщение, преди да бъде шифровано. Това е общ криптографски процес, който се използва, за да предотврати намеците в структурата на криптирани данни да предадат истинското си значение. Обикновено TLS прилага PKCS # 7 padding към записи преди да бъдат шифровани.
Протокол за предупреждение
Ако връзката или сигурността стане нестабилна, компрометирана или е възникнала сериозна грешка, протоколът за предупреждение позволява на подателя да уведоми другата страна. Тези съобщения имат два вида – предупредителни или фатални. Предупредително съобщение показва, че сесията е нестабилна и позволява на получателя да определи дали сесията трябва да продължи или не.
Фатално съобщение казва на получателя, че връзката е компрометирана или е възникнала сериозна грешка. Подателят трябва да прекрати връзката, след като изпрати съобщението. Протоколът за предупреждение съдържа също информация за това, което причинява конкретния проблем с връзката. Това може да включва неща като отказ на декриптиране, неизвестен орган на сертификата, незаконен параметър и много други.
TLS & модела OSI
Моделът OSI е начин да концептуализираме и стандартизираме начина, по който разглеждаме различните си комуникационни системи и протоколи. Важно е да се отбележи, че това е просто модел и някои от нашите протоколи не съответстват на него.
OSI има седем отделни слоя, които показват нивата, на които работят протоколите, TLS не се вписва в нито един. Той преминава през друг транспортен протокол като TCP, което трябва да означава, че е над четвъртия слой, транспортния слой. Най-добре се използва като транспортен слой, но тъй като провежда ръкостискане, това означава, че е част от слоевете за презентация или приложение.
Както можете да видите, TLS просто не съответства на OSI модела. Това не означава, че TLS е счупен или грешен, ако не друго, той просто показва, че моделът на OSI е погрешен и не може да отчита всички наши комуникационни протоколи.
Използване на TLS
TLS се използва за осигуряване на значителна част от нашите онлайн комуникации. Обикновено се реализира над протоколи като Протокол за контрол на предаването (TCP), но може да се използва и в протокола за контрол на конгестията на Datagram (DCCP) и протокола на потребителската дейтаграма (UDP).
Той може да защити протоколи като HTTP, SMTP, FTP, XMPP и NNTP, както и други. Най-честото приложение е като Hypertext Transfer Protocol Secure (HTTPS), което защитава връзката между уеб браузър и уебсайт. Можете да кажете кога HTTPS се използва за осигуряване на вашата онлайн връзка, защото вляво от URL адреса в горната част на браузъра ще се появи малка зелена икона за заключване.
TLS може да се използва и за изграждане на VPN, като например в OpenConnect и OpenVPN. Той използва своите възможности за криптиране и удостоверяване, за да образува тунел, който може да свързва хостове и мрежи помежду си. TLS-базирани VPN технологии като OpenVPN са изгодни пред алтернативи като IPsec, тъй като не е известно, че OpenVPN има сериозни проблеми със сигурността. Тези VPN адреси също могат да бъдат по-лесни за конфигуриране.
Друга негова употреба е да сигурен имейл чрез STARTTLS. Когато TLS е внедрен, той не позволява на нападателите да имат достъп до съобщения, докато пътуват между пощенските сървъри.
Проблеми със сигурността на TLS
Подобно на повечето протоколи, TLS има редица минали уязвимости и теоретични атаки срещу различните му реализации. Въпреки това, последните версии се считат за сигурни за практически цели.
Минали версии, като SSL 2.0 и 3.0 (и TLS 1.0, който по същество е същият като SSL 3.0), имат множество недостатъци на сигурността, но тъй като те са стари и остарели протоколи, няма да навлизаме в детайлите. Трябва да използвате TLS 1.2 и 1.3, за да защитите връзките си вместо това.
По-новите версии на TLS имат многобройни ъпгрейди, които го правят по-малко уязвим от SSL. Въпреки това протоколът все още има следните проблеми със сигурността:
Пристъпи за предоговаряне
Една от характеристиките на TLS е, че позволява на двойки клиент и сървър да предоговарят параметрите на тяхната съществуваща връзка. През 2009 г. беше открито, че това може да бъде използвано от нападатели, така че те да могат да инжектират трафик, за да изглежда, че идва от клиента. Сървърите ще приемат заявката като законна, което означава, че атакуващите потенциално биха могли да манипулират изходящите съобщения.
Тази атака не позволява на нападателя да види отговора, но все пак има потенциал да навреди. Разширението, което ще предотврати тези атаки, понастоящем е предложен стандарт.
BEAST
Атаката на браузъра срещу експлоатация срещу SSL / TLS (BEAST) е открита за първи път от изследователите през 2011 г. Той се възползва от шифровия блок, който веригира уязвимостта в TLS, която може да се използва за декриптиране на съобщения. Тази атака засяга само TLS 1.0, която е стара и по-слаба версия на протокола. Въпреки че той няма да бъде остарял до [year] г., вместо това потребителите трябва да използват версии 1.2 и 1.3.
Временни атаки
Тези атаки на странични канали анализират колко време отнема да работи алгоритъм, след което го използват, за да работят назад и да разберат ключа. През 2013 г. атаката Lucky Thirteen бе открита, за да използва както атака на времето, така и атака на оракула, докато се проверява кодът за удостоверяване на съобщението (MAC). Тази атака може да се използва за разбиване на TLS алгоритъма, въпреки че не се счита за опасна за повечето потребители на TLS.
ПРЕСТЪПНОСТ & НАРУШЕНИЕ
CRIME атаката работи срещу редица протоколи. Когато данните са компресирани, тя може да извлича съдържание от бисквитки за удостоверяване. Тази информация може да се използва за отвличане на сесия. Въпреки че засяга редица протоколи, атаката е особено тревожна, когато се използва HTTP компресия, тъй като няма ефективни стратегии за смекчаване.
През 2013 г. експлоатацията на браузъра Reconnaissance and Exfiltration чрез адаптивно компресиране на хипертекст (BREACH) експлоатация е установена, че влияе по HTTP компресията по подобен начин. Тази версия на атаката може да възстанови имейл адреси и други ценни данни, които бяха шифровани с TLS. BREACH атаката може да бъде смекчена чрез деактивиране на HTTP компресията или използване на техники като защита от подправяне на заявки между различни сайтове (CSRF).
Низходящи атаки
Това са атаки, които измамват сървърите да използват по-ранни и по-малко защитени версии на TLS. Нападателите биха могли да използват тези техники за договаряне на използването на по-малко сигурни обмени на ключове и шифри. Атаката на Logjam е добър пример, защото може да накара уязвимите сървъри да използват 512-битов Diffie-Hellman, което е слабо. След това нападателите могат да разрушат този механизъм за обмен на ключове и да извлекат ключовете, като им позволяват пълен достъп до сесията.
Heartbleed
Heartbleed беше пропуск в сигурността, който случайно беше въведен в библиотеката с криптографии на OpenSSL през 2012 година, но не се публикува до 2014 г. Тъй като това е толкова често използвана реализация на TLS, тя нанесе значителни глобални щети.
Един от разработчиците за разширението на сърдечния ритъм на TLS добави уязвимост на буфер над четене, което позволява да бъдат изложени някои допълнителни данни. Грешката не беше взета при прегледа на кода, което доведе до редица значителни атаки.
Тъй като библиотеката на OpenSSL се прилага толкова широко, международните разходи за смекчаване на проблема се оказаха доста скъпи. Администраторите на сървъра трябваше да инсталират новия патч и регенерират сертификати и ключови двойки, които може да са били компрометирани през двугодишния период, когато съществува уязвимостта.
давя
Дешифрирането на RSA с неактуална и отслабена eNcryption (DROWN) атака бе обявено през 2016 г. и се възползва от поддръжката на сървъра за SSL 2.0. Той използва атака с избран шифротекст срещу сървъри, които все още поддържат SSL 2.0, както и тези, които споделят същия сертификат за публичен ключ с друг сървър, който поддържа SSL 2.0.
Когато атаката беше обявена, тя може да бъде стартирана с първоначални разходи за настройка от около 18 000 долара и около 400 долара за всяка отделна атака. Когато атаката DROWN е успешна, тя придобива ключовете за сесията.
Атаката може да бъде смекчена чрез споделяне на сървърни сертификати. OpenSSL групата също пусна кръпки, които премахват поддръжка за по-стари протоколи и шифри, но те работят само ако сертификатът на сървъра не е споделен с други сървъри, които поддържат SSL 2.0.
Нечестен PAC
Тази атака бе открита през 2016 г. Тя използва слабости, открити в протокола за автоматично откриване на уеб прокси (WPAD). Когато потребителят се опита да посети уебсайт чрез криптирана TLS връзка, недостатъкът може да направи URL адреса видим. Тъй като понякога URL адреси се изпращат на потребителите като форма за удостоверяване, атаката Unholy PAC дава възможност на нападателя да поеме акаунта на потребителя.
Безопасен ли е TLS?
Въпреки че може да изглежда, че има много проблеми със сигурността, реалността е, че повечето от тях са доста незначителни и могат или са били смекчени. С напредването на технологиите се откриват уязвимости и се разработват нови атаки, TLS ще продължи да има повече проблеми със сигурността. Въпреки това, засега и обозримото бъдеще, изглежда, че TLS все още ще бъде един от основните и най-надеждни инструменти, които използваме за осигуряване на нашия онлайн свят.
Бизнес технология за киберсигурност от TheDigitalArtist, лицензиран съгласно CC0
