Necesito implementar SSL para transmisiones entre mi aplicación y Sql Server 2008.
Estoy usando Windows 7, Sql Server 2008, Sql Server Management Studio y mi aplicación está escrita en C#.
Estaba intentando seguir la página de MSDN sobre la creación de certificados yesteen 'Encrpyt para un cliente específico', pero me confundí irremediablemente. Necesito algunos pequeños pasos para avanzar en el camino hacia la implementación exitosa del cifrado.
Primero, no entiendo MMC. Veo muchos certificados allí... ¿son estos certificados los que debería usar para mi propio cifrado o se están usando para cosas que ya existen? Otra cosa, supongo que todos estos certificados son archivos que se encuentran en mi computadora local, entonces, ¿por qué hay una carpeta llamada "Personal"?
En segundo lugar, para evitar el problema anterior, hice un pequeño experimento con un ensamblado autofirmado. Como se muestra en el enlace de MSDN anterior, utilicé SQL ejecutado en SSMS para crear un certificado autofirmado. Luego utilicé la siguiente cadena de conexión para conectarme:
Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True
Se conectó, funcionó. Luego eliminé el certificado que acababa de crear y todavía funcionó. Obviamente nunca hizo nada, pero ¿por qué no? ¿Cómo puedo saber si realmente está "funcionando"? Creo que me falta un paso intermedio para (¿de alguna manera?) sacar el archivo de SSMS y colocarlo en el cliente.
No sé lo que estoy haciendo en lo más mínimo, por lo que cualquier ayuda, consejo, comentario o referencia que puedan brindarme serán muy apreciados.
Gracias de antemano. :)
Respuesta1
Si entiendo correctamente la especificación de MSDN, todo lo que necesita es especificarla en la cadena de conexión Encrypt=True;TrustServerCertificate=True. Esto significa que el cliente solicita cifrado yestá dispuesto a aceptar cualquier certificado que el servidor pueda utilizar. El servidor siempre tiene un certificado autofirmado generado en el momento del inicio del servidor para usar, si no hay nada más disponible. Si el cliente está dispuesto a aceptarcualquiercertificado, entonces aceptará el autofirmado temporal de ese servidor, que es tan bueno como cualquier otro.
Lo que proporciona dicha configuración es un canal de comunicación cifrado entre su aplicación y su servidor, un canal que no se puede dejar caer con facilidad. Sin embargo, el canal está abierto a un ataque de intermediario malicioso. Si un atacante puede engañar al cliente para que se conectea élen lugar del servidor (por ejemplo, al tener control de los registros DNS, más exactamente la IP del servidor DNS que usará el cliente, que es una configuración DHCP trivial para controlar), entonces el atacante puede presentarcualquiercertificado y el cliente lo aceptará, luego puede realizar la autenticación completa de ida y vuelta con el cliente, obteniendo así el nombre de usuario y la contraseña de SQL utilizados, luego puede conectarse al servidor verdadero y reenviar y recibir toda la comunicación, con un mira gratis todo el contenido. El cliente nunca sabrá que está siendo "monitoreado". Este es el ataque del "hombre en el medio".
Para evitar la situación anterior, el clientedebe eliminarel TrustServerCertificate=Truede la cadena de conexión. Una vez hecho esto, el certificado utilizado por el servidortieneconfiar en el cliente, y aquí es cuando surgen todas las complicaciones. Si está de acuerdo con una configuración más débil en la que tiene un tráfico cifrado pero noentenderque TúpuedeSi está sujeto a un ataque de intermediario y está de acuerdo con ello, utilice la TrustServerCertificate=Trueconfiguración mucho más simple. Si no es así, lamentablemente debes entender realmente lo que estás haciendo y no es trivial. Si los datos sonentoncesimportante, entonces tal vez desembolsar el dinero para un certificado VeriSign, Thawte o GlobalSign (éstas son las 3 raíces en las que confía cada cliente de Windows) para su servidor (~$500/año) no sea tan descabellado.
Respuesta2
"Personal" es un nombre engañoso para el almacén de certificados. Cuando esté en MMC, si ve un certificado que se puede seleccionar, probablemente esté bien. Recomiendo usar un certificado real. Puede ser un certificado creado internamente utilizando Microsoft Certificate Server o uno adquirido a un proveedor de certificados. No usaría un certificado autofirmado. El servicio de instancia de SQL Server también debe reiniciarse para que surta efecto.
Algunos consejos generales:
Si aplica el cifrado en el cliente, todas las comunicaciones SQL en el cliente deben utilizar cifrado a nivel de transporte.
Si aplica el cifrado en el servidor, todas las comunicaciones SQL para esa instancia deben utilizar cifrado a nivel de transporte.
Independientemente de la configuración que elija (selectiva o forzada), su aplicación aún requiere soporte para las distintas opciones de conexión. Como la palabra clave de conexión Cifrar.
Personalmente, descubrí que el cliente SQL Native proporciona mensajes de error más descriptivos que el cliente SQL integrado, pero puede usar/imponer el cifrado con cualquiera de los dos.
La documentación de Microsoft es un poco incompleta, pero hay un par de buenos artículos:
Uso selectivo de una conexión segura a SQL Server
Enlace
Cómo habilitar el cifrado SSL para una instancia de SQL Server mediante Microsoft Management Console
http://support.microsoft.com/kb/316898
Uso de palabras clave de cadena de conexión con SQL Server Native Client
http://msdn.microsoft.com/en-us/library/ms130822.aspx