NANOG67: Безопасность TCP Fast Open

Преамбула

Интересно бывает проанализировать зарубежный технологический опыт, благо материалов в открытом доступе хватает. На прошедшей 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, но экономии в потреблении ресурсов тоже не будет.