Ssl tls приема всички сертификати. Уверете се, че ssl и tls са активирани

Мрежови протоколи SSL и TLS са криптографски протоколи, които осигуряват удостоверяване и защита срещу неоторизиран достъп, нарушаване на целостта на предаваните данни. Протоколите SSL/TLS са предназначени да предотвратят подправяне на идентичност от страна на клиента или сървъра, разкриване или изкривяване на данни. За тези цели се използва надежден метод за удостоверяване, използва се криптиране на комуникационния канал и кодове за интегритет на съобщенията. Портът по подразбиране за SSL/TLS е порт 443 за HTTPS, 465 за SMTPS (имейл), 636 за LDAPS, 563 за NNTPS, 994 за IRCS (чат), 995 за POP3S.

SSL протокол

SSL протоколът е разработен от Netscape за защита на данните между сервизните и транспортните протоколи. Първата публикувана версия е издадена през 1995 г. Широко използван за VoIP приложения, услуги за незабавни съобщения. SSL е защитен канал, който има следните свойства:

Частен канал. Всички съобщения се криптират след диалога, необходим за определяне на ключа за криптиране.
Каналът е удостоверен. Удостоверяването не е задължително за страната на клиента, но е задължително за страната на сървъра.
Надеждност на канала. Когато съобщенията се транспортират, се извършва проверка на целостта с помощта на MAC.

SSL протоколът използва както симетрични, така и асиметрични ключове.

Характеристики и предназначение на SSL протокола

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

Слоевата структура е представена от слой на протокол за потвърждение на връзката и слой на протокол за запис. Първият слой е транспортният протокол, например TCP - заедно със SSL Record Protocol, тези слоеве формират ядрото на SSL, което впоследствие участва във формирането на сложни инфраструктури.

Сред основните характеристики на SSL протокола трябва да се отбележи независимостта на софтуерната платформа. В момента SSL протоколът не осигурява адекватна защита - той е заменен от TLS протокола.

TLS протокол

Протоколът TLS е криптографски протокол, който се използва за сигурно прехвърляне на данни между различни възли в Интернет. Този протокол е намерил приложение във VoIP приложения, уеб браузъри, приложения за незабавни съобщения. TLS е внедрен в спецификацията SSL 3.0. IETF участва в разработването и развитието на протокола.

Основните мерки за сигурност, осигурени от протокола TLS, включват:

Използването на ключ за проверка на кода за удостоверяване на съобщението.
Елиминира възможността за понижаване на TLS или замяната му с по-малко защитен мрежов протокол.
Съобщението за ръкостискане съдържа хеш на всички съобщения, разменени между страните.
Използване на номериране на запис на приложение с помощта на MAC.
Използването на псевдослучайна функция, която разделя входните съобщения на 2 части, всяка от които се обработва от различна хеш функция.

Характеристики и предназначение на протокола TLS

TLS протоколът използва следните алгоритми:

RC4, Triple DES, SEED, IDEA и др. за симетрично криптиране.
RSA, DSA, Diffie-Hellman и ECDSA за удостоверяване на ключове.
MD5, SHA и SHA-256/384 за хеш функции.

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

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

Какво е TLS ръкостискане и как работи

TLS е един от най-често използваните инструменти за сигурност в Интернет. Протоколът работи активно с много мрежови процеси: прехвърляне на файлове, VPN връзка (в някои реализации за обмен на ключове), услуги за незабавни съобщения или IP телефония.

Един от ключовите аспекти на протокола е ръкостискането. Именно за него ще говорим в тази статия.

„SSL/TLS ръкостискане“ е името на стъпката за настройка на HTTPS връзката. По-голямата част от работата, свързана с протокола SSL/TLS, се извършва на този етап. Миналата година IETF финализира TLS 1.3 с цялостно преразглеждане на процеса на ръкостискане.
Статията ще обхване два типа ръкостискане - за протоколите TLS 1.2 и TLS 1.3, които ще разгледаме, започвайки от абстрактно ниво и постепенно задълбавайки в характеристиките:

координиране на криптографски протоколи;
удостоверяване със SSL сертификат;
генериране на сесиен ключ.

Как работи TLS ръкостискането?

