autenticación SSL al comparar la huella dactilar del certificado?

Question

Pregunta para todos los expertos en SSL:

Tenemos un dispositivo integrado con un pequeño servidor web y podemos instalar nuestros propios certificados SSL autofirmados en él. El cliente está escrito en .NET (pero eso no importa mucho).

¿Cómo puedo autenticar el dispositivo en .NET? ¿Es suficiente con comparar la huella digital del certificado con una entrada conocida en la base de datos?

Según tengo entendido, la huella digital es un hash de todo el certificado, incluida la clave pública. Un dispositivo que simula ser mi dispositivo podría, por supuesto, enviar el mismo certificado público, pero no podría conocer la clave privada, ¿verdad?

¿O tengo que crear mi propia cadena de confianza, crear mi propio certificado raíz de CA, firmar el certificado del servidor web e instalarlo en el cliente?

Answer 1

Lo que usted propone es, en principio, está bien. Se usa, por ejemplo, durante key signing parties. Aquí los participantes generalmente solo intercambian su nombre y las huellas dactilares de sus claves públicas y se aseguran de que la persona en la fiesta realmente sea quien reclame. Solo es más fácil verificar las huellas digitales que verificar una clave pública larga.

Otro ejemplo es el llamado self certifying file system. Aquí nuevamente, solo los hashes de las claves públicas se intercambian a través de un canal seguro. (Es decir, estos hash están incrustados en las URL.) En este esquema, las claves públicas no tienen que enviarse de forma segura. El receptor solo tiene que verificar que el hash de las claves públicas coincida con los hashes incrustados en las URL. Por supuesto, el receptor también debe asegurarse de que estas URL provengan de una fuente confiable.

Este esquema y lo que usted propone son más simples que usar una CA. Pero hay una desventaja. Debe asegurarse de que su base de datos con hashes sea auténtica. Si su base de datos es grande, esto también será difícil. Si usa CA, solo debe asegurarse de que las claves raíz sean auténticas. Esto generalmente simplifica la gestión de claves de manera significativa y, por supuesto, es una de las razones por las que los esquemas basados ​​en CA son más populares que, p. el sistema de archivo de autocertificación mencionado anteriormente.

Answer 2

De la misma manera en que no debería considerar dos objetos iguales porque sus códigos hash coinciden, no debe considerar un certificado como auténtico solo porque su huella digital aparece en una lista de "conocidos" huellas digitales del certificado ".

Las colisiones son una realidad con algoritmos hash, incluso buenos, y debe evitar la posibilidad de que un atacante motivado pueda crear un certificado deshonesto con un hash de huellas digitales correspondiente. La única manera de protegerse de eso es verificar la validez del certificado en sí, es decir, verificar la cadena de confianza como está implicando en su última declaración.

Answer 3

corta:

Bueno, en teoría, a continuación, hacer exactamente lo que hace una autoridad de certificación para usted. Entonces debería estar bien.

más larga:

Cuando una autoridad de certificación firma su solicitud de clave pública/certificado/certificado de no firmar los datos del certificado enteros. Pero solo el valor hash calculado de todos los datos del certificado. Esto mantiene la firma pequeña.

Cuando no desee establecer su propia CA o utilizar una comercial/gratuita - comparando la huella digital con la que usted confía, obtendrá la segunda configuración más confiable. La solución más confiable sería comparar el certificado completo, porque también lo protege de los ataques de colisión hash.

Como los otros tipos aquí indicados, debes asegurarte de usar un algoritmo hashing seguro/seguro. SHA-1 ya no es seguro.

informaciones más detalladas a este tema:

• https://security.stackexchange.com/questions/6737
• https://security.stackexchange.com/questions/14330