Estou usando o Standard Editoin do SQL Server 2022. Ele tem uma opção adicional de configuração Force Strict Encryption. Eu configurei o mesmo no lado do servidor.
Na máquina cliente, usando SSMS, consigo conectar e acessar a tabela de usuários do banco de dados. Mas não estou conseguindo fazer o mesmo em um aplicativo C++. Abaixo está o código de exemplo do que estou tentando:
auto pDatabase = new CDatabase();
CString connString = L"DRIVER={ODBC Driver 18 for SQL Server};Network=DBMSSOCN;DATABASE=TESTTDE;Encrypt=strict;TrustServerCertificate=no;HostNameInCertificate=10.100.200.300;Mars_Connection=yes;SERVER=10.100.200.300\\TDE,2144;UID=Supervisor;PWD=password;";
auto reply = pDatabase->OpenEx(connString, CDatabase::noOdbcDialog);
CStringArray userNameList;
CString strUserName;
CStringW strUserNameW;
CString SQLString = L"select * from TESTTDE.dbo.UserTable;";
CRecordset userRecords(pDatabase);
userRecords.Open(CRecordset::forwardOnly, SQLString, CRecordset::readOnly);
while (!userRecords.IsEOF())
{
userRecords.GetFieldValue(L"Name", strUserNameW);
strUserName = CW2A(strUserNameW.Trim());
userNameList.Add(strUserName.Trim());
userRecords.MoveNext();
}
userRecords.Close();
userRecords.Open
gera uma exceção e não consigo acessar o banco de dados. Alguém pode me dar uma luz sobre isso? O que eu poderia tentar para fazer isso funcionar?
Estou usando um certificado autoassinado. Ele funciona se eu usar Force Encryption sem habilitar Force Strict Encryption no servidor.
Exceção no lado do cliente:
O fluxo do protocolo de fluxo de dados tabulares (TDS) de entrada está incorreto. O fluxo terminou inesperadamente. Estado:28000,Nativo:4002,Origem:[Microsoft][Driver ODBC 18 para SQL Server][SQL Server]
Log do servidor:
O SQL Server ou o endpoint está configurado para aceitar somente conexões estritas (TDS 8.0 e acima). A conexão foi fechada.
Existe algo que impeça o uso de certificado autoassinado com criptografia Strict? Para a mesma configuração no lado do servidor, consigo executar consulta no lado do cliente do SSMS e recuperar dados da tabela. Somente de um aplicativo de amostra consigo conectar, mas não executar consulta.
Algumas observações adicionais: Usando APIs SQL de baixo nível de um aplicativo de exemplo, consegui buscar dados do servidor mesmo quando Force Strict Encryption estava habilitado. O código para o mesmo é adicionado abaixo:
SQLHANDLE env;
SQLHANDLE dbc;
SQLHANDLE stmt;
SQLRETURN ret;
SQLWCHAR* connStr = (SQLWCHAR*)L"Driver={ODBC Driver 18 for SQL Server};Server=10.100.200.300\\TDE;Database=TESTTDE;Uid=Supervisor;Pwd=password;Encrypt=strict;";
// Allocate environment handle
ret = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env);
if (ret == SQL_ERROR) {
std::wcerr << L"Error allocating environment handle." << std::endl;
return;
}
// Set the ODBC version environment attribute
ret = SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0);
if (ret == SQL_ERROR) {
checkDiagnostic(env, SQL_HANDLE_ENV);
SQLFreeHandle(SQL_HANDLE_ENV, env);
return;
}
// Allocate connection handle
ret = SQLAllocHandle(SQL_HANDLE_DBC, env, &dbc);
if (ret == SQL_ERROR) {
checkDiagnostic(env, SQL_HANDLE_ENV);
SQLFreeHandle(SQL_HANDLE_ENV, env);
return;
}
// Connect to the data source
ret = SQLDriverConnectW(dbc, NULL, connStr, SQL_NTS, NULL, 0, NULL, SQL_DRIVER_COMPLETE);
if (ret == SQL_ERROR) {
checkDiagnostic(dbc, SQL_HANDLE_DBC);
SQLFreeHandle(SQL_HANDLE_DBC, dbc);
SQLFreeHandle(SQL_HANDLE_ENV, env);
return;
}
// Allocate statement handle
ret = SQLAllocHandle(SQL_HANDLE_STMT, dbc, &stmt);
if (ret == SQL_ERROR) {
checkDiagnostic(dbc, SQL_HANDLE_DBC);
SQLDisconnect(dbc);
SQLFreeHandle(SQL_HANDLE_DBC, dbc);
SQLFreeHandle(SQL_HANDLE_ENV, env);
return;
}
// Execute a query
SQLWCHAR* query = (SQLWCHAR*)L"SELECT * FROM UserTable";
ret = SQLExecDirectW(stmt, query, SQL_NTS);
if (ret == SQL_ERROR) {
checkDiagnostic(stmt, SQL_HANDLE_STMT);
}
else
{
SQLWCHAR name[256];
while (SQLFetch(stmt) == SQL_SUCCESS) {
ret = SQLGetData(stmt, 1, SQL_C_WCHAR, name, sizeof(name), NULL);
if (SQL_SUCCEEDED(ret)) {
AfxMessageBox((LPCTSTR)name);
}
}
}
// Clean up
SQLFreeHandle(SQL_HANDLE_STMT, stmt);
SQLDisconnect(dbc);
SQLFreeHandle(SQL_HANDLE_DBC, dbc);
SQLFreeHandle(SQL_HANDLE_ENV, env);
Suspeito que a API da classe MFC CRecordset::Open() tenha algum problema no suporte ao TDS 8.0.
Você parece estar um pouco confuso sobre como o TLS e os certificados devem funcionar com o SQL Server.
Encrypt=no
significa não impor criptografia, mas aceitá-la se forçada pelo servidor.Encrypt=yes
oumandatory
significa impor criptografia mesmo que o servidor não a imponha.TrustServerCertificate=yes
significa ignorar o nome SAN no certificado. Isso é obviamente inseguro e não muito melhor do que não criptografar nada.Sem essa opção, o nome com o qual você se conecta deve corresponder ao SAN no certificado, que no seu caso é um endereço IP por algum motivo.
Encrypt=strict
significa impor as correspondências de nome SAN (ou fornecerHostNameInCertificate
uma diferente). Também impõe o TDS 8.0 e funciona somente no SQL2022+.TrustServerCertificate=yes
é ignorado com esta opção. Você pode fornecerServerCertificate=pathOfCertificate
um certificado real para corresponder, mas isso pode ser bem difícil de manejar.Force encryption
significa que todas as conexões devem ser criptografadas. Se o cliente confia no certificado deste servidor depende de sua própria string de conexão, como acima.Force Strict Encryption
significa que todas as conexões devem usarstrict
criptografia como acima e, portanto, esses clientes não podem usarTrustServerCertificate=yes
.Então, no seu caso, você tem um certificado autoassinado. Isso significa que você deve usar
TrustServerCertificate=yes
and você pode usarEncrypt=yes
orno
, mas nãostrict
. O lado do servidor pode usarForce encryption
but notForce Strict Encryption
.Ou você pode exportar o certificado autoassinado para o cliente (você só pode fazer isso com seu próprio certificado autoassinado, não com o certificado automático). Então você ainda usa
strict
criptografia e usaServerCertificate=pathOfCertificate
para fornecer seu caminho no cliente. Isso pode ficar muito impraticável com muitos clientes para atualizar.Você ficaria muito melhor com um certificado assinado corretamente, por uma CA pública ou uma CA privada confiável. Então você pode impor
strict
criptografia. Conecte-se usando um nome DNS, não um endereço IP, pois nenhuma CA que se preze lhe dará um certificado baseado em IP.Para mais informações, veja a documentação aqui , aqui e aqui .
Além disso, você está se conectando usando um nome de instância e um número de porta. Isso não é padrão: o nome da instância será ignorado e somente o número da porta será usado. Use apenas um ou outro.
Acredito que o problema seja sua string de conexão, onde diz
Encrypt=strict
. Os únicos valores válidos para oEncrypt
atributo sãono
,yes
,false
, etrue
, até onde eu sei:yes
para cada exemplo de string de conexão que usa criptografia. Aqui está o link direto para o exemplo básico de criptografia . (Não deve ser confundido comAlways Encrypted
, um recurso diferente do SQL Server.)true
ouyes
na seção Habilitar Criptografia .Encrypt=yes
em todos os exemplos.Meu palpite é que você tente
Encrypt=yes
e que o servidor determine que tipo de criptografia está sendo aplicada (por exemplo, estrita) com base em como você configurou o servidor.Observe que o acima é verdadeiro somente para drivers ODBC da versão 17 e anteriores.
strict
É válido na versão 18+ .Finalmente encontrei uma possível solução para o problema. Conforme mencionado na consulta, CRecordset::Open() estava causando o problema. Acabei de passar pelos parâmetros suportados e vi que o terceiro parâmetro tem um possível valor executeDirect . O comentário para o mesmo menciona "Execute SQL diretamente em vez de executar preparado". Tentei usar o mesmo e consegui buscar dados usando CRecordset. userRecords.Open(CRecordset::forwardOnly, SQLString, CRecordset::executeDirect); . Fecharei esta consulta marcando-a como resposta se eu conseguir alguma documentação da Microsoft para confirmar.