2011-12-23 32 views
7

Estoy trabajando en un proyecto favorito que (eventualmente, cuando esté hecho) permita transferencias seguras de archivos (hay más que solo eso, pero el resto no es particularmente relevante). Me gustaría usar la biblioteca OpenSSL, ya que parece ser la biblioteca de criptografía gratuita más completa (y necesito soporte para encriptación simétrica básica y hash, además de SSL/TLS).SSL/TLS sin certificados

Estoy buscando implementar un esquema de seguridad similar a SSH. Básicamente, un usuario se conecta a mi computadora con TLSv1 (SSLv3.1). Me gustaría que la conexión tenga éxito independientemente de la seguridad. Luego, deseo poder inspeccionar la clave pública (no un certificado completo) que el usuario usó. Esa clave se compararía con claves públicas conocidas, y si coincide, el usuario podría acceder a un determinado conjunto de comandos. Si no coincide, el usuario tendría la opción de usar la conexión para solicitar que se agregue su clave pública a mi colección, pero aparte de eso no podría acceder a mis servicios.

No tengo ninguna necesidad particular de certificados aquí. Sería mucho más simple para mí si pudiera omitir todos los detalles del certificado y trabajar solo con las claves de cifrado sin formato. Esto se debe a que este modelo sigue un modelo de confianza en la web, no el modelo jerárquico utilizado por la mayoría de las conexiones SSL/TLS, por lo que no necesito CA ni certificados firmados.

Desafortunadamente, la documentación de la mayoría de OpenSSL es, bueno, inexistente. Todos los artículos relevantes que encuentro parecen estar ocupados con la configuración de una conexión SSL/TLS "estándar", donde el certificado del servidor se verifica hasta un conjunto de certificados raíz. Esto puede ser útil, pero es difícil para mí descubrir cómo poner en marcha estas conexiones SSL no tradicionales.

¿Alguien puede sugerir algún artículo o documentación que pueda ayudarme a encontrar la manera de lograrlo?

(El uso de OpenSSL no está escrito en piedra, y podría cambiar a otra biblioteca si proporciona una mejor manera de lograr esto, así como hash [SHA-512] y encriptación simétrica [AES]. m con el objetivo de apuntar a Linux, pero estaría bien si el producto final fuera portátil para Windows para que mis amigos también lo puedan usar).

+1

Comparar una clave pública con una lista de claves públicas es esencialmente usar una contraseña, que anula la PKI completa de https y ssl. La sugerencia de crear y usar certificados autofirmados es buena si controla tanto el cliente como el software del servidor (para que pueda configurar la relación de confianza). –

+1

@AdamLiss, no, no es lo mismo que la contraseña: el usuario nunca tiene que enviar la clave privada, mientras que el usuario debería enviar la contraseña. (Y comparar certificados con firma automática en una lista es más o menos lo mismo que comparar sus claves públicas). – Bruno

+0

