Preciso implementar SSL para transmissões entre minha aplicação e o Sql Server 2008.
Estou usando o Windows 7, Sql Server 2008, Sql Server Management Studio e meu aplicativo está escrito em c#.
Eu estava tentando seguir a página do MSDN sobre criação de certificados eesseem 'Encrpyt para um cliente específico', mas fiquei irremediavelmente confuso. Preciso de alguns pequenos passos para avançar no caminho para implementar a criptografia com sucesso.
Primeiro, não entendo o MMC. Vejo muitos certificados lá... são esses certificados que eu deveria usar para minha própria criptografia ou estão sendo usados para coisas que já existem? Outra coisa, presumo que todos esses certificados sejam arquivos localizados no meu computador local, então por que existe uma pasta chamada 'Pessoal'?
Segundo, para evitar o problema acima, fiz uma pequena experiência com um assembly autoassinado. Conforme mostrado no link do MSDN acima, usei SQL executado em SSMS para criar um certificado autoassinado. Então usei a seguinte string de conexão para conectar:
Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True
Conectado, funcionou. Então excluí o certificado que acabei de criar e ainda funcionou. Obviamente nunca fez nada, mas por que não? Como eu saberia se está realmente "funcionando"? Acho que posso estar perdendo uma etapa intermediária para (de alguma forma?) retirar o arquivo do SSMS e colocá-lo no cliente.
Não sei nem um pouco o que estou fazendo, então qualquer ajuda, conselho, comentários, referências que você possa me dar serão muito apreciados.
Agradeço antecipadamente. :)
Responder1
Se entendi corretamente as especificações do MSDN, tudo que você precisa é especificar na connection string Encrypt=True;TrustServerCertificate=True. Isso significa que o cliente solicita criptografia eestá disposto a aceitar qualquer certificado que o servidor possa usar. O servidor sempre possui um certificado autoassinado gerado na inicialização do servidor para uso, se nada mais estiver disponível. Se o cliente estiver disposto a aceitarqualquercertificado, então ele aceitará o autoassinado temporário desse servidor, é tão bom quanto qualquer outro.
O que tal configuração fornece é um canal de comunicação criptografado entre seu aplicativo e seu servidor, um canal que não pode ser facilmente ouvido. No entanto, o canal está aberto a um ataque malicioso do tipo man-in-the-middle. Se um invasor conseguir enganar o cliente para se conectareleem vez do servidor (por exemplo, por ter controle dos registros DNS, mais exatamente o IP do servidor DNS que o cliente usará, que é uma configuração DHCP trivial para controlar), então o invasor pode apresentarqualquercertificado e o cliente irá aceitá-lo, ele poderá então fazer a autenticação completa de ida e volta com o cliente, obtendo assim o nome de usuário e a senha SQL usados, então ele poderá se conectar ao verdadeiro servidor e encaminhar toda a comunicação, com um veja gratuitamente todo o conteúdo. O cliente nunca saberá que está sendo 'monitorado'. Este é o ataque do tipo “man-in-the-middle”.
Para evitar a situação acima, o clientedeve removera TrustServerCertificate=Truepartir da cadeia de conexão. Uma vez feito isso, o certificado usado pelo servidortemter a confiança do cliente, e é aí que surgem todas as complicações. Se você concorda com uma configuração mais fraca na qual você tem um tráfego criptografado, mas vocêentenderque vocêpoderiaesteja sujeito a um ataque man-in-the-middle e você esteja bem com isso, então use a TrustServerCertificate=Trueconfiguração muito mais simples. Se não, infelizmente você deve realmente entender o que está fazendo e não é trivial. Se os dados forementãoimportante, então talvez desembolsar dinheiro para um certificado VeriSign, Thawte ou GlobalSign (sendo estas as três raízes em que todos os clientes Windows confiam) para o seu servidor (~$500/ano) não seja tão estranho.
Responder2
"Pessoal" é um nome enganoso para o armazenamento de certificados. Quando você estiver no MMC, se vir um certificado que pode ser selecionado, provavelmente você está bem. Eu recomendo usar um certificado real. Pode ser um certificado criado internamente usando o Microsoft Certificate Server ou adquirido de um provedor de certificados. Eu não usaria um certificado autoassinado. O serviço de instância do SQL Server também deve ser reiniciado para que entre em vigor.
Algumas dicas gerais:
Se você impor criptografia no cliente, toda comunicação SQL no cliente deverá usar criptografia em nível de transporte.
Se você impor a criptografia no servidor, toda a comunicação SQL dessa instância deverá usar criptografia em nível de transporte.
Independentemente da configuração escolhida (seletiva ou imposta), seu aplicativo ainda requer suporte para as diversas opções de conexão. Como a palavra-chave de conexão Criptografar.
Eu pessoalmente descobri que o cliente SQL Native fornece mensagens de erro mais descritivas do que o cliente SQL integrado, mas você pode usar/impor criptografia com qualquer um deles.
A documentação da Microsoft é um pouco incompleta, mas há alguns artigos bons:
Usando seletivamente conexão segura com SQL Server
Link
Como habilitar a criptografia SSL para uma instância do SQL Server usando o Microsoft Management Console
http://support.microsoft.com/kb/316898
Usando palavras-chave de string de conexão com SQL Server Native Client
http://msdn.microsoft.com/en-us/library/ms130822.aspx