Поиск 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/
Похожие записки:
- Ретроспектива заметок: сентябрь 2013 года
- "Авторизованный трафик" и будущее Интернета
- Машинный ИИ в книгах прошлого века
- Gofetch как уязвимость
- Реплика: особенности DNSSEC
- IP-адреса и октеты
- Модули DH в приложении Telegram и исходный код
- Одновременность состояний и суперпозиция для Конгресса
- Постквантовые криптосистемы в Google Chrome (Kyber768)
- Вывод ключей Kyber768 на tls13.1d.pw
- DNSSEC и особенности развития технологий
Комментарии читателей блога: 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 заголовке поздно.