В HTTPS връзката участват две страни: клиент (инициаторът на връзката, обикновено уеб браузър) и сървър. Целта на SSL/TLS ръкостискането е да извърши цялата криптографска работа за установяване на защитена връзка, включително проверка на автентичността на използвания SSL сертификат и генериране на ключ за криптиране.

Преговори за шифрован набор

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

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

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

Удостоверяване

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

Всички надеждни SSL сертификати се издават от Сертифициращ орган (CA). CA трябва да спазва стриктни правила за издаване и валидиране на сертификати, за да се ползва с доверие. Можете да си представите КО като нещо като нотариус - неговият подпис означава, че данните в удостоверението са реални.

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

В тази стъпка клиентът индиректно проверява дали сървърът притежава частния ключ, свързан със сертификата.

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

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

Размяна на ключове

Последната част от TLS ръкостискането включва създаване на „сесиен ключ“, който всъщност ще се използва за защитени комуникации.

Сесийните ключове са "симетрични", което означава, че един и същ ключ се използва както за криптиране, така и за декриптиране.

Симетричното криптиране е по-бързо от асиметричното криптиране, което го прави по-подходящо за изпращане на данни през HTTPS връзка. Точният метод за генериране на ключове зависи от избрания шифров пакет, като двата най-често срещани са RSA и Diffie-Hellman.

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

Цялото SSL ръкостискане се случва за няколкостотин милисекунди. Това е първото нещо, което се случва при HTTPS връзка, дори преди уеб страницата да бъде заредена. След SSL ръкостискането започва криптирана и удостоверена HTTPS връзка и всички данни, изпратени и получени от клиента и сървъра, са защитени.

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

Процес на ръкостискане стъпка по стъпка в TLS 1.2

Нека разгледаме по-отблизо TLS ръкостискането с помощта на RSA. Използването на алгоритъма на Дифи-Хелман ще бъде описано по-долу.

Първото съобщение се нарича "Client Hello". Това съобщение изброява опциите на клиента, така че сървърът да може да избере набора от шифри, който ще използва за комуникация. Съобщението също така включва голямо произволно избрано просто число, наречено „случайно число на клиента“.
Сървърът учтиво отговаря със съобщение "Server Hello". Там той казва на клиента какви опции за свързване са избрани и връща своето произволно избрано просто число, наречено "случайно число на сървъра". Ако клиентът и сървърът не споделят пакети за шифроване, връзката е неуспешна.
В съобщението „Сертификат“ сървърът изпраща своята верига от SSL сертификати на клиента, която включва листови и междинни сертификати. След получаването им, клиентът извършва няколко проверки за проверка на сертификата. Клиентът трябва също така да гарантира, че сървърът има частен ключсертификат, което се случва по време на процеса на обмен/генериране на ключове.
Това е незадължително съобщение, необходимо само за определени методи за обмен на ключове (като Diffie-Hellman), които изискват допълнителни данни от сървъра.
Съобщението "Server Hello Done" уведомява клиента, че сървърът е приключил с предаването на данни.
След това клиентът участва в генерирането на сесийния ключ. Спецификата на тази стъпка зависи от метода за обмен на ключове, който е избран в оригиналните съобщения „Hello“. Тъй като разглеждаме RSA, клиентът ще генерира произволен низ от байтове, наречен pre-master secret, ще го шифрова с публичния ключ на сървъра и ще го изпрати обратно.
Съобщението „Change Cipher Spec“ уведомява другата страна, че сесийният ключ е генериран и може да премине към криптирана връзка.
След това се изпраща съобщението „Готово“, което показва, че ръкостискането е завършено от страна на клиента. От този момент нататък връзката е защитена от сесийния ключ. Съобщението съдържа данни (MAC), които могат да се използват за проверка дали ръкостискането не е било подправено.
Сега сървърът дешифрира предшестващата главна тайна и изчислява ключа на сесията. След това изпраща съобщение "Change Cipher Spec", за да уведоми, че превключва към криптирана връзка.
Сървърът също така изпраща съобщение „Готово“, използвайки новогенерирания ключ за симетрична сесия и проверява контролната сума, за да провери целостта на цялото ръкостискане.

След тези стъпки SSL ръкостискането е завършено. И двете страни вече имат сесиен ключ и могат да комуникират чрез криптирана и удостоверена връзка.

В този момент могат да бъдат изпратени първите байтове на уеб приложението (данни, свързани с действителната услуга - HTML, Javascript и др.).

