Борьба за Интернет будущего

[Lame]

http://www.chip.ua/wp-content/uploads/2014/01/111.jpg

 

Удовлетворение — обманчивое чувство, особенно если речь идет об Интернете. Пользователи все чаще готовы тратить свои деньги на относительно дорогой широкополосной доступ в Сеть. После этого их программы для проверки скорости интернет-подключения подтверждают: соединение имеет скорость 50 Мбит/с или выше. Однако в действительности страницы вряд ли открываются быстрее, чем при старом подключении DSL.

 

http://www.chip.ua/wp-content/uploads/2014/01/15.jpg

 

Время отклика важнее скорости. Начиная с 4 Мбит/с повышение скорости не приводит к более быстрой загрузке веб-страниц. Гораздо важнее эффективность, с которой сервер передает данные.

 

Ускорение аппаратной части не повышает скорость Сети, ведь загрузку страниц тормозят устаревшие протоколы, с помощью которых общаются браузеры и серверы. Они были созданы еще в те времена, когда из Интернета загружались простейшие HTML-страницы с несколькими картинками. С тех пор сетевые коммуникации продвинулись невероятно далеко: веб-страницы с несколькими сотнями скриптов стали обычным делом, как и возможность одновременной загрузки элементов из разных источников. Часто бывает необходима интерактивность или применяется активное шифрование для защиты информации.

 

http://www.chip.ua/wp-content/uploads/2014/01/121.jpg

 

HTTP — это центральный прикладной протокол, который регулирует коммуникацию между браузером и сервером. Его актуальная версия 1.1 была введена в строй еще в 1999 году и с тех пор время от времени оптимизировалась, однако основные слабые места остались прежними (см. таблицу). Этот протокол не способен использовать все возможности, которые дает доступная на сегодня пропускная способность интернет-сетей. К тому же из-за больших сетевых издержек (overhead) он производит огромный поток ненужных данных. Неудивительно, что Инженерный совет Интернета (Internet Engineering Task Force, IETF), ответственный за техническое развитие Сети, с 2012 года занимается обновлением протокола передачи данных. Срок намечен точно: специалисты планируют введение HTTP 2.0 в конце 2014-го. В июле был опубликован первый черновик спецификации, а с августа уже ведутся работы по тестированию.

 

Конкурирующие предложения

 

За прошедший год свои предложения по технической модернизации HTTP 2.0 внесли Google и Microsoft. Протокол SPDY (от англ. Speedy – «быстрый»), разработанный Google, конкурировал с HTTP Speed+Mobility от Microsoft.

 

Оба варианта должны были решить проблемы со скоростью, существующие в HTTP 1.1, и отличались подходом к вопросу о необходимости постоянного шифрования в HTTP 2.0. Когда в качестве основы для HTTP 2.0 утвердили SPDY, в IETF отказались от обязательного шифрования данных, предусмотренного для этого протокола, поскольку оно потребовало бы от мобильных устройств дополнительной вычислительной мощности и, следовательно, сократило бы время их работы от аккумуляторов. К тому же принудительное шифрование могло сильно затронуть владельцев небольших сайтов, ведь необходимый сертификат стоит денег.

 

http://www.chip.ua/wp-content/uploads/2014/01/131.jpg

 

Преимущества нового HTTP 2.0

 

Путь к HTTP 2.0 был уже намечен, когда разоблачения Эдварда Сноудена перечеркнули все планы, казавшиеся такими прекрасными. В начале сентября выяснилось, что американская служба внешней разведки АНБ в состоянии свободно перехватывать данные, зашифрованные в HTTPS. Эксперт по криптографии Брюс Шнайер даже заявил, что правительство США «предало Интернет». После этого второстепенная прежде тема «Безопасность HTTP 2.0» попала в центр общественного внимания. Председатель IETF Яри Аркко ввел ее в повестку дня заседания совета, прошедшего в ноябре в Ванкувере. Специальная рабочая группа собрала там предложения по неприкосновенности шифрования в HTTP 2.0.

 

Веб-шифрование HTTPS использует для установки безопасных соединений существующие протоколы SSL и TLS. Сначала проводится асимметричное шифрование, для которого нужны два ключа: открытый (public key) и закрытый (private key). Сервер посылает браузеру сертифицированный открытый ключ. Браузер на основе сертификации проверяет, действителен ли этот ключ, генерирует с его помощью и отправляет на сервер сеансовый ключ (session key) для симметричного шифрования потока данных. Сервер использует свой закрытый ключ, чтобы извлечь из сообщения ключ для симметричного шифрования. В результате сервер и браузер имеют один и тот же сеансовый ключ и с его помощью могут шифровать дальнейший поток данных.

 

