Какова уязвимость данного подхода?

Question

[floppa322]

В интернете часто слышал: "Don't do your own secure layer". Имеется в виду не делать своё шифрование поверх UDP, а взять что-то готовое, например, DTLS.

Так вот, что мешает, установить TLS-соединение, внутри него (уже по безопасному зашифрованному соединению) обменяться симметричными ключами для шифрования, и далее общаться по UDP, шифруя пакеты, ключами, полученными ранее по TLS-соединению? Есть ли здесь какие-либо очевидные или не очень уязвимости ?

Comments

[profesor08]

Где-то случился поворот не туда, раз потребовался велосипед. Лучше несколько раз хорошо все обдумать и расписать все проблемы, мешающие внедрению данного протокола, а потом подумать над их решением. Желательно с коллегами.

[floppa322]

profesor08, ну там в комменте ниже написано, почему потребовался велосипед )

[pfg21]

а разве так не сделано в практически каждом шифроканале ??

[floppa322]

pfg21, ну просто суть вопроса-то и была в том, мол, "почему все говорят, что это очень сложно (реализовать свой secure-UDP), если можно сделать так, как описано в вопросе" ну или, мб такие хаки, как с установление tls соединения для обмена ключами не подразумевались )

Answer 1

[ky0]

Поздравляю, вы изобрели "your own PFS" :)

В принципе, внутри нормально зашифрованного канала можно делать что угодно, хоть обменяться ключами и установить новое, на основе этих ключей, соединение - только зачем? Всякого рода IPSec-туннели и site-to-site впны для того и служат, чтобы можно было внутри них пускать нешифрованный трафик, если, например, протокол шифрования не умеет.

Comments

[floppa322]

Просто есть нужда в использовании UDP.
И в то же время готовые решение (например, различные реализации DTLS - secure UDP) не подходят из-за крайне неудобного API и ещё пары вещшей связанных с производительностью

[ky0]

bakdurak, говорят, скоро QUIC захватит интернет :) А в нём, насколько я понимаю, как раз есть всё, вам необходимое. Фактически же, это протокол общего вида поверх UDP, в котором помимо всяких штук "а-ля TCP" есть и встроенное шифрование.

[floppa322]

ky0, просто QUIC делался для обычных, не real-time приложений
В моём случае нужно создать некоторую логику поверх UDP в Application Layer, отличную от QUIC, а делать поверх QUIC тоже не получится по некторым причинам

Answer 2

[Станислав Бодро́в]

Имеется в виду не делать своё шифрование поверх UDP

Здесь скорее всего главное не делать своё шифрование. UDP всего лишь транспорт, ему совершенно всё равно какую нагрузку он несёт. RH собирается реализовать поддержку икапсуляции протокола SCTP в UDP. Ты можешь спокойно инкапсулировать TLS в UDP, если хочешь.

Comments

[floppa322]

просто TLS + UDP = DTLS
а я-то как раз хотел сдлеать свой DTLS

Сценарий:
1. Клиент устанавливает защищённое соединение с сервером (TCP + TLS)
2. Внутри этого защищённого соединения сервер и клиент обмениваются симметричными ключами шифрования
3. Данное соединение разрывается
4. Устанавливается новое защищённое, уже UDP соединение, где клиент и сервер общаются, используя ключ полученный на шаге 2

Как именно сервер идентифицирует клиента после разрыва TCP-соединения, ведь порты (и даже IP) могут отличаться - уже детали реализации

[Станислав Бодро́в]

Почему нельзя всё сразу реализовать по UDP, если так хочется заюзать этот протокол?

[floppa322]

Станислав Бодро́в, потому что нет полной уверенности, что я учту все нюансы
а так, с одной стороны - ни хэнддшейка ни обмена ключами не нужно реализовывать самостоятельно, а с другой - получаю кастомный (с логикой поверх в App layer'е) secure UDP протокол

[Станислав Бодро́в]

UDP протокол по определению не обладает никакой секурностью, как и ТСР и прочие протоколы транспортного уровня. Эта задача вышележащих протоколов. И не стоит лепить свою криптографию

[floppa322]

Станислав Бодро́в, в этом и заключалась суть вопроса, в недостатках подхода, описанного в теле вопроса

[Станислав Бодро́в]

Это называется "наваливание лишних сущностей". С таким подходом как у тебя можно начинать с проверок доступности хоста по icmp, потом сеанс обмена ключами по tcp и затем переход на udp. Можно ещё докинуть протоколов транспортного уровня. Там их хватает.

[floppa322]

Станислав Бодро́в, если честно, не совсем понял зачем icmp, ведь по идее проверить доступность хоста должен будет tcp. Протоколов транспортного уровня не нужно докидывать )), то, о чём говорится в вопросе и есть протокол транспортного уровня

[Станислав Бодро́в]

Вот.... начинаешь уже понимать