Использование SSL с Netty в начале соединения, а затем его отключение

Я пишу серверное приложение и его клиентский аналог, которые оба используют Netty для сетевого уровня. Я сталкиваюсь с типичными проблемами безопасности при отправке пароля с клиента на сервер, поэтому я решил, что SSL — самый безопасный способ сделать это.

Я знаю о securechat и буду использовать его для соответствующей модификации моих пайплайнов. Однако я также хотел бы отключить SSL после передачи пароля и подтвердить, чтобы сэкономить несколько драгоценных циклов процессора на стороне сервера, который может быть занят многими другими клиентами. В документации ChannelPipeline указано следующее:

«После присоединения соединение между каналом и конвейером является постоянным; канал не может ни присоединить к нему другой трубопровод, ни отсоединить от него текущий трубопровод».

Идея состоит в том, чтобы не менять конвейер на лету, что запрещено, а каким-то образом сообщить SslHandler в конвейере, что в какой-то момент он должен прекратить шифрование сообщений. Я думал о создании класса, наследуемого от SslHandler, переопределяющего его функцию handleDownstream для вызова context.sendDownstream(evt) после некоторого момента связи. .

Вопрос 1. Является ли это плохой идеей, то есть отключением SSL в какой-то момент?

Чтобы позволить блоку в конвейере (скажем, Decoder) сообщать другому блоку (скажем, SslHandler), что с этого момента он должен изменить свое поведение, я подумал, что могу создать, скажем, , AtomicBoolean в моей ChannelPipelineFactory getPipeline() и передать его конструктору как Decoder, так и SslHandler.

Вопрос 2. Является ли это плохой идеей, то есть разделением состояния между блоками конвейера? Я беспокоюсь, что могу испортить многопоточность Netty здесь: блоки конвейера работают с одним сообщением, по одному за раз? то есть: первый блок ждет завершения последнего блока, прежде чем вытащить следующее сообщение?

ИЗМЕНИТЬ:

Боже мой, это из ChannelPipeline страница, которую я посещал много раз и цитировал в этом же вопросе:

«ChannelHandler может быть добавлен или удален в любое время, потому что ChannelPipeline является потокобезопасным. Например, вы можете вставить SslHandler перед обменом конфиденциальной информацией и удалить его после обмена».

Таким образом, это отвечает на вопрос 2 об изменении content конвейера на лету, а не самой ссылки на конвейер.


ssl multithreading netty
person gsimard    schedule 27.11.2012    source источник
comment
Теперь я понимаю, что задавать два вопроса в одном посте было плохой идеей, поскольку теперь я не могу принять два ответа, каждый из которых касается одного вопроса.   -  person gsimard    schedule 27.11.2012

Ответы (3)


arrow_upward
3
arrow_downward

Я не уверен в эффективности отключения SSL после установки, но я думаю, что вы неверно истолковали изменчивость конвейера. Как только данный канал связан с конвейером, эта ассоциация становится неизменной. Однако обработчики в конвейере можно безопасно модифицировать. То есть вы можете добавлять и удалять обработчики, как того требует ваш протокол. Соответственно, вы сможете удалить обработчик SSL после того, как он выполнит свою задачу.

person Nicholas    schedule 27.11.2012
comment
Я более чем неправильно истолковал эту изменчивость: кажется, я упустил из виду ту часть документации, которая непосредственно отвечает на мой второй вопрос. Я отредактировал свой вопрос соответственно. - person gsimard; 27.11.2012

arrow_upward
3
arrow_downward

Вы можете удалить SslHandler из конвейера с помощью ChannelPipeline.remove(..), тогда ваше соединение должно превратиться в открытый текст. Пожалуйста, отправьте сообщение об ошибке, если это не работает - мы на самом деле не пробовали этот сценарий в производстве :-)

person trustin    schedule 03.12.2012

arrow_upward
1
arrow_downward

Я не уверен насчет Netty, но, в принципе, вы действительно можете продолжать работать с обычным трафиком по тому же TCP-соединению. Есть несколько минусов:

  • Только аутентификация будет защищена. MITM может выполнять действия, не предусмотренные пользователем. (Это в некоторой степени похоже на использование HTTP Digest: учетные данные защищены, а объекты запроса/ответа — нет.)

  • #P3# <блочная цитата> #P4# #P5#

Хотя может иметь смысл сэкономить несколько циклов ЦП, большая часть накладных расходов SSL/TLS связана с рукопожатием, которое вы все равно будете выполнять. Симметричные криптографические операции, используемые для фактического шифрования данных, намного дешевле. (Вы должны попытаться измерить эти накладные расходы, чтобы увидеть, действительно ли это проблема.)

person Bruno    schedule 27.11.2012