Как рассчитать размер SSL-данных?

@mytilus · Регистрация: 04.10.2012

Студворк — интернет-сервис помощи студентам

Приветствую!
Пишу TCP-сервер с поддержкой SSL. Для упрощения реализации хочу выделить память под входящее сообщение, равную максимально возможной длине такого сообщения. Ну, чтобы не обрабатывать данные "кусками".
Отсюда два вопроса, ответ на которые я не смог найти.
Во-первых: какова максимальная длина сообщения от клиента во время handshake? А во-вторых: если после handshake клиент должен отправлять на сервер данные не длиннее X байтов, можно ли рассчитать максимальную длину кодированных данных?

Убежденный · 07.10.2015, 08:55

Сообщение от mytilus

Для упрощения реализации хочу выделить память под входящее сообщение, равную максимально возможной длине такого сообщения. Ну, чтобы не обрабатывать данные "кусками".

Бесполезная затея.
Вот придет 1 байт данных и все равно придется работать "кусками".

@mytilus · 07.10.2015, 14:26 **[ТС]**

Сервер работает в блокирующем режиме. Если я правильно понимаю, в этой ситуации сокет будет ждать окончания входящего сообщения, прежде чем вернет управление программе.

Убежденный · 07.10.2015, 14:34

Ну ок. Придет "сообщение" в 1 байт, что тогда ?

@mytilus · 07.10.2015, 14:48 **[ТС]**

Как вариант, сервер просто закроет соединение, поскольку "знает", что сообщение в 1 байт быть не должно.

Убежденный · 07.10.2015, 14:54

Значит, это неправильный сервер. Потому что клиент не может гарантировать,
что на сервер не придет 1 байт. Никак.

@mytilus · 07.10.2015, 15:08 **[ТС]**

1 байт для меня - не проблема. Вот 1 гигабайт - это уже другое дело.
Разверну свой вопрос. Пишу под Win. Когда клиент инициирует соединение, сервер полученные данные отправляет в Schannel для формирования handshake-ответов. Когда handshake завершен и кодированное соединение налажено, все сообщения клиента отправляются в Schannel для декодирования, после чего парсятся сервером. Но и в первом и во втором случае Schannel может вернуть ошибку incomplete message, мол, буфер оказался маловат, заберите оставшуюся часть сообщения. Если бы я знал максимально необходимую длину буфера под мои нужды, то такая ошибка сигнализировала о том, что клиент отправляет слишком длинное сообщение, которое сервер все равно не поймет. Тогда я не стал бы заморачиваться с этим конкретным клиентом и отвязался от него, так как он шлет какую-то чушь.

@mytilus · 09.10.2015, 16:46 **[ТС]**

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

Длина списка с этими методами будет варьироваться от клиента к клиенту. Конечно, их число конечно, более того - под ID метода выделено лишь два байта, а это значит, что вариантов больше 0xFFFF быть не может. Следовательно, для буфера под handshake достаточно выделить 0x20000 байтов под этот список + еще около 100-200 байтов под сопутствующую информацию (флаг handshake, версия TLS, timestamp, имя хоста и пр.).

Безусловно, ~128 КБ памяти под одно соединение - вещь вполне подъемная. Но дальше от клиента пойдут запросы, длина которых зависит от шифра, на котором условились общаться клиент и сервер. И здесь рушатся все желания вычислять максимально возможную длину шифрованных данных.

Увы, но, по ходу дела, придется работать с "кусками".

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Desktop (MinGW): Рисуем цветные прямоугольники с помощью рисовальщика SDL3 на Си и C++ 8Observer8 17.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-rectangles-sdl3-c. zip finish-rectangles-sdl3-cpp. zip	Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link),. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .	делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью
SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .

