Как «разблокировать» QUIC с нестандартной конфигурацией TLS?
Есть приложение, которое использует QUIC в качестве транспортного протокола. Передаваемые данные это НЕ «веб» трафик, по паттернам поведения тоже сильно отличается от веба (используются как однонаправленные, так и двунаправленные стримы), много (~50) одновременных коннектов и что самое главное - используется расширение Raw Public Keys (https://datatracker.ietf.org/doc/html/rfc7250). Также, для того чтобы уменьшить начальные ClientHello пакеты при «настройке» TLS убрано всё лишнее - в списке поддерживаемой криптографии передаётся только AES_256_GCM_SHA384, AES_128_GCM_SHA256 и CHACHA20_POLY1305_SHA256 (требования протокола), а для обмена ключами стоит только X25519.
Казалось бы довольно уникальный набор параметров, поведение отличается от обычных браузеров или VPNов. Но к сожалению провайдеры такой трафик блокируют (проверены МГТС и Ростелеком).
Если пропатчить библиотеку с QUIC’ом и перевернуть байты в пакете то трафик начинает проходить и всё работает как надо. Если использовать обычные сертификаты то тоже всё работает.
Отсюда вопрос - кто-нибудь сталкивался с подобным при использовании Raw Public Keys? Может ли кто-нибудь исследовал какие главные триггеры у ТСПУ по фильтрации QUIC трафика? Вдруг условно можно указать какой-нибудь кузнечик в списке криптографии и товарищ майор благословит подобный трафик :D
Заранее спасибо за любую полезную информацию!