Процес на ръкостискане стъпка по стъпка в TLS 1.3

Ръкостискането TLS 1.3 е значително по-кратко от своя предшественик.

Както при TLS 1.2, съобщението „Client Hello“ задейства ръкостискането, но този път то съдържа много повече информация. TLS 1.3 намали броя на поддържаните шифри от 37 на 5. Това означава, че клиентът може да познае кое споразумение за ключ или протокол за обмен ще се използва, така че изпраща своята част от публичния ключ от предполагаемия протокол в допълнение към съобщението.
Сървърът ще отговори със съобщение "Server Hello". Както при ръкостискане 1.2, в този момент се изпраща сертификат. Ако клиентът е познал правилно протокола за криптиране с прикачените данни и сървърът се е съгласил с него, последният изпраща своята част от публичния ключ, изчислява ключа на сесията и завършва предаването със съобщение „Сървърът е завършен“.
Сега, когато клиентът разполага с цялата необходима информация, той проверява SSL сертификата и използва двата публични ключа, за да изчисли своето копие на сесийния ключ. Когато приключи, изпраща съобщение „Клиентът завърши“.

TLS ръкостискане отгоре

В исторически план едно от оплакванията относно SSL/TLS е, че претоварва сървърите с допълнителни разходи. Това допринесе за вече несъществуващото схващане, че HTTPS е по-бавен от HTTP.

Ръкостисканията преди TLS 1.2 изискваха много ресурси и в голям мащаб можеха сериозно да натоварят сървъра. Дори ръкостисканията на TLS 1.2 могат да забавят нещата, ако има много от тях, които се случват по едно и също време. Удостоверяването, криптирането и декриптирането са скъпи процеси.

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

Подобрения в ръкостискането на TLS 1.3 спрямо TLS 1.2

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

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

За разлика от 1.2, ръкостискането на TLS 1.3 се вписва в една фаза, въпреки че би било по-точно да се каже една и половина, но все пак е много по-бързо от TLS 1.2.

Намаляване на комплекти за шифроване

Никой никога нямаше да използва 37 набора за криптиране на данни, така се разви протоколът. Всеки път, когато се добавя нов алгоритъм, се добавят нови комбинации и скоро IANA администрира 37 различни пакета за шифроване.

Това е лошо поради две причини:

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

IETF премахна поддръжката за всички, освен за най-сигурните алгоритми в TLS 1.3, премахвайки объркването чрез ограничаване на избора. По-специално, изборът на метод за обмен на ключове е премахнат. Ефимерната схема Diffie-Hellman се превърна в единствения начин клиентът да изпрати ключовата си информация заедно с „Клиентски здравей“ в първата част на ръкостискането. RSA криптирането е напълно премахнато заедно с всички други схеми за обмен на статични ключове.

Като се има предвид това, има една потенциална ахилесова пета в TLS 1.3.

Нулево време за препредаване - 0-RTT

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

Въпреки всички предимства на 0-RTT, той съдържа няколко потенциални клопки. Режимът прави клиентите податливи на повторни атаки, при които нападател, който по някакъв начин успява да получи достъп до криптирана сесия, може да получи 0-RTT данни, включително първата заявка на клиента, и да ги изпрати обратно на сървъра.

Експлойтът обаче не е лесен за използване. Вероятно такъв риск е малка цена за изключително полезна функция.

Безопасност

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

При ръкостискането на TLS 1.2 стъпките за преговори не бяха сигурни, вместо това беше използвана проста MAC функция, за да се предотврати намесата на никого в предаването. Фазата на преговорите включва съобщения "Клиентски здравей" и "Здравей на сървъра".

MAC функцията действа като индикатор, но не предоставя никакви гаранции за сигурност. Може да сте чували за атака, която принуждава страните да използват по-малко сигурни протоколи и функции (атака за понижаване). Ако и сървърът, и клиентът поддържат остарели пакети за шифроване - това се получава лесно чрез прослушване на връзката - атакуващият може да промени криптирането, избрано от сървъра, на по-слабо. Такива атаки не са опасни сами по себе си, но отварят вратата към други известни подвизи на тези пакети за шифроване, на които е променен първоначално избраният.

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

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

Комплекти за шифроване на TLS ръкостискане

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

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

