Преамбула
Интересно бывает проанализировать зарубежный технологический опыт, благо материалов в открытом доступе хватает. На прошедшей 13-15 июня 2016 в Чикаго конференции NANOG67 в программе присутствовала, пусть и не сверхинновационная, но очень полезная презентация "Network Support for TCP Fast Open" по проблемам использования TCP Fast Open (TFO). Спикер Christoph Paasch из Apple проводит анализ в контексте изучения веб-трафика для оптимизации ресурсов серверов.
Материал в открытом доступе, доступен как в виде краткого обзора , так и презентации , и даже видеозаписи . Кроме пользы материала, дополнительное уважение вызывает спикер, выступающий на инвалидной коляске.
Озвученная проблема
На высоконагруженных ресурсах использование полноценного TCP для обслуживания каждого запроса - дорого с точки зрения потребления вычислительных ресурсов и времени установки сессии. В RFC7413 описана облегченная реализация под названием "TCP Fast Open". При использовании в приложениях TCP Fast Open появляются проблемы прохождения трафика через промежуточные устройства, выполняющие проверку на легитимность TCP-сессии, типа firewall и IDS/IPS, для которых TFO является ненормальным трафиком в связи с отклонениями от стандартного TCP. Как итог, выступление призывает производителей сетевого оборудования и операторов задуматься о поддержке в своем оборудовании и сети TCP-трафика, инициируемого с использованием TCP Fast Open.
Дискуссия
Казалось бы, чисто американская конференция операторов связи, описывающая просто технологическое предложение. Но, поскольку TFO используется в iOS 9, OS X 10.11 и более поздних версиях, а также поддерживается в Apple Service, думаю, география вопроса потенциально расширяется далеко за пределы североамериканского континента, натягиваясь на весь глобус.
Краткая вводная, известная преобладающему большинству специалистов ИТ/ИБ: TCP работает по принципу "трехстороннего рукопожания":
Кристоф даже приводит интересную юмористическую аналогию. Как бы выглядел юмор, если бы шутки передавались по TCP (лично у меня это проассоциировалось с SCTP, а не TCP):
Предлагаемый для использования TCP Fast Open позволяет установить соединение и начать передачу данных немного раньше. Первой фазой произойдет генерация SYN Cookie, затем последующие SYN-пакеты клиента будут уже будет содержать данные, ответ на которые сервер даст сразу после SYN/ACK, не дожидаясь ACK от клиента.
Полученная кука запоминается, и используется в последующих запросах к тому же серверу для ускоренной инициации обмена данными. И это все на уровне стека TCP/IP.
Как видно, последующих запросов на передачу данных может быть очень много на одну куку.
Открытые вопросы
Навскидку вижу такие потенциальные проблемы.
- Уязвимости клиента и сервера, связанные с обработкой Cookies. В "чистом" TCP стек не передает приложению данных из SYN-пакета (которые можно вставить, RFC позволяет), соответственно, проблем с их обработкой практически нет. В приложениях с поддержкой TFO могут потенциально возникнуть связанные с Cookies уязвимости TCP-стека и приложения.
- Cookie. Алгоритм генерации и составляющие. От них напрямую зависит возможность использования чужой сессии как для получения данных, предназначенных для другого клиента, так и для спуфинга с соответствующим DDoS. Как видно из презентации, стойкость к перебору зависит от наличия соли и ее комплексности. Есть подозрение, что если ПО сервера будет позволять генерацию Cookie без соли, то большой процент администраторов не будет заморачиваться с ее использованием. В этом случае джентльменский набор для DDoS из скриптов генерации запросов и базы кук для спуфинга в виде хэшей IP всех потенциальных жертв будет занимать совсем немного места.
- Cookie. Время жизни. Тоже немаловажный фактор, особенно если администратор сервера не озаботился наличием соли для куки. При отсутствии соли и длительном времени жизни куки TFO приближается по уровню безопасности к UDP.
- Cookie. Перебор. Затрудняюсь предположить, как реализовать механизмы защиты.
- NAT типа PAT, он же many-to-one. К одному серверу обращается много клиентов, которые прячутся за одним реальным IP-адресом. Постоянная перегенерация куки будет аннулировать полученные преимущества в экономии вычислительных ресурсов, в то время как поддержка сервером большого количества кук на одного клиента (RFC позволяет) упрощает процесс подбора куки.
Выводы
Поддержка TCP Fast Open, наряду с оптимизацией ресурсов серверов при обработке TCP-сессий, привносит некоторые потенциальные проблемы с безопасностью подобной реализации, которые можно минимизировать следующими путями:
- Тестирование на уязвимости, связанные с обработкой Cookies TCP-стека и приложения.
- Повышение комплексности Cookie за счет использования соли (возможно, еще дополнительных опций) и коллизионно-стойкого алгоритма хэширования.
- Понижение времени жизни Cookie.
- Внедрение механизмов защиты от перебора Cookie.
- Не передавать данные, не получив ACK. Тогда протокол будет еще безопаснее, чем "чистый" TCP, за счет наличия Cookies, но экономии в потреблении ресурсов тоже не будет.
