Здравствуйте, Pzz, Вы писали:

N>>PSK этот это запомненный из прошлого состояния соответствующей сессии, если я правильно понял. Но по идее должно этого хватить...

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

Там контекст как раз передаётся: в ClientHello идёт номер сессии.
Только дальше вопрос, как сервер должен идентифицировать, с кем именно этот номер сессии сравнивать. Например, если по клиентскому IP, то что будет, когда за NAT сидят 100500 клиентов и этих номеров сессий тупо не хватит?

Там целый RFC (5077) под это сделан, но там 16 бит на номер сессии (в 8446 повторено в самом RFC). А тут, мне кажется, меньше 64 (а то и 128) недостаточно.

Pzz>Интересно, а разработчики веб-приложений вообще в курсе, что первая порция данных от клиента уходит с пониженными гарантиями?

По-моему, гарантия достаточна.
Присылаете запрос с указанием номера PSK. Если расшифровано и подпись сошлась — принимается. Иначе — нет, назад идёт "неее, устанавливаем заново".
То, что я говорил выше, это увеличивает количество таких перезапусков при ложных коллизиях, но не даёт чтение чужих данных или их успешную подделку.

Здравствуйте, netch80, Вы писали:

N>По-моему, гарантия достаточна.
N>Присылаете запрос с указанием номера PSK. Если расшифровано и подпись сошлась — принимается. Иначе — нет, назад идёт "неее, устанавливаем заново".
N>То, что я говорил выше, это увеличивает количество таких перезапусков при ложных коллизиях, но не даёт чтение чужих данных или их успешную подделку.

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

Здравствуйте, Pzz, Вы писали:

N>>По-моему, гарантия достаточна.
N>>Присылаете запрос с указанием номера PSK. Если расшифровано и подпись сошлась — принимается. Иначе — нет, назад идёт "неее, устанавливаем заново".
N>>То, что я говорил выше, это увеличивает количество таких перезапусков при ложных коллизиях, но не даёт чтение чужих данных или их успешную подделку.

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

Как раз это должен делать, скорее всего, встроенный http клиент браузера. Именно ему держать пул истории соединений и пытаться переюзать существующие договорённости.
Не будут же писать TLS прямо на JS...

Здравствуйте, netch80, Вы писали:

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

N>Как раз это должен делать, скорее всего, встроенный http клиент браузера. Именно ему держать пул истории соединений и пытаться переюзать существующие договорённости.
N>Не будут же писать TLS прямо на JS...

Он не знает, для какого запроса какие гарантии нужны.

Если это переложить на него, ну он просто будет при открытии нового соединения посылать на всякий случай preflight запрос. Получим 0-RTT TLS и лишний HTTP-ный RTT к нему в довесок

Здравствуйте, Pzz, Вы писали:

Pzz>>>Но ты ведь понимаешь, что это должны знать и делать те гаврики, которые на JS скрипты пишут для вебовских страничек какого-нибудь условного банка?
N>>Как раз это должен делать, скорее всего, встроенный http клиент браузера. Именно ему держать пул истории соединений и пытаться переюзать существующие договорённости.
N>>Не будут же писать TLS прямо на JS...
Pzz>Он не знает, для какого запроса какие гарантии нужны.

Смотрим кэш завершённых соединений, отфильтрованный по ремоту (host+port), выбираем некоторое, скорее всего, самое последнее (для надёжности восстановления). Для соединения записано, каким идентификатором сессии оно было обозначено, такой и посылаем.

Это чисто теоретически, конечно — какие тут грабли, я не в курсе.