У пачатку года, у справаздачы аб праблемах і даступнасці інтэрнэту за 2018-2019 , Што распаўсюджванне TLS 1.3 непазбежна. Некаторы час таму мы самі разгарнулі версію 1.3/XNUMX пратакола Transport Layer Security і, пасля збору і аналізу дадзеных, нарэшце, гатовыя распавесці аб асаблівасцях гэтага пераходу.
Старшыні працоўнай групы IETF TLS :
"Каротка, TLS 1.3 павінен даць падмурак больш бяспечнага і эфектыўнага Інтэрнэту на наступныя 20 гадоў".
Распрацоўка заняла доўгія 10 гадоў. Мы ў Qrator Labs, разам са ўсёй астатняй галіной, уважліва сачылі за працэсам стварэння пратаколу ад першапачатковага праекту. За гэты час спатрэбілася напісаць 28 паслядоўных версій чарнавіка для таго, каб у канчатковым рахунку ў 2019 годзе святло ўбачыла збалансаваны і зручны ў разгортванні пратакол. Актыўная падтрымка TLS 1.3 рынкам ужо відавочная: укараненне праверанага і надзейнага пратакола бяспекі адпавядае патрабаванням часу.
Па словах Эрыка Рэскорлы (тэхнічнага дырэктара Firefox і адзінага аўтара TLS 1.3) :
"Гэта поўная замена TLS 1.2, якая выкарыстоўвае тыя ж ключы і сертыфікаты, таму кліент і сервер могуць аўтаматычна мець зносіны па TLS 1.3, калі абодва яго падтрымліваюць", – сказаў ён. "Ужо ёсць добрая падтрымка на ўзроўні бібліятэк, а Chrome і Firefox па змаўчанні ўключаюць TLS 1.3".
Паралельна ў працоўнай групе IETF TLS заканчваецца , які аб'яўляе старыя версіі TLS (за выключэннем толькі TLS 1.2) састарэлымі і непрыдатнымі для выкарыстання. Верагодней за ўсё, фінальны RFC убачыць свет да канца лета. Гэта яшчэ адзін сігнал IT-індустрыі: абнаўленне пратаколаў шыфравання не варта адкладаць.
Спіс бягучых рэалізацый TLS 1.3 даступны на Github для ўсіх, хто шукае найбольш прыдатную бібліятэку: . Відавочна, што прыняцце і падтрымка абноўленага пратакола будзе - і ўжо ідзе - хуткімі крокамі. Разуменне таго, наколькі фундаментальным стала шыфраванне ў сучасным свеце, распаўсюдзілася дастаткова шырока.
Што змянілася ў параўнанні з TLS 1.2?
З :
Як TLS 1.3 робіць свет лепш?
TLS 1.3 уключае пэўныя тэхнічныя перавагі - такія, як спрошчаны працэс поціску рукі (handshake) для ўсталявання бяспечнага злучэння - а таксама дазваляе кліентам хутчэй аднаўляць сесіі з серверамі. Гэтыя меры закліканы паменшыць затрымку на ўсталёўку злучэння і колькасць няўдалых злучэнняў на слабых каналах, якія часта выкарыстоўваюцца ў якасці апраўдання для падавання толькі нешыфраваных HTTP-злучэнняў.
Не менш важна і тое, што ўхіленая падтрымка некалькіх састарэлых і небяспечных алгарытмаў шыфравання і хэшаванні, якія ўсё яшчэ дазволена (хоць і не рэкамендуецца) выкарыстоўваць з больш раннімі версіямі TLS, уключаючы SHA-1, MD5, DES, 3DES і AES-CBC, адначасова дадаючы падтрымку новых набораў шыфраў. Іншыя ўдасканаленні ўключаюць у сябе больш зашыфраваных элементаў поціску рукі (напрыклад, зараз зашыфраваны абмен інфармацыяй аб сертыфікаце), каб паменшыць аб'ём падказак патэнцыйнаму перахопніку трафіку, а таксама паляпшэнні ў forward secrecy пры выкарыстанні пэўных рэжымаў абмену ключамі, так што сувязь у любы момант часу павінна заставацца бяспечнай, нават калі алгарытмы, якія выкарыстоўваюцца для яе шыфравання, будуць скампраметаваныя ў будучыні».
Распрацоўка сучасных пратаколаў і DDoS
Як вы, магчыма, ужо чыталі, падчас распрацоўкі пратакола , у працоўнай групе IETF TLS . Ужо зараз відавочна, што асобным прадпрыемствам (уключаючы фінансавыя ўстановы) давядзецца змяніць спосаб забеспячэння бяспекі ўласнай сеткі для таго, каб прыстасавацца да цяпер убудаванай у пратакол. .
Прычыны, па якіх гэта можа спатрэбіцца, выкладзены ў дакуменце, . У 20-старонкавай паперы згадваецца некалькі прыкладаў, калі прадпрыемства можа захацець выканаць расшыфроўку out-of-band трафіку (што PFS рабіць не дазваляе), у мэтах маніторынгу, адпаведнасці нарматыўным патрабаванням або забеспячэнні абароны ад DDoS-нападаў на прыкладным узроўні (L7).
Хоць мы вызначана не гатовыя разважаць аб нарматыўных патрабаваннях, наш уласны прадукт для нейтралізацыі прыкладных DDoS-нападаў (уключаючы рашэнне, адчувальнай і/або канфідэнцыйнай інфармацыі) быў створаны ў 2012 годзе з улікам PFS, таму нашым кліентам і партнёрам ніякіх змен у іх інфраструктуры пасля абнаўлення версіі TLS на баку сервера вырабляць не запатрабавалася.
Таксама, за час, які прайшоў з моманту ўкаранення, ніякіх праблем, звязаных з транспартным шыфраваннем, выяўлена не было. Афіцыйна: TLS 1.3 гатовы да выкарыстання ў прадакшэне.
Зрэшты, ёсць усё ж праблема, звязаная з распрацоўкай пратаколаў наступнага пакалення. Яна заключаецца ў тым, што звычайна прагрэс у развіцці пратаколаў у IETF моцна залежыць ад вынікаў навуковых даследаванняў, а стан акадэмічных даследаванняў у галіне нейтралізацыі размеркаваных нападаў на адмову ў абслугоўванні - вельмі жаласнае.
Так, добрым прыкладам можа выступаць чарнавіка IETF "QUIC Manageability" ("Кіраванне QUIC"), які з'яўляецца часткай будучага набору пратаколаў QUIC: у ім гаворыцца, што "сучасныя метады выяўлення і нейтралізацыі [DDoS-атак] звычайна ўключаюць пасіўнае вымярэнне з выкарыстаннем дадзеных аб сеткавых струменях".
Апошняе, насамрэч, вельмі рэдка сустракаецца ў рэальных карпаратыўных асяроддзях (і толькі збольшага дастасавальна да інтэрнэт-правайдэраў), і ў любым выпадку ці наўрад з'яўляецца «агульным выпадкам» у рэальным міры — але ўвесь час фігуруе ў навуковых публікацыях, звычайна не падмацаваных тэставаннем усяго спектру патэнцыйных DDoS-нападаў, уключаючы напады прыкладнога ўзроўня. Апошнія, у сілу хаця б сусветнага разгортвання TLS, відавочна ніяк не могуць быць выяўлены пасіўным вымярэннем сеткавых пакетаў і струменяў.
Аналагічна, мы пакуль не ведаем, як вытворцы абсталявання для нейтралізацыі DDoS будуць адаптоўвацца да рэалій TLS 1.3. З-за тэхнічнай складанасці падтрымкі out-of-band пратаколу, можа спатрэбіцца некаторы час на апгрэйд.
Пастаноўка правільных мэт для накіравання навуковых даследаванняў - сур'ёзная задача для правайдэраў паслуг нейтралізацыі DDoS. Адна з абласцей, у якой можна пачаць развіццё - у IRTF, дзе даследчыкі могуць супрацоўнічаць з галіной для ўдакладнення ўласных ведаў у праблемнай галіны і пошуку новых напрамкаў даследаванняў. Мы таксама гатовы цёпла павітаць усіх даследчыкаў, калі такія знойдуцца — з намі можна звязацца па пытаннях або прапановах, звязаных DDoS-даследаваннямі або з даследчай групай SMART, па адрасе
Крыніца: habr.com