FB3, Win_SSPI, Wire_Crypt=disabled
С пятницей всех.
Продолжая воспроизводить функциональность fbclient.dll (v3) в собственном клиенте для FB3, обнаружил следующие ну очень интересные вещи для SSPI-аутентификации:
При подключении с разрешенным шифрованием трафика (Wire_Crypt=enabled) обмен сообщениями с сервером на этапе инициализации выглядит так:
PROTOCOL: XDR_ENCODE (0) - op_connect (1) PROTOCOL: XDR_DECODE (1) - op_cond_accept (98) PROTOCOL: XDR_ENCODE (0) - op_cont_auth (92) PROTOCOL: XDR_FREE (2) - op_cont_auth (92) PROTOCOL: XDR_DECODE (1) - op_response (9) PROTOCOL: XDR_ENCODE (0) - op_attach (19) PROTOCOL: XDR_DECODE (1) - op_response (9)
А с выключенным шифрованием трафика (Wire_Crypt=disabled) вот так:
PROTOCOL: XDR_ENCODE (0) - op_connect (1) PROTOCOL: XDR_DECODE (1) - op_accept_data (94) PROTOCOL: XDR_ENCODE (0) - op_attach (19) PROTOCOL: XDR_DECODE (1) - op_response (9)
Возникла мысль — куда делась передача данных из третьей строки первого варианта?
Оказалось, во втором случае это делается через op_attach и его DatabaseParameterBuffer (DPB).
В целом, эта два разных способа достижения одного результата — «трафик без шифрования». Шифрование для Win_SSPI собственными средствами сервера и клиента, насколько я понимаю, не поддерживается.
Попытка привести второй вариант к первому, то есть вместо передачи данных через DPB отправлять отдельный пакет (op_cont_auth), не работает — сервер возвращает ошибку «unavailable database».
Собственно говоря, раздражает тот факт, что похоже придется размазывать код аутентификации между op_connect (подключение к серверу) и op_attach (подключение к базе).
А ведь по-началу даже начинало казаться, что новый механизм авторизации тринадцатого протокола выглядит вполне логичным и предсказуемым.
Ан нет.
В следующий раз, когда начнет казаться, сразу начну креститься.
Dmitry Kovalenko on 10 мая, 2019
… логичный и предсказуемый.
Сегодня пользователь провайдера написал, что не получается подключиться к Firebird на Linux.
Провайдер возвращает ошибку «[Subsystem: remote_fb] Received packet with unexpected operation ID: 3.»
ID=3 — это op_accept.
С FB на Windows (с идентичным конфигом) этой проблемы нет.
Забавно что за два с половиной года никто не жаловался. Походу пользователи провайдера держат FB на Windows.