АНБ и лазейка в веб-шифровании

 

АНБ — это инстанция, которая перехватывает и записывает петабайты данных в Сети. Она могла бы расшифровать любое соединение, если бы получила доступ к закрытому ключу сервера — например, по решению суда или путем взлома. Поэтому для HTTP 2.0 и протокола шифрования TLS 1.3, который также находится в стадии разработки, был предложен другой метод генерирования ключей — Perfect Forward Secrecy (PFS), в котором не предусмотрен прямой обмен ключами. Вместо этого сервер и браузер обмениваются несколькими сообщениями и с помощью построенного на их основе криптографического метода (так называемый алгоритм обмена ключами Диффи — Хеллмана) независимо друг от друга производят общий для обоих симметричный ключ, который не пересылается через Сеть. Он действует только в течение одного сеанса, а затем удаляется.

 

http://www.chip.ua/wp-content/uploads/2014/01/14.jpg

 

Криптографические методы PFS, с помощью которых генерируются ключи, обещают быть безопасными. Но в прошлом NSA активно сотрудничало в работе над этой системой и, возможно, позаботилось о лазейках, которые сможет использовать в будущем. Так, стало известно о «баге» в эллиптической кривой для генератора случайных чисел Dual_EC_DRBG. Значения данной кривой использовались при генерировании случайных чисел для асимметричной пары ключей. Остальные кривые, которые были опубликованы ведомством стандартизации США (NIST), тоже находятся под подозрением. Между тем IETF получило предложение Саймона Джозефссона использовать для TLS 1.3 другую эллиптическую кривую с обозначением 25519, поскольку она не имеет отношения к NIST и позволила бы закрыть в TLS 1.3 лазейку, оставленную NSA.

 

Однако нового протокола TLS недостаточно: в криптографическом методе RC4, применяемом при шифровании HTTPS, по-видимому, тоже может найтись слабое место «от NSA». RC4 как часть активных протоколов безопасности от SSL 2.0 до TLS 1.2 используется в 50% случаев шифрования веб-трафика. В TLS 1.3 можно было бы просто отказаться от RC4, однако при нынешнем уровне безопасности используемый протокол определяется сервером.

 

В то время как в новейшие версии браузеров Chrome и Internet Explorer уже имплементирован актуальный TLS 1.2, большинство всех веб-серверов продолжает применять устаревшие варианты SSL 3.0 или TLS 1.0 (см. график). У обоих есть известные «дыры», которые могут быть использованы для взлома. Поэтому одно из предложений по HTTP 2.0 предусматривает коренное изменение: в будущем выбор протокола будет определяться браузером. В итоге благодаря этому пользователь сможет сам задавать степень защиты своего HTTPS-соединения.

 

«Дыры» в безопасности SSL/TLS

 

Современные методы атак на TLS базируются на возможности пересылать перехваченные и измененные пакеты дальше. Центральную роль при этом играет код аутентичности сообщения (Message Authentication Code, или MAC), который во время связи с помощью сеансового ключа передается с каждым пакетом данных. MAC создается на основе хэш-значения пакета данных и сеансового ключа. С помощью MAC принимающая сторона узнает, что пакеты действительно посланы отправляющей стороной. Сегодня все протоколы безопасности действуют по принципу «MAC then encrypt» («сначала MAC, потом дешифрование»). То есть, чтобы сгенерировать MAC, применяется хэш-значение еще не зашифрованного содержимого пакета, а это небезопасно. В качестве защитной меры вводится расширение для TLS, которое работает по методу «encrypt then MAC», применяя хэш-значение уже зашифрованного содержимого пакета, с которым взломщик ничего не может поделать.

 

Правда, пока не ясно, достаточно ли этих мер, чтобы воспрепятствовать той глобальной прослушке, которую ведут спецслужбы. Они ликвидируют лишь уже известные слабые места. Как бы то ни было, спорная тема постоянного шифрования в HTTP 2.0 вновь стоит в повестке дня совета Internet Engineering Task Force.

 

Решить проблемы скорости

 

Члены IETF единодушны в своем отношении к технологиям, которые должны решить проблемы производительности HTTP 1.1. Основой является протокол SPDY версии 3, разработанный Google. Его уже поддерживают актуальные версии таких браузеров, как Chrome, IE, Firefox и Opera. Safari от Apple еще не вошел в этот список.

 

