3
HTTP-протокол приложения, и базовое TCP-соединение может быть закрыто и открыто, не затрагивая приложение HTTP (кроме производительности).
Используя HTTP1.1, мы используем постоянные соединения, но сервер или клиент могут закрыть соединение в любое время.
Для безопасности HTTP использует TCP через SSL/TLS.
Я понимаю, что SSL действует так же, как приложение, по крайней мере, это то, как TCP «просматривает» SSL.
Вопрос в том, что базовый TCP-сокет закрывается в точке после установления безопасного соединения, означает ли это, что сеанс SSL становится недействительным, а стороны должны начинать с рукопожатия ssl?
Или базовое TCP-соединение не имеет отношения к сеансу TLS?HTTP-постоянное соединение и сеанс ssl
Спасибо!
@Eugene: После установления связи стороны SSL имеют информацию, необходимую для установления защищенного канала (шифрование/дешифрование), поскольку данные безопасности были обменены (алгоритмы и т. Д.). Эта часть, насколько я понимаю, кажется неактуальной для лежащих в основе tcp, которые получают зашифрованные блоки и передают их по сокету. Почему закрытие tcp, которое закрывается, аннулирует ранее согласованные сведения о безопасности ssl-сторон (клиент/сервер)? Эта часть я не понимаю. Не могли бы вы рассказать? – Cratylus
@ user384706 С технической точки зрения SSL/TLS не заботится о соединении и может использоваться по UDP (в случае UDP используется модификация TLS, называемая DTLS), именованные каналы, почтовая почта и т. Д. (Мы когда-то реализовали ее над каналом связи на основе сообщений). Тем не менее, было решено, что для предотвращения определенных атак отключение базового канала автоматически также аннулирует SSL-соединение. В общем, ничто не заставляет вас это делать, если вы реализуете как клиентскую, так и серверную сторону связи, а также контролируете функции SSL (например, при использовании наших компонентов). –
@Eugene: Итак, лучше ли считать сеанс TLS недействительным?Это не санкционировано каким-либо RFC или не подразумевается TLS RFC, правильно? – Cratylus