Lumabas lang ang balita na ang Apple, Cloudflare, Mabilis, at Mozilla ay nakikipagtulungan sa pagpapahusay ng pag-encrypt ng mekanismo ng Identification Server na mekanismo ng HTTPS sa IETF 102 Hackathon tulad ng ipinahiwatig ng isang tweet mula sa Nick Sullivan ng Cloudflare. Ang tweet ay binati ang koponan ng halo mula sa apat na higanteng tech sa pamamagitan ng pagsasabing 'Galing ng trabaho' at pagbabahagi doon sa ilalim ng mga link sa mga gumaganang server sa esni.examp1e.net at cloudflare-esni.com .
Kahanga-hanga ang trabaho sa IETF 102 hackathon ng naka-encrypt na koponan ng SNI na binubuo ng mga tao mula sa @Cloudflare @tapat @mozilla at @apple . Mayroon na ngayong pagpapatupad sa BoringSSL, NSS at mga picotl.
Ang mga nagtatrabaho server ay live sa https://t.co/sLI9xLRjlK at https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) Hulyo 15, 2018
Ang IETF Hackathon ay isang platform na inaanyayahan ang mga batang developer at taong mahilig sa tech na sumali sa mga ulo sa pagbubuo ng mga solusyon para sa mga isyung nauugnay sa tech na kinakaharap ng karaniwang gumagamit ngayon. Ang mga kaganapan ay malayang sumali, bukas sa lahat, at hinihimok nila ang pagtutulungan kumpara sa kumpetisyon. Ang IETF Hackathon ngayong taon ay ginanap sa Montreal noong 14ikaat 15ikang Hulyo. Ang pinakatanyag na tagumpay na lumabas dito, tila, ay ang pag-encrypt ng Transport Layer Security (TLS) Server Name Indication (SNI), isang problema na sumakit sa mga developer sa huling dekada, isa na ang mga miyembro ng Apple, Cloudflare, Mabilis , at ang Mozilla ay nagpanukala ngayon ng isang solusyon sa.
Kaganapan ng IETF Hackathon. IETF
Nagkaroon ng isang malinaw na pandaigdigang paglilipat mula sa Hyper Text Transfer Protocol (HTTP) sa Transport Layer Security Server Name Indication Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) sa huling dekada at kalahati. Ang problema na tumaas sa pag-optimize ng TLS SNI HTTPS system ay ang kakayahan ng hacker na gamitin ang SNI laban sa layunin nito upang tumugma sa paglilipat ng data para sa decryption sa paglaon.
Bago ang pagbuo ng SNI, mahirap upang maitaguyod ang mga ligtas na koneksyon sa maraming mga virtual server gamit ang parehong unang pagkakamay ng client. Kapag nakipag-ugnay ang isang IP address sa isang server, ipinagpalitan ng dalawa ang 'hellos,' ipinadala ng server ang mga sertipiko nito, ipinadala ng computer ang susi ng kliyente nito, ipinagpalitan ng dalawa ang mga 'ChangeCipherSpec' na utos at pagkatapos ay natapos ang pakikipag-ugnay habang itinatag ang isang koneksyon. Maaaring madali itong tunog sa paraang nasabi lamang ngunit ang proseso ay nagsasangkot ng maraming mga palitan at tugon na madaling napamamahalaang maging lubos na may problema habang tumaas ang bilang ng mga server. Kung ang lahat ng mga site ay gumagamit ng parehong mga sertipiko, kung gayon hindi ito gaanong isang problema, ngunit sa kasamaang palad ay bihira iyon. Kapag maraming mga site ang nagpapadala ng iba't ibang mga sertipiko pabalik-balik, nahirapan para sa server na matukoy kung aling sertipiko ang hinahanap ng computer at sa kumplikadong web ng mga palitan, naging mahirap na makilala kung sino ang nagpadala kung ano at kailan, sa gayong paraan natatapos ang buong aktibidad na may isang babalang mensahe sa kabuuan.
Ang TLS SNI ay ipinakilala noong Hunyo ng 2003 sa pamamagitan ng isang IETF summit at ang layunin na hinatid nito, sa isang kahulugan, ay upang lumikha ng mga name tag para sa mga computer at serbisyong kasangkot sa web exchange. Ginawa nito ang proseso ng exchange ng hello ng server-client na mas diretso pasulong dahil nagawang magbigay ng server ang eksaktong mga sertipiko na kinakailangan at nagawa ng dalawa na magkaroon ng kanilang sariling palitan ng pag-uusap nang hindi naguguluhan kung sino ang nagsabi kung ano. Ito ay tulad ng pagkakaroon ng mga pangalan ng contact para sa mga pakikipag-chat at hindi nalilito kung saan nanggagaling ang mga mensahe, at kakayahang tumugon din sa bawat query nang naaangkop, na nagbibigay ng tamang mga dokumento sa kung aling computer ang nangangailangan nito. Ang kahulugan ng SNI na ito ang eksaktong nag-udyok sa pinakamalaking problema sa pamamaraang ito ng pag-optimize ng proseso ng palitan.
Ang pakikibaka na kinaharap ng maraming mga kumpanya sa paglipat sa HTTPS ay ang pagbagay ng maraming mga sertipiko sa format na SNI na may mga indibidwal na IP address upang maisagawa ang mga kahilingan para sa bawat sertipiko. Ang ginawa ng TLS para sa kanila ay ginagawang mas simple upang makabuo ng mga sertipiko upang tumugon sa mga naturang kahilingan at kung ano pa ang ginawa ng SNI ay tinanggal ang pangangailangan para sa isinapersonal na mga IP address ng sertipiko ng IP sa pamamagitan ng paghagis sa isang buong sistema ng pagkakakilanlan sa buong network ng internet. Ang sumama sa pag-upgrade ng siglo ay ang katotohanang pinapayagan nito ang mga hacker na gamitin ang itinatag na 'mga pangalan ng contact' upang subaybayan at i-shade ang paglipat ng data at kunin ang impormasyong kailangan nila upang ma-decrypt sa susunod na yugto.
Bagaman pinapayagan ng TLS na maipadala pabalik-balik ang data sa isang naka-encrypt na channel, sa pagtiyak ng SNI na naabot nito ang tamang patutunguhan, ang huli ay nagbigay din ng mga paraan para sa mga hacker na subaybayan ang aktibidad sa online at maitugma ito sa pinagmulan nito sa pamamagitan ng pagsunod sa mga kahilingan sa DNS, mga IP address , at mga stream ng data. Bagaman ang mas mahigpit na mga patakaran sa pag-coding ng SNI ay naipatupad sa pamamagitan ng pagpasa ng impormasyon ng DNS sa pamamagitan din ng TLS channel, ang isang maliit na window ay mananatili para sa mga hacker upang magamit ito bilang isang paraan ng pagkakakilanlan na sundin ang piraso ng impormasyon na nais nilang kunin at ihiwalay ito para sa decryption Ang mga kumplikadong server na nakikipag-usap sa mas malawak na trapiko ng naka-encrypt na data ng TLS ay gumagamit ng simpleng teksto na SNI upang maipadala ang komunikasyon sa paligid ng kanilang mga server at ito ang nagpapadali sa mga hacker na kilalanin ang mga channel at stream ng impormasyon na nais nilang sundin. Kapag ang isang hacker ay nagawang kunin ang impormasyon ng SNI ng data ng interes, siya ay nakapag-set up ng isang faux replay ng utos sa isang hiwalay na koneksyon ng TLS sa server, nagpapadala ng impormasyon sa SNI na ninakaw at nakuha ang impormasyon na ay naiugnay dito. Mayroong maraming mga pagtatangka upang malutas ang isyu ng SNI na ito sa nakaraan ngunit karamihan ay laban sa prinsipyo ng pagiging simple na pinapatakbo ng SNI upang gawin itong isang maginhawang pamamaraan ng pagkakakilanlan para sa mga server.
Bumalik sa tuktok na unang nagtrabaho upang maitaguyod ang pamamaraang ito, ang mga kalahok mula sa apat na higanteng tech ay bumalik sa kumperensya sa Montreal upang makabuo ng isang pag-encrypt para sa TLS SNI sapagkat sa kabila ng mas mahusay na kahusayan sa multi HTTPS adjoining system, ang seguridad ay nananatiling isang alalahanin lamang kagaya ng dati.
Upang maitago ang SNI sa TLS, ang isang 'Nakatagong Serbisyo' ay dapat itago sa ilalim ng pagpapakita ng isang 'Fronting Service' na maaaring makita ng hacker. Nang hindi direktang mapagmamasdan ang nakatagong serbisyo, ang hacker ay maliligaw ng harapan na pagkukubli na itinatago ito sa ilalim ng payak na teksto nang hindi nakilala ang napapailalim na lihim na mga parameter ng serbisyo na ginamit upang maipasa ang naka-encrypt na data. Habang sinusunod ng tagamasid ang landas ng serbisyo sa harap, ang data ay aalisin mula sa sinusunod na channel dahil ito ay nai-redirect sa inilaan nitong nakatagong serbisyo kung saan mawawala ang landas ng hacker. Dahil mailantad din ang server sa fronting service, habang papunta roon ang data, ipapadala ang isang pangalawang parallel na signal ng SNI sa fronting service upang i-redirect ang data patungo sa nakatagong serbisyo at sa proseso ng pagbabago ng direksyon na ito, mawala sa web ng server. Ang mekanismong ito ng mga dobleng tiket ay karagdagang binuo sa isang pinagsamang tiket sa ilalim ng parehong SNI. Bilang isang piraso ng data ay ipinadala sa server, gumagawa ang data ng isang nakikipagtulungan na muling direktor ng SNI at ang dalawang gawain na kasabay upang makuha ang naka-encrypt na data ng TLS kung saan ito kailangang puntahan. Nang hindi magagawang i-crack ang randomized fronting service na sumasakop sa parehong mga track ng SNI, hindi masusundan ng hacker ang landas ng data ngunit magagawa pa rin ng server na ikonekta ang dalawa at mai-decrypt ang nakatagong serbisyo bilang pangwakas na lokasyon ng data. Pinapayagan nito ang mga server na magpatuloy sa paggamit ng SNI upang ma-optimize ang kanilang paglipat ng data sa pag-encrypt ng TLS habang tinitiyak na ang mga hacker ay hindi maaaring samantalahin ang mekanismo ng SNI.