Комплекти за шифроване TLS 1.2

TLS е протокол.
ECDHE е алгоритъм за обмен на ключове.
ECDSA е алгоритъм за удостоверяване.
AES 128 GCM е симетричен алгоритъм за криптиране.
SHA256 е алгоритъм за хеширане.

Горният пример използва система на Diffie-Hellman (DH) с ефимерна елиптична крива за обмен на ключове и алгоритъм за цифров подпис с елиптична крива за удостоверяване. DH може също да бъде свързан към RSA (функциониращ като алгоритъм за цифров подпис) за извършване на удостоверяване.

Ето списък на най-широко поддържаните комплекти за шифроване TLS 1.2:

Комплекти за шифроване TLS 1.3

TLS е протокол.
AES 256 GCM - Удостоверено криптиране с прикачени данни (AEAD).
SHA384 е алгоритъм за хеширана функция за генериране на ключ (HKFD).

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

От горния пример можете да видите, че AES (Advanced Encryption Standard) се използва за криптиране на голямо количество данни. Той работи в режим на брояч на Galois, използвайки 256-битови ключове.

Ето петте пакета за шифроване, които се поддържат в TLS 1.3:

TLS_AES_256_GCM_SHA384;
TLS_CHACHA20_POLY1305_SHA256;
TLS_AES_128_GCM_SHA256;
TLS_AES_128_CCM_8_SHA256;
TLS_AES_128_CCM_SHA256.

Какво се промени в TLS 1.3 в сравнение с TLS 1.2?

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

Ръкостискането на TLS 1.3 също подобри някои процеси, като удостоверяване на съобщения и цифрови подписи.

И накрая, в допълнение към премахването на старите алгоритми за генериране или обмен на ключове, TLS 1.3 елиминира старите симетрични шифри. TLS 1.3 елиминира изцяло блоковите шифри. Единственият тип симетричен шифър, разрешен в TLS 1.3, се нарича спомагателно автентифицирано шифроване (AEAD). Той комбинира криптиране и удостоверяване на съобщения (MAC) в една функция.

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

Исторически двата основни обмена на ключове са RSA и Diffie-Hellman (DH), в наши дни DH често се свързва с елиптични криви (ECDH). Въпреки някои основни прилики, има фундаментални разлики между двата ключови подхода за обмен.

С други думи, RSA TLS ръкостискането е различно от ECDH TLS ръкостискането.

RSA използва проста факторизация и модулна аритметика. Големите прости числа изискват много мощност на процесора за изчисление и са трудни за извличане.

Diffie-Hellman понякога се нарича експоненциален обмен на ключове, което показва степенуване (в допълнение към модулната аритметика), но самият DH всъщност не криптира или декриптира нищо. Така че наричането му „метод на криптиране“ вместо „математическа обосновка“ може да е малко подвеждащо.

Едно кратко отклонение в историята може да изясни този въпрос.

Още през 1976 г. Whitfield Diffie и Martin Hellman създават протокол за обмен на ключове, базиран на работата на Ralph Merkle, чието име, според двамата, също трябва да фигурира в името на протокола.

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

Това може да се счита за раждането на криптографията с публичен ключ и PKI. Малко след като Diffie и Hellman представиха техния протокол за обмен на ключове, бяха завършени най-ранните версии на криптосистемата RSA. Дифи и Хелман са създали концепцията за криптиране с публичен ключ, но все още не са измислили действителната функция на еднопосочното криптиране.

Рон Ривест (R в RSA) беше този, който създаде концепцията, която в крайна сметка се превърна в криптосистемата RSA.

В много отношения RSA е духовният наследник на DH. Той извършва:

генериране на ключове;
обмен на ключове;
криптиране;
декриптиране.

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

Докато RSA обработва удостоверяването и обмена на ключове, Diffie-Hellman само улеснява обмена на ключове. Има четири често срещани варианта на фамилията DH:

Дифи-Хелман (DH);
ефимерен (краткосрочен) Diffie-Hellman (DHE);
елиптична крива на Дифи-Хелман (ECDH);
елиптична крива ефимерна Diffie-Hellman (ECDHE).

Отново Diffie-Hellman сам по себе си не удостоверява нищо. Трябва да се използва заедно с алгоритъм за цифров подпис. Така че, например, ако сте използвали ECDH или ECDHE, повечето пакети за шифроване ще се сдвоят с алгоритъма за цифров подпис на елиптична крива (ECDSA) или RSA.

