Поиск Google и защищённый доступ по https
В конце мая Google, наконец-то, реализовал доступность поиска по HTTPS – https://www.google.com/. Правда, пока не все поисковые направления работают по защищённому протоколу, например, не поддерживает HTTPS поиск по изображениям. Да и вообще всё в статусе беты. Тем не менее, это важный шаг.
Так, у Google нашлось достаточно вычислительных мощностей, чтобы перевести на HTTPS один из самых своих массовых сервисов: нужно учитывать, что вычислительные затраты на работу по шифрованному каналу заметно больше, если сравнивать с простым HTTP. При работе с многими миллионами запросов – проблема с дополнительной нагрузкой встаёт в полный рост.
Но самое интересное-то в другом. Сейчас все пользователи постепенно переезжают в новый Интернет. В старом Интернете веб-трафик был сплошь открытым, из, так сказать принципиальных соображений. Всякий “любопытный”, имеющий доступ к каналам связи, мог этот трафик записывать, анализировать, фильтровать, подделывать и дополнять разными “инъекциями”. В новом Интернете каналы “точка-точка” – хорошо закрыты криптографическими средствами. И всякий узел удостоверяется электронной подписью.
Если строить аналогию, то можно представить, что участники сети перестали обмениваться между собой почтовыми открытками (которую может почитать каждый почтальон), а вместо этого перешли на хорошо заклеенные печатями непрозрачные конверты.
В ближайшие годы на HTTPS перейдёт ещё больше сайтов. Вряд ли, конечно, защищённая версия быстро полностью вытеснит открытый протокол – ведь используют же до сих пор FTP. Но доля трафика HTTPS сильно вырастет. Собственно, уже и только трафик Google – заметная прибавка.
При этом криптография активно внедряется и на уровне DNS – это DNSSEC, – и на уровне IP (здесь планируется сертификация маршрутов и автономных систем, с подписыванием ЭЦП анонсов BGP – об этом, наверное, нужно отдельную записку написать). Новый Интернет должен сформироваться уже лет через пять. Помимо перехода на HTTPS, важным моментом будет проталкивание поддержки DNSSEC на клиентские машины.
Адрес записки: https://dxdt.ru/2010/06/01/3157/
Похожие записки:
- Реплика: атака посредника в TLS и проблема доверия сертификатам
- Реплика: программные "демультиплексоры" протоколов уровня приложений
- Десятилетие DNSSEC в российских доменах
- Маскирование криптографических ключей в памяти
- Реплика: внешние капча-сервисы и сегментация
- Rowhammer-атака и код сравнения с нулём
- Публикация ТЦИ о постквантовых криптосистемах
- Вычислимые опасности ИИ
- Техническое: занимательный пример из практики DNS в Интернете
- Постквантовая "гибридизация" криптосистем и перспективы стойкости
- Уровни сигнатур клиентских подключений
Комментарии читателей блога: 4
1 <t> // 1st June 2010, 19:06 // Читатель Макс Лапшин написал:
Надо понимать, что есть ещё одна немаловажная проблема. HTTP/1.1 поддерживает заголовок Host, который невозможен в случае с HTTPS
2 <t> // 1st June 2010, 19:25 // Читатель jno написал:
Есть и SCP и SFTP…
И даже внутри FTP есть криптозащита сессий.
3 <t> // 1st June 2010, 20:38 // Читатель Alatar написал:
>> Надо понимать, что есть ещё одна немаловажная проблема. HTTP/1.1 поддерживает заголовок Host, который невозможен в случае с HTTPS
А можно с этого места по-подробнее, почему это невозможен? Что-то первый раз такое слышу.
4 <t> // 1st June 2010, 23:04 // Читатель GreenElf написал:
Заголовок HOST возможен, но бесполезен. ssl сессия устанавливается ДО начала http, и сервер может предъявить только один сертификат на какой-то определенный CN (Common Name), а после этого уже менять имя сервера в HOST заголовке поздно.