Для защиты своих клиентов Microsoft, как и большинство других разработчиков СУБД, использует протокол SSL. Однако мало кто знает, что в отличие от других СУБД MsSQL инкапсулирует SSL-хендшейк внутри TDS-фрейма.

Вероятно, данный трюк выполнен намеренно, с целью сократить число потенциальных угроз на серверы MS, так как разработчики сегодня пользуются SSL в простом сочетании уровней протокола, в режиме полной инкапсуляции. Это и проще, и универсальнее, в связи с тем, что включение-отключение SSL не требует дополнительных зависимостей внутри основного протокола.

Шифрование в MsSQL работает в 2-х режимах: защита на стадии авторизации и полная защита соединения. В обоих случаях диалог начинается с обмена настройками между клиентом и сервером: клиент посылает свой пакет PRELOGIN и принимает аналогичный пакет от сервера. Затем клиент посылает свой первый пакет хендшейка, предварительно инкапсулируя его в TDS под видом PRELOGIN. Все последующие пакеты SSL аналогично заворачиваются в TDS, пока не будет завершен хендшейк.

При этом первый же и все последующие аппликативные пакеты SSL клиент присылает уже в чистом виде без TDS. Этот пакет инкапсулирует запрос LOGIN7-авторизация клиента. Непосредственно после LOGIN7 и начинаются различия между режимами работы шифрования. В первом режиме шифрование с помощью протокола SSL заканчивается, и весь последующий трафик между клиентом и сервером идет без него, а во втором режиме шифрование продолжается вплоть до закрытия сессии.

Следует заметить, что на самом деле сервер может работать и без шифрования, но официальные клиенты MsSQL не предоставляют такую возможность. Почему это важно? Наличие шифрования в канале в том или ином виде препятствует пассивному сбору и анализу его трафика – сниффингу, а это одна из наших основных функций.

В случае, когда нет возможности модифицировать трафик, функциональность сниффера значительно ограничена. В первую очередь это касается всех шифров, которые используют эфемерные ключи. К этой категории относятся шифры с модификаторами ECDHE и DHE, такие как:

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS_EXPORT1024_DES_SHA DHE_DSS_DES_CBC_SHADHE_DSS_3DES_EDE_CBC_SHA

Более того, для расшифровки трафика приходится пользоваться низкоуровневым API при работе с OpenSSL. В свою очередь это пока требует от нас постоянной поддержки SSL-сниффера в актуальном состоянии от версии к версии SSL.

Вместе с тем для работы SSL-сниффера нашему клиенту на стороне прокси (файрволла) необходимо установить ключ сервера. Это еще одно препятствие на пути к защите информации, поскольку клиент должен доверить нам гарант безопасности своего сервера или отказаться от работы в режиме сниффера с официальным клиентским ПО от Microsoft для MsSQL, например, таким как Microsoft SQL Server Management Studio.

Что касается эфемерных ключей, их можно отключить на стороне сервера MsSQL. Криптопровайдер Windows позволяет это делать в штатном режиме.

Таким образом, несмотря на явные ограничения протокола со стороны Microsoft, сниффер для Microsoft SQL Server все же включен в состав файрволла. Мы постарались сделать так, чтобы нашим клиентам было удобно им пользоваться.

Комментарии