Какво е TLS, savepearlharbor

Обща информация за TLS

След SSL протокол е стандартизиран от IETF (Internet Engineering Task Force), тя е преименувана като TLS. Затова, въпреки че имената на SSL и TLS са взаимозаменяеми, те все още са различни, като всяка описва различна версия на протокола.

Както вече споменахме, TLS е проектиран да работи върху TCP, обаче, да се работи с дейтаграма протоколи, като UDP (User Datagram Protocol), специална версия на TLS е разработен, наречена DTLS (Datagram Transport Layer Security).

Encryption, заверка и почтеност

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

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

И накрая, TLS осигурява изпращането на всяко съобщение с код MAC (Message Authentication Code), създаване на алгоритъм, който - еднопосочна функция криптографска хеш стойност (в действителност - контролна сума), ключовете на които се знае, че двамата участници за комуникация. Всеки път, когато изпратите съобщение, генерирано от неговия MAC-стойност, която може да се генерира и приемника, той осигурява целостта на информацията и нейната защита срещу подправяне.

Така накратко разглежда трите механизми в основата TLS протокол kriptobezopasnosti.

TSL Ръкостискане

Преди да започнете обмена на данни чрез TLS, на клиента и сървъра трябва да се споразумеят за параметрите на връзката, а именно: версията използва протокол, метод за криптиране, както и проверка на сертификати, ако е необходимо. Схемата започва съединение, наречено TLS ръкостискане и показано по-долу:

Нека разгледаме по-подробно всяка стъпка от процедурата:

Тъй като TLS минава през TCP, TCP-връзка е настроен да започне между клиента и сървъра.
След инсталиране на TCP, клиентът изпраща към спецификацията на сървър в обикновен текст (т.е. протокол версия, която иска да използва поддържаните методи за криптиране, и т.н.).
Сървърът поддържа версия на протокола, използван, изберете метод за криптиране от посочения списък, отдава своя сертификат и изпраща отговор на клиента (ако е необходимо, сървърът може също да поиска клиентски сертификат).
протокол и метод версия за криптиране, в този момент се считат за одобрени, проверките на клиента изпратени сертификат и инициира нито RSA, или обмен на ключове Diffie-Hellman, в зависимост от вашите настройки.
Сървърът обработва клиента, за да изпратите съобщение, проверява MAC, и изпраща на клиента краен ( "Готово") съобщение на клиента в шифрован вид.
Клиентът декриптира полученото съобщение, проверява MAC, и ако всичко е наред, а след това връзката е установена и започва да се споделя информация за кандидатстване.

Ясно е, че за създаването на връзка TLS, като цяло, дълга и време изразходвам процес, така че в стандарта TLS, има няколко оптимизации. По-специално, има процедура, наречена "съкращение ръкостискане", която позволява използването на предварително договорените параметри за намаляване на съединението (разбира се, ако на клиента и сървъра е установено TLS-връзка в миналото). Тази процедура се обсъжда подробно в раздел "Възобновяване на сесията".

Също така, има допълнително разширяване на процедурата за ръкостискане, което се нарича TLS фалстарт. Това разширение позволява на клиента и сървъра, за да започнат да обменят шифрованите данни веднага след създаването на метода на шифроване, което намалява съобщенията за настройка на връзка на повторение. Това е казал по-подробно в точка "TLS False Start".

Key Exchange TLS протокол

За различни исторически и търговски причини най-често се използва в ключов алгоритъм обмен TLS на RSA: Клиентът генерира симетричен ключ, той криптира с публичния ключ на сървъра и го изпраща на сървъра. На свой ред, сървърът на ключ на клиента е разшифрован с частния ключ. След това, обмен на ключове е обявена за приключена. Този алгоритъм има един недостатък: тя е един чифт Open-частен ключ се използва за удостоверяване на сървъра. Съответно, ако един печалби нападателя достъп до частния ключ на сървъра, може да декриптира цялата сесия. Освен това нападателят може просто да напише цялата сесия е криптирана версия и след това да вземе препис, когато можете да получите личен ключ на сървъра. В същото време, обмен на ключове Diffie-Hellman е по-защитена, както е симетричен ключ никога не напуска клиента или сървъра и поради това не могат да бъдат засечени от хакер, дори и ако той знае частния ключ на сървъра. Тази услуга се основава на намаляване на риска от компрометиране на предишните сесии: създаване на нова по един за всяка нова сесия, на така наречената "временна" симетричен ключ. Съответно, дори и в най-лошия случай (ако противникът знае частен ключ на сървъра), нападателят може да получи само ключовете за бъдещите сесии, но не разшифровате предварително записана.

В момента всички браузъри при инсталиране на връзките TLS дават предпочитание на комбинация от Diffie-Hellman алгоритъм, и използването на временни клавиши, за да се повиши сигурността.

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

Възобновяването на сесията TLS

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

