IBProvider Developer's Blog

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 (подключение к базе).

А ведь по-началу даже начинало казаться, что новый механизм авторизации тринадцатого протокола выглядит вполне логичным и предсказуемым.

Ан нет.

В следующий раз, когда начнет казаться, сразу начну креститься.