Re[10]: TCP все...
От: Pzz Россия https://github.com/alexpevzner
Дата: 17.11.18 14:13
Оценка:
Здравствуйте, Ops, Вы писали:

Pzz>>Этот метод считается достаточно надежным для, например, привязывания брелков к электрическим воротам, или для привязывания bluetooth устройств. Воткнуться, конечно, в нужный момент можно, но это надо очень постараться.


Ops>BT, WPS и, подозреваю, ворота с брелоками, обеспечивают это вообще на канальном уровне. А уже на уровне IP такой сценарий затруднителен, из-за меньшей локальности хостов в общем случае.


Ну спросили про утюг, я и ответил про утюг. Утюг всегда локален, иначе нафиг он вообще нужен? Каждая задача должна решаться с учетом спецефических для нее потребностей.

В общем и целом, доверие должно на чем-то основываться. Использование сертификационных центров, которым все доверяют (совершенно напрасно, на мой взглад) — один из вариантов. Использование явного действия со стороны пользователя — другой возможный вариант, при условии, что пользователь действительно понимает, что он делает.

Pzz>>Без надстроек он обеспечивает TLS-like модель безопасности, при наличии соответствующей инфраструктуры для раздачи сертификатов.


Ops>А в чем польза-то? Ну сделали бы этот протокол без принудительного шифрования, а сверху пустили бы тот же TLS, когда нужно.


В том, что от внесения шифрования на уровень транспортного протокола, можно добиться существенной экономии. Например, объединяя "TLS" handshake и "TCP" handshake, можно установить соединение с шифрованием за 1-2 RTT, а не за 5-7, как в случае TCP+TLS. Объеденив "TCP" sequence numbers с криптографическим nonce, можно сэкономить несколько байт на пакет, что заметно, если пакеты маленькие (как в случае аудиопотока, например). Ну и т.д. и т.п.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.