Komence de la jaro, en raporto pri interretaj problemoj kaj alirebleco por 2018-2019 ke la disvastiĝo de TLS 1.3 estas neevitebla. Antaŭ iom da tempo, ni mem deplojis version 1.3 de la protokolo pri Transporta Tavolo kaj, post kolekti kaj analizi datumojn, ni finfine pretas paroli pri la funkcioj de ĉi tiu transiro.
IETF TLS Laborgrupo-Prezidoj :
"Mallonge, TLS 1.3 devus provizi la fundamenton por pli sekura kaj efika Interreto dum la venontaj 20 jaroj."
Disvolviĝo daŭris 10 longajn jarojn. Ni ĉe Qrator Labs, kune kun la resto de la industrio, atente sekvis la protokolan kreadon de la komenca skizo. Dum ĉi tiu tempo, estis necese verki 28 sinsekvajn versiojn de la skizo por finfine vidi la lumon de ekvilibra kaj facile disfaldebla protokolo en 2019. La aktiva merkatsubteno por TLS 1.3 jam estas evidenta: la efektivigo de provita kaj fidinda sekureca protokolo renkontas la bezonojn de la tempoj.
Laŭ Eric Rescorla (Firefox CTO kaj sola aŭtoro de TLS 1.3) :
"Ĉi tio estas kompleta anstataŭaĵo por TLS 1.2, uzante la samajn ŝlosilojn kaj atestojn, do la kliento kaj servilo povas aŭtomate komuniki per TLS 1.3 se ili ambaŭ subtenas ĝin," li diris. "Ekzistas jam bona subteno ĉe la biblioteka nivelo, kaj Chrome kaj Fajrovulpo ebligas TLS 1.3 defaŭlte."
Paralele, TLS finiĝas en la laborgrupo de IETF , deklarante pli malnovajn versiojn de TLS (ekskludante nur TLS 1.2) malnoviĝintaj kaj neuzeblaj. Plej verŝajne, la fina RFC estos publikigita antaŭ la fino de la somero. Ĉi tio estas alia signalo al la IT-industrio: ĝisdatigado de ĉifradaj protokoloj ne devus esti prokrastita.
Listo de aktualaj TLS 1.3-efektivigoj haveblas ĉe Github por ĉiuj, kiuj serĉas la plej taŭgan bibliotekon: . Estas klare, ke adopto kaj subteno por la ĝisdatigita protokolo estos—kaj jam—progresas rapide. Kompreno pri kiel fundamenta ĉifrado fariĝis en la moderna mondo sufiĉe vaste disvastiĝis.
Kio ŝanĝiĝis ekde TLS 1.2?
De :
"Kiel TLS 1.3 faras la mondon pli bona loko?
TLS 1.3 inkluzivas iujn teknikajn avantaĝojn - kiel simpligitan manpremon por establi sekuran konekton - kaj ankaŭ permesas al klientoj pli rapide rekomenci sesiojn kun serviloj. Ĉi tiuj mezuroj celas redukti latentecon de konekto-agordo kaj konekto-malsukcesoj sur malfortaj ligiloj, kiuj ofte estas uzataj kiel pravigo por provizi nur neĉifritajn HTTP-ligojn.
Same grave, ĝi forigas subtenon por pluraj heredaj kaj nesekuraj ĉifrado kaj hashing algoritmoj kiuj ankoraŭ estas permesitaj (kvankam ne rekomenditaj) por uzi kun pli fruaj versioj de TLS, inkluzive de SHA-1, MD5, DES, 3DES, kaj AES-CBC. aldonante subtenon por novaj ĉifroj. Aliaj plibonigoj inkludas pli ĉifritajn elementojn de la manpremo (ekzemple, la interŝanĝo de atestilinformoj nun estas ĉifrita) por redukti la kvanton de indicoj al ebla trafika subaŭskultanto, same kiel plibonigoj por plusendi sekretecon dum uzado de certaj ŝlosilaj interŝanĝoreĝimoj tiel ke komunikado ĉiam devas resti sekura eĉ se la algoritmoj uzataj por ĉifri ĝin estas endanĝerigitaj en la estonteco."
Evoluo de modernaj protokoloj kaj DDoS
Kiel vi eble jam legis, dum la disvolviĝo de la protokolo , en la laborgrupo de IETF TLS . Nun estas klare, ke individuaj entreprenoj (inkluzive de financaj institucioj) devos ŝanĝi la manieron kiel ili sekurigas sian propran reton por alĝustigi la nun enkonstruitan de la protokolo. .
La kialoj, kial tio povas esti postulata, estas prezentitaj en la dokumento, . La 20-paĝa papero mencias plurajn ekzemplojn kie entrepreno eble volas malĉifri ekster-de-bandan trafikon (kiun PFS ne permesas) por monitorado, plenumado aŭ aplikaĵa tavolo (L7) DDoS-protektoceloj.
Kvankam ni certe ne pretas konjekti pri reguligaj postuloj, nia proprieta aplikaĵa DDoS mildiga produkto (inkluzive de solvo sentemaj kaj/aŭ konfidencaj informoj) estis kreita en 2012 konsiderante PFS, do niaj klientoj kaj partneroj ne bezonis fari ajnajn ŝanĝojn al sia infrastrukturo post ĝisdatigo de la TLS-versio ĉe la servilo.
Ankaŭ, ekde la efektivigo, neniuj problemoj ligitaj al transporta ĉifrado estis identigitaj. Ĝi estas oficiala: TLS 1.3 estas preta por produktado.
Tamen, ekzistas ankoraŭ problemo asociita kun la evoluo de venontgeneraciaj protokoloj. La problemo estas, ke protokola progreso en la IETF estas tipe tre dependa de akademia esplorado, kaj la stato de akademia esplorado en la kampo de mildigado de distribuitaj ne-de-servo-atakoj estas malgaja.
Do, bona ekzemplo estus La IETF-skizo "QUIC Manageability", parto de la venonta QUIC-protokolo-serio, deklaras, ke "modernaj metodoj por detekti kaj mildigi [DDoS-atakojn] kutime implikas pasivan mezuradon uzante retfluajn datumojn."
Ĉi-lasta estas, fakte, tre malofta en realaj entreprenaj medioj (kaj nur parte aplikebla al ISP-oj), kaj ĉiukaze verŝajne ne estos "ĝenerala kazo" en la reala mondo - sed aperas konstante en sciencaj publikaĵoj, kutime ne subtenataj. provante la tutan spektron de eblaj DDoS-atakoj, inkluzive de aplikaj nivelaj atakoj. Ĉi-lasta, pro almenaŭ la tutmonda deplojo de TLS, evidente ne povas esti detektita per pasiva mezurado de retpakoj kaj fluoj.
Same, ni ankoraŭ ne scias kiel DDoS mildiga aparataro vendistoj adaptos al la realaĵoj de TLS 1.3. Pro la teknika komplekseco de subtenado de la ekster-grupa protokolo, la ĝisdatigo povas daŭri iom da tempo.
Fiksi la ĝustajn celojn por gvidi esploradon estas grava defio por provizantoj de DDoS-mildigaj servoj. Unu areo kie evoluo povas komenci estas ĉe la IRTF, kie esploristoj povas kunlabori kun industrio por rafini sian propran scion pri malfacila industrio kaj esplori novajn esplorvojojn. Ni ankaŭ bonvenigas ĉiujn esploristojn, se ekzistas - ni povas esti kontaktitaj kun demandoj aŭ sugestoj rilataj al DDoS-esplorado aŭ la SMART-esplorgrupo ĉe
fonto: www.habr.com