#ssl #openssl #polling #starvation
#ssl #openssl #опрос #голодание
Вопрос:
Обеспечивает ли OpenSSL и / или протокол SSL / TLS какую-либо встроенную защиту от бесконечного пересмотра условий?
В частности, возможно SSL_read() ли продолжать выполнение вечно, потому что удаленная сторона (возможно, злонамеренно) продолжает запрашивать повторные переговоры без отправки данных полезной нагрузки?
Меня это беспокоит, потому что я хочу обслуживать несколько SSL-соединений из одного потока, используя механизм опроса, а также обеспечить справедливость, при которой обработка ввода-вывода в одном соединении не приводит к сбою ввода-вывода в других соединениях.
Когда я вызываю regular read() на сокете в неблокирующем режиме, я знаю, что он не может выполняться вечно, потому что буфер в конечном итоге заполнится.
Однако, поскольку SSL_read() может прозрачно обрабатывать повторные переговоры, мне кажется, что если удаленная сторона (возможно, злонамеренно) продолжает запрашивать повторные переговоры без отправки данных полезной нагрузки, а базовый транспортный уровень достаточно быстр, чтобы базовые операции чтения и записи никогда не завершались неудачно EWOULDBLOCK , то SSL_read() это может закончиться выполнением навсегда и, таким образом, лишить другогосоединения.
Поэтому мой вопрос: есть ли у OpenSSL или протоколов механизмы, позволяющие избежать этого? Кстати, вопрос в равной степени относится SSL_write() и к.
РЕДАКТИРОВАТЬ: например, могу ли я быть уверен, что SSL_read() это вернется с SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE указанием /, прежде чем участвовать в нескольких повторных согласованиях, даже если базовые операции чтения / записи никогда не завершаются сбоем EWOULDBLOCK ?
РЕДАКТИРОВАТЬ: для целей этого вопроса предположим, что я использую обычный сокет BIO ( BIO_s_socket() ) и что базовый сокет находится в неблокирующем режиме.
Комментарии:
1. Он не может прозрачно обрабатывать повторные переговоры. Это зависит от того, что вы вызываете write при возникновении NEED_WRAP.
2. Я предполагаю, что OpenSSL не предоставляет эвристики для его обнаружения. Вероятно, это исправление, которое должно происходить выше в стеке и на границе сети, например, на брандмауэре.
Ответ №1:
В OpenSSL нет встроенной защиты. Но вы можете использовать SSL_CTX_set_info_callback или аналогичный, чтобы установить функцию, которая вызывается при каждом согласовании. Таким образом, вы можете прервать соединение, если внутри одного и того же соединения происходит слишком много повторных согласований. Для получения дополнительной информации см. раздел Защита от DoS, инициируемого клиентом для повторного согласования в OpenSSL / Python.