Aunque no estoy usando la PKI. La idea es que si eres mi "amigo" (tengo tu clave pública/certificado), puedes descargar los archivos (que especifico) de los archivos PLUS de mi computadora que puedo descargar de MIS amigos. El problema es que no se puede ver de dónde vienen los archivos (es decir, si A y B son amigos, B y C son amigos, A puede descargar de C a B, pero no sabe nada de C) . Al menos, esa es la idea en pocas palabras. [OneSwarm] (http://www.oneswarm.org/) me inspiró para este proyecto. – Ethan

Respuesta

3

Para ampliar la respuesta de Eugene (I habría puesto esto como un comentario, pero es un poco largo) ...

Después de haber hecho este tipo de cosas con el FOAF+SSL project (más tarde llamado WebID), el de mantener X .509 certificados hace que la implementación sea más fácil, simplemente porque la mayoría de las pilas SSL/TLS están diseñadas teniendolas en cuenta (y su API lo refleja).

La última vez que revisé FOAF + SSL, los cheques de PKI tradicionales seguían vigentes para que el cliente verificara el certificado del servidor. Otra opción, similar a SSH, sería aceptar la clave/certificado público la primera vez que lo encuentre y advertir al usuario cuando cambie. Esa es más o menos la forma en que SSH funciona de todos modos (en particular, creo que pocas personas realmente comprueban la huella dactilar de la llave la primera vez que la ven).

Teniendo en cuenta sólo el uso de certificado de cliente (aunque algo de esto podría aplicarse a los certificados de servidor de una manera similar):

  • mayoría de las bibliotecas de servidor parecen ser capaces de procesar los certificados X.509, pero que deje cambiar la forma en que se verifican (p. ej.X509TrustManager en Java).
  • Si bien no podrá confiar en nada que diga el certificado de cliente hasta que lo haya verificado de otra manera, podrá insertar información adicional (como un DN de sujeto o nombre alternativo de sujeto para ver quién dice ser el usuario) puede ayudar (a) a los usuarios a organizar sus certs y (b) dar una pista para que el verificador sepa qué buscar. Una clave pública desnuda puede ser difícil de administrar.
  • Varias herramientas de cliente existentes (especialmente navegadores) usan certificados X.509 al realizar autenticación de cliente SSL/TLS. No es necesario hacer mucho para configurar un cliente para que use un certificado autofirmado X.509 (a diferencia de un certificado de una PKI). (Hay muy pocas herramientas que admitan OpenPGP para TLS, no estoy seguro de que puedan usarlo como una forma de certificado de cliente).
  • Como no podrá confiar en el certificado sin controles externos, no importa si es autofirmado o no (es decir, si el emisor y el sujeto son los mismos), al menos, suponiendo que el usuario no le envíe un certificado con el que no estaría de acuerdo (por lo que no tendría ser sellado por su propia clave). Una consecuencia de esto es que puede crear un servicio para emitir certificados con bastante facilidad. La generación de claves en el navegador, por ejemplo, es conveniente para los usuarios que no desean usar los comandos openssl o keytool. Here es un servicio de ejemplo que emitirá un certificado con la SAN que el usuario desea (puede haber versiones más recientes si comprueba con el proyecto FOAF + SSL/WebID). Cualquiera que sea la clave privada o el nombre del emisor que dicho servicio utilice, apenas importa, pero dado que los navegadores están diseñados en torno a PKI tradicionales, no hace que sea fácil usar certificados realmente autofirmados.

También hay problemas a la hora de solicitar un certificado de cliente específico. La especificación TLS 1.1 permite explícitamente el certification authorities vacío (consulte RFC 4346), mientras que el TLS 1.0 guardaba silencio sobre el tema. En la práctica, incluso con TLS 1.0, la mayoría de las herramientas de cliente parecen estar contentas con una lista vacía (ofrecerán más opciones). Si desea que sus certificados para su sistema sean fácilmente identificables, podría usar el mismo DN emisor para todos estos certs, incluso si no están firmados con la misma clave privada en la práctica (nuevamente, ya que ignoraría la firma).

+0

La idea es generar un código de invitación y darle ese código a un amigo. Junto con el código, ingrese algunos detalles sobre mi nuevo amigo (específicamente, una dirección en la que están ubicados, como ethan.no-ip.org). Cuando envían una "aplicación", usan el código de invitación y también pueden enviar un mensaje.El programa verificará para asegurarse de que la invitación sea correcta y que la dirección que ingresé resuelva el origen de la aplicación en el momento en que se creó. También puedo hacerlo para que inspeccione manualmente el mensaje. La idea es que así es como validar nuevos "amigos". – Ethan

2

Utilice certificados autofirmados: esto es lo mismo que las teclas "crudas" pero más fácil administrar (ver this question con respecto a cómo aceptar o no un certificado autofirmado en openssl).

+0

Así que la respuesta sería "No hay una manera fácil de no usar certificados. Es más fácil simplemente usar certificados autofirmados". Supongo que eso funciona. Todavía puedo omitir la carga de los certificados raíz, ¿verdad? Supongo que el seguimiento obvio es: ¿Puedo forzar a OpenSSL a ** solo ** aceptar certificados autofirmados? – Ethan

+0

@Ethan, no tiene sentido restringir el acceso solo a los certificados autofirmados (y rechazar los demás). Si está dispuesto a aceptar cualquier certificado autofirmado, también podría aceptar cualquier cosa, ya que no podría verificar que el DN del emisor sea quien dice que es (utilizando solo el cert), si-o-no DN del emisor = el DN del sujeto se vuelve irrelevante. – Bruno

+0

@Ethan en general SSL admite autenticación con claves OpenPGP o con clave secreta precompartida. Pero ninguno de estos se adaptará. En cuanto a aceptar solo autofirmado, puede controlar dinámicamente en qué confiar y supongo que, entre otros controles, OpenSSL debería permitirle verificar si el certificado está autofirmado (sus campos Emisor y Sujeto deben ser idénticos). –

Cuestiones relacionadas