Тъй като първата публична версия на протокола SSL (2.0) сървър в рамките на TLS договарянето (а именно първоначалният доклад ServerHello) може да генерира и изпрати идентификатор на сесия на 32-байт. Естествено, в този случай сървърът съхранява генерираните кеш идентификатор и сесия параметри за всеки клиент. На свой ред, на клиента магазини в изпратил своя идентификатор и го включват (разбира се, ако има такъв) на оригиналното съобщение ClientHello. Ако и двете на клиента и сървъра имат еднакви идентификатори на сесии, инсталирането на една обща връзка възниква при опростена алгоритъм е показано на фигурата. Ако не, то изисква пълната версия на TLS ръкостискане.

Процедурата за възобновяване на сесията ви позволява да пропуснете стъпката на генериране на симетричен ключ, което значително подобрява времето за свързване на инсталацията, но не влияе върху неговата безопасност, като се използва по-рано neskomprometirovannye данни от предишната сесия.

Въпреки това, има практическо ограничение: тъй като сървърът трябва да се съхраняват данни за всички отворени сесии, това води до проблем с популярните ресурси, които се изискват в същото време хиляди и милиони клиенти.
За да избегнете този проблем е разработен механизъм на «Сесия билет», което премахва необходимостта от съхраняване на данни за всеки клиент на сървъра. Ако клиентът по време на първоначалната инсталация връзка посочи, че той поддържа тази технология, сървърът през TLS договарянето се изпраща на клиента така наречените сесия на билетите - сесия параметри, криптиран сървър личен ключ. Следващият път, възобновяването на сесията, клиентът изпраща с ClientHello налични той сесия на билети. По този начин, на сървъра, се освобождава от необходимостта да се съхраняват данни за всяка връзка, но връзката е все още в безопасност, тъй като сесията билет е криптирана с ключ, известен само на сървъра.

TSL фалстарт

сесия технология възобновяване протокол несъмнено увеличава производителността и намалява разходите изчислителни, но тя не е приложима в първоначално свързване към сървъра, или когато предишната сесия е изтекла.
За още по-голяма производителност е разработен TLS фалстарт технология е незадължителен протокол разширение, и ви позволява да изпращате данни, когато TLS договарянето се попълва само частично. Подробна TLS False схема Start е показан по-долу:

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

TLS верига на доверие

Authentication е неразделна част от всеки TLS връзка. Помислете за най-простият процес удостоверяване между Алис и Боб:

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

Ясно е, че схемата е изграден на доверие между Алис и Боб. Предполага се, че обменът на публични ключове случило, например, лично, и по този начин, Алис забравяйте да вземете ключа директно от Боб и Боб, от своя страна, е, че да се получи публичен ключ на Алис.

Да предположим сега, че Алис получава съобщение от Чарли, с когото тя не е запознат, но кой твърди, че е приятел с Боб. За да го докаже, Чарли попита предварително, за да се регистрирате свой собствен публичен ключ затворен публичен ключ на Боб, и отдава подписването на съобщението на Алис. Алис първите проверки подпис Боб по ключова Чарли (тя е в състояние да направи, защото публичния ключ на Боб към вече е известно), е убеден, че Чарли е наистина приятел Боб, като посланието му и изпълнява вече са известни проверка на достоверността, като се уверите, че съобщението е наистина от Чарли :

Описани в предходния параграф, е създаването на "верига на доверие" (или «Верига на доверие", ако на английски език).
В TLS, веригата на доверие се основават на сертификати за автентичност, предоставяни от специални органи, наричани сертифициращи органи (CA - сертифициращи органи). КО провери и, ако е издадено удостоверение, е изложена на риск, сертификатът се отменят.

От издадените удостоверения се състои вече се счита за верига на доверие. Коренът на това е така наречената "Root сертификата Калифорния" - удостоверение, подписано от основен център, доверието, което може да се отрече. Като цяло, от веригата на доверие изглежда така:

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

Механизмът на този тест е проста и тя се основава на т.нар "Списъкът с анулирани сертификати» (CRL - «списъка с анулирани сертификати»). Всеки от ТЗ има в списъка, който е лесен за използване списък на серийните номера на прекратените удостоверения. Съответно, всеки, който иска да се провери автентичността на сертификата, трябва само да се зареди списъка и гледа към нея проверява номера на сертификата. Ако не се намери броя - това означава, че сертификатът е отменено.

Тук е очевидно има някаква техническа ирационалност: да се провери само един сертификат е необходимо да се направи запитване до целия списък на прекратени удостоверения, което води до забавяне. За борба с този механизъм е разработен под името "удостоверение за актуално състояние протокол» (OCSP - Онлайн удостоверение за актуално състояние Protocol). Тя позволява на статут сертификат проверка динамично. Естествено, това намалява натоварването на капацитета на мрежата, но в същото време води до няколко проблема:

КО трябва да се справят с натоварването в реално време;
КО трябва да гарантира тяхната наличност по всяко време;
Благодарение на реално време заявки сертифициращи органи получат информация за кои сайтове се посещават от всеки потребител.

Всъщност, във всички съвременни браузъри, и двете решения (OCSP и CRL) се допълват взаимно, освен това, като правило, можете да настроите предпочитаните от състоянието на политиката за утвърждаване сертификат.

По този начин, тази статия се занимава с всички основни инструменти, предлагани от TLS протокол за защита на данните. За някои не мога да понасям в Article'm съжалявам, струва първоначалната цел на превода.

Предишен ◈ Следващото