http://www.chip.ua/wp-content/uploads/2014/01/18.jpg

 

Новый SPDY быстрее старого HTTP. Для передачи данных по протоколу SPDY необходима его поддержка веб-сервером. По сравнению с HTTP-серверами, тестовый сервер под названием Flip работает значительно быстрее и надежнее

 

SPDY решает проблемы структурного дефицита HTTP 1.1. Так, в HTTP 1.1 серверу приходится для каждого элемента устанавливать отдельное TCP-соединение. Для этого он запускает несколько параллельных соединений, что приводит к избыточному трафику и может вызвать так называемую блокировку начала строки (head of line blocking). При этом обработка пакетов данных тормозится, так как они всегда идут в том порядке, в котором запрашиваются, независимо от того, ошибочен ли запрос, или его обработка занимает слишком много времени. К тому же инициатива HTTP-соединения всегда исходит от клиента. Браузер постоянно спрашивает, не изменилось ли содержимое интернет-страницы. Сервер сам по себе такой информации не дает.

 

В HTTP 2.0 все иначе: после однократного установления соединения браузер и сервер могут независимо друг от друга создавать собственные потоки, в которых они посылают свои пакеты данных. Благодаря мультиплексированию (так называется параллельная обработка нескольких запросов/ответов) это происходит одновременно. В отличие от HTTP 1.1, версия 2.0 реализует параллелизацию в пределах одного TCP-соединения. Это существенно снижает нагрузку, особенно на стороне сервера, которому приходится одновременно обрабатывать запросы многих браузеров. К тому же фреймам присваиваются приоритеты, именно в соответствии с ними браузер или сервер могут определять порядок пакетов при расшифровке. Блокировка начала строки исключается. Кроме того, сервер получает возможность посылать браузеру push-сообщения.

 

Оптимизируются и заголовки пакетов. В версии 1.1 протокол HTTP передает их несжатыми в текстовом виде. Поэтому они слишком велики, и при обработке их приходится сначала переводить в двоичный код. Версия 2.0 сжимает заголовки и передает их уже в двоичном коде, что в первую очередь позволяет уменьшить первый фрейм пакета данных, который обрабатывается гораздо быстрее. Благодаря этому существенно снижается латентность (время отклика).

 

Как показывает пример параллелизации, многие функции HTTP 1.1 и TCP взаимосвязаны. При этом протокол TCP обладает возможностями, которые у HTTP отсутствуют: например, он обнаруживает и устраняет потери, возникающие при передаче данных, и задает порядок обработки пакетов. Однако эти контрольные функции еще больше увеличивают размер заголовка TCP, а вместе с ним растет и время отклика. Установление соединения при использовании протокола TCP сопровождается трехступенчатым «рукопожатием» (handshake), которое еще больше повышает латентность.

 

http://www.chip.ua/wp-content/uploads/2014/01/17.jpg

 

Протоколы TCP и UDP в сравнении

 

Некоторые задачи, свойственные для TCP, замедляют HTTP 2.0, и теперь HTTP 2.0 выполняет их самостоятельно. Вместо порядка пакетов, задаваемого TCP, очередность их обработки определяется с помощью приоретизации фреймов. Поэтому Google советует взять в качестве транспортного протокола недостаточно надежный, но быстрый UDP (User Datagram Protocol) и немного изменить его. Протокол QUIC (Quick UDP Internet Connections), разработанный Google на базе UDP, расширен за счет встроенной функции коррекции ошибок. Она делает ненужной исправление ошибок в TCP. От сложного трехступенчатого процесса «рукопожатий», принятого в TCP, тоже можно отказаться, поскольку HTTP 2.0 поддерживает связь между сервером и браузером через один поток. В будущем Google предполагает не заменить TCP, а интегрировать в него QUIC. Итак, уже можно представить себе мягкий переход с HTTP 1.1 на 2.0. Пользователи будут получать элементы HTTP 2.0 вместе с обновлениями браузера. При установке соединения веб-просмотрщик будет автоматически спрашивать сервер, поддерживает ли он версию 2.0. Если да — тогда вперед, в Интернет будущего!

 

http://www.chip.ua/s...net-budushhego/

Изменено 3 января, 2014 пользователем Lame

[antiz]

Еще больше порно и еще более качественного! Ура технологиям!