@mytilus 87 / 86 / 27 Регистрация: 04.10.2012 Сообщений: 355

	Как рассчитать размер SSL-данных? 06.10.2015, 14:17. Показов 732. Ответов 7 Метки нет (Все метки) Приветствую! Пишу TCP-сервер с поддержкой SSL. Для упрощения реализации хочу выделить память под входящее сообщение, равную максимально возможной длине такого сообщения. Ну, чтобы не обрабатывать данные "кусками". Отсюда два вопроса, ответ на которые я не смог найти. Во-первых: какова максимальная длина сообщения от клиента во время handshake? А во-вторых: если после handshake клиент должен отправлять на сервер данные не длиннее X байтов, можно ли рассчитать максимальную длину кодированных данных? 0

@mytilus 87 / 86 / 27 Регистрация: 04.10.2012 Сообщений: 355
	07.10.2015, 14:26 [ТС]
	Сервер работает в блокирующем режиме. Если я правильно понимаю, в этой ситуации сокет будет ждать окончания входящего сообщения, прежде чем вернет управление программе. 0

Убежденный Ушел с форума 16481 / 7444 / 1187 Регистрация: 02.05.2013 Сообщений: 11,616 Записей в блоге: 1
	07.10.2015, 14:34
	Ну ок. Придет "сообщение" в 1 байт, что тогда ? 0

@mytilus 87 / 86 / 27 Регистрация: 04.10.2012 Сообщений: 355
	07.10.2015, 14:48 [ТС]
	Как вариант, сервер просто закроет соединение, поскольку "знает", что сообщение в 1 байт быть не должно. 0

Убежденный Ушел с форума 16481 / 7444 / 1187 Регистрация: 02.05.2013 Сообщений: 11,616 Записей в блоге: 1
	07.10.2015, 14:54
	Значит, это неправильный сервер. Потому что клиент не может гарантировать, что на сервер не придет 1 байт. Никак. 0

@mytilus 87 / 86 / 27 Регистрация: 04.10.2012 Сообщений: 355
	07.10.2015, 15:08 [ТС]
	1 байт для меня - не проблема. Вот 1 гигабайт - это уже другое дело. Разверну свой вопрос. Пишу под Win. Когда клиент инициирует соединение, сервер полученные данные отправляет в Schannel для формирования handshake-ответов. Когда handshake завершен и кодированное соединение налажено, все сообщения клиента отправляются в Schannel для декодирования, после чего парсятся сервером. Но и в первом и во втором случае Schannel может вернуть ошибку incomplete message, мол, буфер оказался маловат, заберите оставшуюся часть сообщения. Если бы я знал максимально необходимую длину буфера под мои нужды, то такая ошибка сигнализировала о том, что клиент отправляет слишком длинное сообщение, которое сервер все равно не поймет. Тогда я не стал бы заморачиваться с этим конкретным клиентом и отвязался от него, так как он шлет какую-то чушь. 0

@mytilus 87 / 86 / 27 Регистрация: 04.10.2012 Сообщений: 355
	09.10.2015, 16:46 [ТС]
	В общем, углубившись в документацию протокола TLS, я понял, что моя затея не достойна реализации. Хотя бы потому, что во время handshake клиент сообщает серверу о поддерживаемых им (клиентом) методах шифрования. Длина списка с этими методами будет варьироваться от клиента к клиенту. Конечно, их число конечно, более того - под ID метода выделено лишь два байта, а это значит, что вариантов больше 0xFFFF быть не может. Следовательно, для буфера под handshake достаточно выделить 0x20000 байтов под этот список + еще около 100-200 байтов под сопутствующую информацию (флаг handshake, версия TLS, timestamp, имя хоста и пр.). Безусловно, ~128 КБ памяти под одно соединение - вещь вполне подъемная. Но дальше от клиента пойдут запросы, длина которых зависит от шифра, на котором условились общаться клиент и сервер. И здесь рушатся все желания вычислять максимально возможную длину шифрованных данных. Увы, но, по ходу дела, придется работать с "кусками". 0