Всем здравствуйте.
Цель: сделать защищённое UDP-соединение.
Чтобы собственными руками не писать хэндшейки и код для передачи ключей шифрования(симметричных), было принято решение:
1.установить соединение по TLS протоколу; 2. внутри него обменяться ключами; 3.разорвать TLS соединение; 4. обмениваться данными по Уже защищённому UDP-соединению, используя ранее полученные ключи.
В качестве достоинств такого подхода: используется уже протестированный и стабильно работающий протокол, следовательно снижается кол-во кода, где может быть баг.
Вопрос: какие недостатки может повлечь за собой такое решение? (за исключением, отсутствия кастомизации момента хэндшейка и обмена ключами, заложенного в TLS)
P.S.: кстати, по-моему, https тоже сначала использует медленный алгоритм ассиметричного шифрования, для обмена внутри него симметричными ключами (так как ассиметричное шифрование намного медленнее симметричного, лучше использовать симметричное)
Защищённое UDP-соединение применяется (в данном случае), для real-time приложения, где каждая миллисекунда на счету, не стал про это говорить в вопросе для краткости.
Ну и вообще, насколько мне известно, VPN это более комплексное решение, воздействующее на весь трафик целиком, а не лишь на трафик одного приложения. По крайней мере, например, Steam и Blizzard не используют его для secure части своего протокола
Есть единый сервер, есть множество клиентов, для каждого клиента внутри TLS генерируется симметричный ключ (алгоритм шифрования RC4), затем по UDP этот ключ используется. Как TCP(TLS), так и UDP взаимодействие происходит на одном сервере, даже внутри одного процесса
Сложный
Простой