TLS 1.2 удостоверяване чрез ръкостискане

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

От друга страна, ако Diffie-Hellman не удостоверява, тогава какво прави? Както бе споменато по-горе, DH често се използва заедно с криптография с елиптична крива за осигуряване на удостоверяване и обмен на ключове.

Елиптичната криптография (ECC) има много по-малки размери на ключовете, които отговарят на елиптичната крива, на която се основават. Има пет подходящи криви за този контекст:

192 бита;
224 бита;
256 бита;
384 бита;
521 бита

Но това не е единствената разлика между ECC публични/частни ключове и RSA ключове. Те се използват за две напълно различни цели по време на TLS ръкостискането.

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

С Diffie-Hellman двойката публичен/частен ключ НЕ се използва за симетричен обмен на сесиен ключ. Когато Diffie-Hellman е включен, частният ключ всъщност е свързан с придружаващия алгоритъм за подпис (ECDSA или RSA).

RSA удостоверяване

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

Когато клиент получи SSL сертификат на сървър, той проверява няколко показателя:

електронен подпис с публичен ключ;
верига от сертификати, за да се уверите, че сертификатът идва от един от главните сертификати в довереното хранилище;
срок на годност, за да сте сигурни, че не е изтекъл;
състояние на анулиране на сертификат.

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

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

DH удостоверяване

Когато се използват Diffie-Hellman и ECDSA/RSA, удостоверяването и обменът на ключове се разполагат един до друг. И това ни връща към ключовете и техните употреби. Публичният/частният ключ RSA се използва както за обмен на ключове, така и за удостоверяване. В DH + ECDSA/RSA двойка асиметрични ключове се използва само за цифров подпис или стъпка за удостоверяване.

Когато клиентът получи сертификат, той все още извършва стандартните проверки:

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

Но притежаването на частния ключ се проверява по различен начин. По време на обмена на ключ за ръкостискане на TLS (стъпка 4), сървърът използва своя частен ключ, за да шифрова произволното число на клиента и сървъра, както и своя DH параметър. Той действа като цифров подпис на сървъра и клиентът може да използва свързания публичен ключ, за да провери дали сървърът е законният собственик на двойката ключове.

TLS 1.3 удостоверяване чрез ръкостискане

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

RSA (само подпис),
Алгоритъм за цифров подпис с елиптична крива (ECDSA),
Алгоритъм за цифров подпис на Едуардс (EdDSA).

За разлика от ръкостискането на TLS 1.2, частта за удостоверяване на ръкостискането на TLS 1.3 не е свързана със самия обмен на ключове. По-скоро се обработва паралелно с обмена на ключове и удостоверяването на съобщенията.

Вместо да изпълнява симетричен MAC за проверка на целостта на ръкостискането, сървърът подписва целия хеш за декриптиране, когато връща „Server Hello“ със своята част от публичния ключ.

Клиентът получава цялата информация, изпратена с "Server Hello" и извършва стандартна серия от проверки за удостоверяване на SSL/TLS сертификат. Това включва проверка на подписа върху сертификата и след това проверка дали подписът, който е добавен към хеша за декриптиране, съвпада.

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

Обмен на ключове в TLS ръкостискане

Ако подчертаете основната идея на този раздел, тя ще звучи така:

RSA улеснява обмена на ключове, като позволява на клиента да криптира споделената тайна и да я изпрати на сървъра, където се използва за изчисляване на съответния сесиен ключ. Обменът на DH ключ всъщност изобщо не изисква обмен на публичен ключ, по-скоро двете страни създават ключ заедно.

Ако сега това звучи малко абстрактно, до края на този раздел всичко трябва да стане ясно.

RSA обмен на ключове

Наричането му RSA обмен на ключове всъщност е погрешно. Всъщност това е RSA криптиране. RSA използва асиметрично криптиране, за да генерира сесийния ключ. За разлика от DH, двойката публичен/частен ключ играе голяма роля.

Ето как става:

хИ г
Клиентът генерира pre-master secret(a) и след това използва публичния ключ на сървъра, за да го шифрова и изпрати на сървъра.
Сървърът дешифрира pre-master secretсъс съответния частен ключ. Сега и двете страни имат и трите входни променливи и ги смесват с някои псевдослучайни функции (PRF), за да създадат главен ключ.
И двете страни смесват главния ключ с още повече PRF и в крайна сметка получават съвпадащи сесийни ключове.

DH обмен на ключове

Ето как работи ECDH:

Клиентът и сървърът обменят две прости числа ( хИ г), които се наричат произволни числа.
Едната страна избира извикан таен номер pre-master secret(а) и изчислява: x a mod y. След това изпраща резултата (A) на друг участник.
Другата страна прави същото, избирайки своите pre-master secret(b) и изчислява x b mod yи след това изпраща обратно своята стойност (B).
И двете страни завършват тази част, като приемат дадените стойности и повтарят операцията. Човек изчислява b a mod y, другият изчислява a b mod y.

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

TLS 1.2 ръкостискане за DH

Сега, след като видяхме как DH се различава от RSA, нека да разгледаме как изглежда базираното на DH ръкостискане TLS 1.2.

Отново има много прилики между двата подхода. Ще използваме ECDHE за обмен на ключове и ECDSA за удостоверяване.

Както при RSA, клиентът започва със съобщение "Клиент Здравейте", което включва списък от набори от шифри, както и случаен клиентски номер.
Сървърът отговаря със своето съобщение „Здравей на сървъра“, което включва избрания набор от шифри и произволното число на сървъра.
Сървърът изпраща своя SSL сертификат. Както при RSA TLS ръкостискането, клиентът ще извърши серия от проверки за удостоверяване на сертификата, но тъй като самият DH не може да удостовери сървъра, е необходим допълнителен механизъм.
За удостоверяване сървърът взема произволните числа на клиента и сървъра, както и DH параметъра, който ще се използва за изчисляване на ключа на сесията, и ги криптира със своя частен ключ. Резултатът ще действа като цифров подпис: клиентът използва публичния ключ, за да провери подписа и че сървърът е законният собственик на двойката ключове и ще отговори със своя собствена DH опция.
Сървърът завършва тази фаза със съобщение „Server Hello Done“.
За разлика от RSA, клиентът не трябва да изпраща пред-главната тайна на сървъра, използвайки асиметрично криптиране, вместо това клиентът и сървърът използват DH параметрите, които са обменили по-рано, за да получат пред-главната тайна. След това всеки използва предшестващата главна тайна, която току-що е изчислил, за да получи същия сесиен ключ.
Клиентът изпраща съобщение "Change Cipher Spec", за да информира другата страна, че е преминал към криптиране.
Клиентът изпраща последно съобщение „Готово“, за да покаже, че е завършил своята част от ръкостискането.
По същия начин сървърът изпраща съобщение "Change Cipher Spec".
Ръкостискането завършва със съобщение „Готово“ от сървъра.

Предимства на DHE пред RSA

Има две основни причини, поради които криптографската общност предпочита да използва DHE пред RSA: перфектна предна секретност и известни уязвимости.

Перфектна предна секретност

По-рано може би сте се чудили какво означава думата „ефемерен“ в края на DHE и ECDHE. Ефемерен буквално означава „краткотраен“. И може да помогне за разбирането на Perfect Forward Secrecy (PFS), което е характеристика на някои протоколи за обмен на ключове. PFS гарантира, че сесийните ключове, обменени между страните, не могат да бъдат компрометирани, дори ако частният ключ на сертификата е компрометиран. С други думи, той защитава предишни сесии от извличане и дешифриране. PFS получи най-висок приоритет след откриването на грешката Heartbleed. Това е основният компонент на TLS 1.3.

Уязвимост при обмен на RSA ключове

