Току-що се появиха новини, че Apple, Cloudflare, Fastly и Mozilla си сътрудничат за подобряване на криптирането на механизма за идентифициране на имена на сървъри на HTTPS на IETF 102 Hackathon, както е посочено от туит от Cloudflare’s Nick Sullivan. Tweet поздрави микс екипа от четирите технологични гиганта, като каза „Страхотна работа“ и сподели там под връзки към работещите сървъри в esni.examp1e.net и cloudflare-esni.com .
Страхотна работа на хакатона IETF 102 от шифрования екип на SNI, състоящ се от хора от @Cloudflare @бързо @mozilla и @apple . Вече има внедрения в BoringSSL, NSS и picotls.
Работещите сървъри са на живо в https://t.co/sLI9xLRjlK и https://t.co/AoC2SIlJ7N .
- Ник Съливан (@grittygrease) 15 юли 2018 г.
IETF Hackathon е платформа, която кани млади разработчици и технологични ентусиасти да се присъединят към главите в изготвянето на решения за проблеми, свързани с технологиите, с които се сблъскват днешните потребители. Събитията са свободни за присъединяване, отворени за всички и насърчават работата в екип за разлика от състезанието. Тазгодишният IETF Hackathon се проведе в Монреал на 14тии 15тиот юли. Изглежда, че най-изтъкнатото постижение е криптирането на Transport Layer Security (TLS) Server Name Indication Name (SNI), проблем, който измъчва разработчиците през последното десетилетие, който членовете на Apple, Cloudflare, Fastly и Mozilla вече предложиха решение за.
IETF Hackathon Събитие. IETF
През последното десетилетие и половина се наблюдава явна глобална промяна от протокола за прехвърляне на хипертекст (HTTP) към индикация на името на сървъра за защита на транспортния слой (TLS SNI HTTPS). The проблем това, което се издигна от оптимизирането на системата TLS SNI HTTPS, беше способността на хакера да използва SNI срещу целта си, за да съответства на прехвърлянето на данни за декриптиране по-късно.
Преди разработването на SNI беше трудно да се установят сигурни връзки към множество виртуални сървъри, като се използва едно и също първо ръкостискане на клиента. Когато един IP адрес взаимодейства с един сървър, двамата си разменят „здравей“, сървърът изпраща своите сертификати, компютърът изпраща своя клиентски ключ, двамата обменят команди „ChangeCipherSpec“ и след това взаимодействието приключва при установяване на връзка. Това може да звучи лесно по начина, по който току-що беше казано, но процесът включваше множество обмени и отговори, които лесно успяха да станат доста проблематични, тъй като броят на сървърите, с които се комуникираше, се увеличаваше. Ако всички сайтове са използвали едни и същи сертификати, това не е голям проблем, но за съжаление това е рядко. Когато множество сайтове изпращаха различни сертификати напред-назад, за сървъра беше трудно да определи кой сертификат търси компютърът и в сложната мрежа от борси стана трудно да се идентифицира кой какво и кога е изпратил, като по този начин прекратява цялата дейност с предупредително съобщение.
След това TLS SNI беше въведена през юни 2003 г. чрез среща на върха на IETF и целта, която тя обслужваше, в известен смисъл беше да създаде етикети с имена за компютрите и услугите, участващи в мрежата за обмен. Това направи процеса на обмен на сървър-клиент много по-прав, тъй като сървърът успя да предостави точните необходими сертификати и двамата успяха да имат свой собствен обмен на разговори, без да се объркват кой какво каза. Това е малко като да имате имена на контакти за чатове и да не се бъркате откъде идват съобщенията, а също и да можете да отговорите по подходящ начин на всяка заявка, като предоставите правилните документи на който и компютър да се нуждае. Тази дефиниция на SNI е точно това, което предизвика най-големия проблем с този метод за оптимизиране на процеса на обмен.
Борбата, с която се сблъскаха много фирми при преминаването към HTTPS, беше адаптирането на много сертификати към формата SNI с индивидуални IP адреси, за да изпълняват заявки за всеки сертификат. Това, което TLS направи за тях, беше да опрости генерирането на сертификати, за да отговори на такива искания, а това, което SNI направи още повече, беше да премахне необходимостта от индивидуализирани IP адреси на специални сертификати, като въведе цяла система за идентификация в цялата мрежа от интернет. Това, което дойде с ъпгрейда на века, беше фактът, че той позволи на хакерите да използват установените „имена на контакти“, за да наблюдават и прехвърлят данните в сянка и да извличат информацията, която им е необходима за дешифриране на по-късен етап.
Въпреки че TLS позволява данните да се изпращат напред и назад в криптиран канал, като SNI гарантира, че те достигат правилната дестинация, последният също така предоставя средства за хакери за наблюдение на онлайн активността и съпоставянето им с нейния източник, следвайки DNS заявки, IP адреси и потоци от данни. Въпреки че са въведени по-строги политики за кодиране на SNI чрез предаване на DNS информация и през канала TLS, остава малък прозорец за хакерите, за да могат да го използват като средство за идентификация, за да следват информацията, която биха искали да извлекат и изолират за дешифриране. Сложните сървъри, които се справят с по-голям трафик на TLS криптирани данни, използват обикновен текст SNI, за да изпращат комуникацията на своите сървъри и това е, което улеснява хакерите да идентифицират каналите и потоците от информация, които искат да следват. След като хакерът успее да извлече информацията за SNI от данните, които представляват интерес, той / тя може да настрои фалшиво повторение на командата в отделна TLS връзка със сървъра, изпращайки открадната информация за SNI и извличайки информацията, която беше свързано с него. В миналото имаше няколко опита за разрешаване на този проблем с SNI, но повечето се противопоставиха на принципа на простота, по който SNI работи, за да го направи удобен метод за идентификация на сървърите.
Обратно към срещата на върха, която за пръв път работи за установяването на този метод, участници от четири технологични гиганта се завърнаха на конференцията в Монреал, за да разработят криптиране за TLS SNI, защото въпреки по-голямата ефективност в мулти HTTPS прилежащата система, сигурността все още остава загриженост само колкото и преди.
За да се скрие SNI в TLS, трябва да се съхранява „Скрита услуга“ под шоуто на „Fronting Service“, която хакерът може да види. Без да може директно да наблюдава скритата услуга, хакерът ще бъде заблуден от маскировката отпред, под която се крие в обикновен текст, без да може да идентифицира основните параметри на тайната служба, използвани за препредаване на криптирани данни. Тъй като наблюдателят следва следата на предната услуга, данните ще бъдат премахнати от наблюдавания канал, тъй като те ще бъдат пренасочени към предвидената скрита услуга, в който момент хакерът ще е загубил следата си. Тъй като сървърът също ще бъде изложен на услугата за препращане, тъй като данните си проправят път там, вторият паралелен сигнал SNI ще бъде изпратен до услугата за пренасочване, за да пренасочи данните към скритата услуга и в тази посока процесът на промяна, хакерът ще да се загубите в мрежата на сървъра. Този механизъм на двойни билети е доразвит в комбиниран билет съгласно същия SNI. Тъй като една част от данните се изпращат към сървъра, данните произвеждат съдействащ SNI редиректор и двете работят заедно, за да получат TLS криптирани данни до мястото, където трябва да отидат. Без да може да пробие услугата за рандомизиран фронт, която обхваща и двата канала SNI, хакерът няма да може да следва следите на данните, но сървърът все още ще може да свърже двете и да дешифрира скритата услуга като крайно местоположение на данните. Това позволява на сървърите да продължат да използват SNI, за да оптимизират прехвърлянето на данни в TLS криптиране, като същевременно гарантират, че хакерите не са в състояние да се възползват от механизма SNI.
