Страница 1 из 1

FBScanner и Firebird 3.0

Добавлено: 08 ноя 2012, 01:31
Dimitry Sibiryakov
ЕМНИП, в FB 3.0 то ли обещают то ли уже сделали шифрование сетевого траффика. А FBScanner готов к такому повороту событий?

Re: FBScanner и Firebird 3.0

Добавлено: 08 ноя 2012, 01:58
hvlad
Dimitry Sibiryakov писал(а):в FB 3.0 то ли обещают то ли уже сделали шифрование сетевого траффика
Уже сделали

Re: FBScanner и Firebird 3.0

Добавлено: 08 ноя 2012, 09:27
Oleg_M
И да и нет.
ДА - потомучто делаю свой плагин и перехватом траффика не будет смысла заниматься, плагин входит в поставку FBScanner-a.
а нет - потомучто если траффик зашифрован - расшифровать его будет как минимум сложно.

Впрочем, в IB2009 тоже обещано было шифрование траффика.
Но то ли оно включается опционально, и по-умолчанию выключено, то ли еще чего...
FBScanner-у не потребовалось никаких доработок после IB7.0. Все работает по-прежнему и в IB XE.
Разве что авторизация проходит в два раундтрипа.

Перехват и расшифровка TCP-траффика это от бедности. Неужто я стал бы делать такой хак, если бы был штатный механизм трейса в 2005г.
Я даже создавал тему на gmane "хочется серверного API".

Re: FBScanner и Firebird 3.0

Добавлено: 08 ноя 2012, 13:43
kdv
Но то ли оно включается опционально, и по-умолчанию выключено, то ли еще чего...
разумеется, в IB с версии 2009 шифрование трафика (OTW) включается только явно, и идет оно через SSL. И без этого шифровать трафик можно было чем угодно, в т.ч. zebedee.
http://www.ibase.ru/devinfo/zebedee.htm

а про OTW в InterBase - тут: http://interbase.blogspot.ru/2012/05/interbase.html

Re: FBScanner и Firebird 3.0

Добавлено: 08 ноя 2012, 15:48
Dimitry Sibiryakov
Может, стоит закинуть в трекер пожелание, чтобы пакет шифровался не полностью, оставив открытой часть, нужную для работы прокси: операцию и установку доп.соединения для эвентов?..

Re: FBScanner и Firebird 3.0

Добавлено: 08 ноя 2012, 20:49
Oleg_M
ты все думаешь, как его приспособить к балансировке нагрузки?

... Так уж устроен протокол, что одной только операции будет мало:

Вариант 1.
Как минимум, надо чтобы передавалась длина пакета. Сейчас смещение к началу следующего логического пакета, (в начале которого стоит код операции) надо довольно долго и мучительно вычислять. Особенно op_fetch.
При том, что содержимое самого fetch пакета совершенно неинтересно, и не нужно FBScanner-у. Но раз уже такое вычисление происходит, FBScanner подсчитывает кол-во прошедших строк. Которое нужно только для "красоты". Я уж молчу о том, что после того как FBScanner стал производить полную расшифровку протокола, нагрузка на CPU увеличилась на порядок.
(полная расшифровка появилась в версии FBScanner 2.5, без этого невозможно было понять, что происходит в 11ом протоколе FB2.1 и старше)

Но даже если так, то знание операции мало: стейтментов (или тр-ций) может быть несколько. Какому именно сейчас делается prepare - важно знать.

Вариант 2.
Интересно, а как сейчас происходит шифрация протокола? Полностью пакуется логический пакет?
Если да - то зачем? По сути, шифровать протокол нет никакого смысла.
Достаточно шифровать данные:
а) данные внутри fetch (каждый столбец - отдельно)
б) внутри передачи параметров (алгоритм тот же самый, как с fetch)
в) блобы
г) под вопросом - текст SQL запроса.

Если пойти по этому варианту, доработки в FBScanner будут ненужны :)))
Пакеты не изменятся, а сами данные по барабану, в общем-то... правда, логирование всеравно накроется.

Re: FBScanner и Firebird 3.0

Добавлено: 09 ноя 2012, 15:39
Dimitry Sibiryakov
Скорее прицениваюсь: стоит ли сваять свой или дешевле будет закинуть тикет к Firebird, как говорил ДЕ... У них там внутре тоже уже есть готовый редиректор, так что научить его раскидывать коннекты на несколько хостов в зависимости от количества неотвеченных пакетов не должно быть слишком тяжко...