Има уязвимости, които биха могли да използват подплънките ( подплата), използвани по време на обмен на ключове в по-стари версии на RSA (PKCS #1 1.5). Това е един от аспектите на криптирането. При RSA предшестващата главна тайна трябва да бъде криптирана с публичния ключ и декриптирана с частния ключ. Но когато тази по-малка предглавна тайна се побере в по-големия публичен ключ, тя трябва да бъде подплатена. В повечето случаи, ако се опитате да познаете подложката и изпратите фалшива заявка до сървъра, ще го сбъркате и той ще разпознае несъответствието и ще го филтрира. Но има голям шанс да изпратите достатъчно заявки до сървъра, за да познаете правилната подложка. След това сървърът ще изпрати погрешно завършено съобщение, което на свой ред ще стесни възможната стойност на предварително главната тайна. Това ще позволи на атакуващия да изчисли и компрометира ключа.

Ето защо RSA беше премахнат в полза на DHE в TLS 1.3.

Обмен на ключове в TLS 1.3 ръкостискане

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

RSA не беше единствената схема за обмен на ключове, която беше премахната в TLS 1.3. Неефимерните схеми на Дифи-Хелман също са елиминирани, както и списък с недостатъчно сигурни параметри на Дифи-Хелман.

Какво се има предвид под недостатъчно сигурни параметри? Без да навлизаме в математиката, сложността на Diffie-Hellman и повечето криптосистеми с публичен ключ е сложността на решаването на проблеми с дискретни логаритми. Криптосистемата трябва да е достатъчно сложна, за да изчисли, ако входните параметри (произволни числа на клиента и сървъра) са неизвестни, в противен случай цялата схема ще бъде безполезна. Схемите на Diffie-Hellman, които не можеха да предоставят достатъчно големи параметри, бяха отхвърлени в TLS 1.3.

В началото на ръкостискане на TLS 1.3, знаейки, че ще се използва схема за споразумение за DHE ключ, клиентът включва своята част от публичния ключ въз основа на планираната схема за обмен на ключове в своето Client Hello съобщение.
Сървърът получава тази информация и, ако клиентът е правилен, връща своята част от публичния ключ в „Server Hello“.
Клиентът и сървърът изчисляват ключа на сесията.

Това е много подобно на това, което се случва с DH в ръкостискането на TLS 1.2, с изключение на това, че обменът на ключове се случва по-рано в TLS 1.3.

Вместо заключение

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

Поне докато нещо не се обърка.

Съгласно изискванията на руското законодателство, само използването на TLS връзки, установени от руски криптографски алгоритмиГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001. Ето защо, ако трябва да използвате сайтове, които използват криптиране според GOST алгоритми, трябва да инсталирате програмата " CryptoPro CSP» .

В операционните зали Windows системиизползва се програмата CryptoPro CSP - набор от криптографски помощни програми за генериране електронен подпис, работа със сертификати

За да инсталирате CryptoPro CSP, използвайте материалите от официалния уебсайт:

След инсталиране на CryptoPro CSP браузърпроверява съществуването и работата на тази програма.

Сайтове, изискващи GOST TLS криптиране

Ако даден сайт поиска GOST TLS криптиране, браузърът проверява дали CryptoPro CSP е инсталиран. Ако програмата е инсталирана, контролът се прехвърля към нея.

Примери за сайтове, изискващи криптиране: www.gosuslugi.ru , сайтове в домейна .gov.ru, .kamgov.ru , .nalog.ru .

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

Всички наши разсъждения се основават на факта, че използвате Windows XP или по-нова версия (Vista, 7 или 8), които имат инсталирани всички подходящи актуализации и корекции. Сега още едно условие: говорим за най-новите версии на браузърите днес, а не за „сферичен Ognelis във вакуум“.

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

И теорията ни казва, че въпреки това Internet Explorerтъй като версия 8 поддържа TLS 1.1 и 1.2, под Windows XP и Vista няма да го принуждаваме да го прави. Щракнете върху: Инструменти / Опции за интернет / Разширени и в секцията „Сигурност“ намираме: SSL 2.0, SSL 3.0, TLS 1.0 ... намерихте ли нещо друго? Поздравления, ще имате TLS 1.1/1.2! Не е намерен - имате Windows XP или Vista, а в Редмънд ви смятат за изостанал.

И така, премахваме отметките от всички SSL, поставяме ги на всички налични TLS. Ако е наличен само TLS 1.0, така да бъде, ако има по-актуални версии, по-добре е да изберете само тях и да премахнете отметката от TLS 1.0 (и да не се изненадвате по-късно, че някои сайтове не се отварят през HTTPS) . След това щракнете върху бутоните "Прилагане", "ОК".

С Opera е по-лесно - тя организира истински банкет за нас от различни версиипротоколи: Инструменти/Общи настройки/Разширени/Сигурност/Протоколи за сигурност. какво виждаме Целият комплект, от който оставяме отметките само за TLS 1.1 и TLS 1.2, след което натискаме бутона "Подробности" и там премахваме отметките на всички редове, с изключение на тези, които започват с "256 bit AES" - те са на самия край. В началото на списъка има ред "256 bit AES ( Анонимен DH/SHA-256), премахнете отметката и от него. Щракнете върху „OK“ и се насладете на сигурността.

Opera обаче има едно странно свойство: ако TLS 1.0 е активиран, тогава, ако е необходимо да се установи защитена връзка, тя незабавно използва тази конкретна версия на протокола, независимо дали сайтът поддържа по-нови. Като, защо напрежение - и всичко е наред, всичко е защитено. Когато активирате само TLS 1.1 и 1.2, той първо ще се опита да използва по-разширена версия и само ако не се поддържа от сайта, браузърът ще премине към версия 1.1.

Но сферичният Ognelis Firefox изобщо няма да ни хареса: Инструменти / Настройки / Разширени / Шифроване: всичко, което можем да направим, е да изключим SSL, TLS е наличен само във версия 1.0, няма какво да правим - оставяме го с отметка.

Лошото обаче се научава в сравнение: Chrome и Safari изобщо не съдържат настройки кой протокол за криптиране да се използва. Доколкото знаем, Safari не поддържа TLS версии, по-нови от 1.0 във версии под Windows, и тъй като пускането на нови версии за тази операционна система е преустановено, няма да го направи.

Chrome, доколкото знаем, поддържа TLS 1.1, но, както в случая на Safari, не можем да откажем да използваме SSL. Деактивирането на TLS 1.0 в Chrome също не е начин. Но с реалното използване на TLS 1.1 - голям въпрос: първо беше включен, след това изключен поради проблеми в работата и, доколкото може да се каже, все още не е включен отново. Тоест, поддръжката изглежда е налице, но тя е, така да се каже, изключена и няма начин да я включите отново на самия потребител. Същата история с Firefox - поддръжката на TLS 1.1 в него всъщност е, но все още не е достъпна за потребителя.

Резюме от горното многописмо. Каква е опасността от използването на остарели версии на протоколи за криптиране? Фактът, че някой друг ще влезе във вашата защитена връзка със сайта и ще получи достъп до цялата информация "там" и "там". На практика ще стане пълен достъпкъм кутията електронна поща, сметка в системата клиент-банка и др.

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

В противен случай няма избор: само Opera и само TLS 1.2 (TLS 1.1 е само подобрение на TLS 1.0, частично наследяващо проблемите му със сигурността). Любимите ни сайтове обаче може да не поддържат TLS 1.2 :(

TLS е наследник на SSL, протокол, който осигурява сигурна и сигурна връзкамежду възли в интернет. Използва се при разработването на различни клиенти, включително браузъри и приложения клиент-сървър. Какво е TLS в Internet Explorer?

Малко за технологията

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

По принцип в организацията си те използват вградения браузър. В някои случаи - Mozilla Firefox.

Активиране или деактивиране на протокол

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

2.Отидете в секцията "Опции за интернет" и отворете блока "Разширени".

3. Поставете отметка в квадратчетата до „Използване на TLS 1.1 и TLS 1.2“.

4. Щракнете върху OK, за да запазите промени. Ако искате да деактивирате протоколите, което е силно обезкуражено, особено ако използвате интернет банкиране, премахнете отметките от същите елементи.

Каква е разликата между 1.0 и 1.1 и 1.2? 1.1 е само леко подобрена версия на TLS 1.0, която частично наследи своите недостатъци. 1.2 е най-сигурната версия на протокола. От друга страна, не всички сайтове могат да се отварят с активирана тази версия на протокола.

Както знаете, месинджърът на Skype е пряко свързан с Internet Explorer като компонент на Windows. Ако не сте проверили TLS протокола в настройките, тогава може да има проблеми със Skype. Програмата просто няма да може да се свърже със сървъра.

Ако поддръжката на TLS е деактивирана в настройките на Internet Explorer, всички свързани с мрежата функции на програмата няма да работят. Освен това безопасността на вашите данни зависи от тази технология. Не го пренебрегвайте, ако го направите финансови операциив този браузър (покупки в онлайн магазини, превод на пари чрез интернет банкиране или електронен портфейл и др.).