autenticación de cliente ssl: marque solo un certificado VS certificados firmados desde una ca

Question

autenticación de cliente ssl: marque solo un certificado VS certificados firmados desde una ca

#1 de Tom Leek (1 votos)

0

Estoy a punto de asegurar un servicio web con autenticación de cliente. (apache2, mod_ssl, openssl).

por lo que busqué en Google, descubrí que es más común tener una ca, que firma los certificados de los clientes, que luego se verificará.

también encontré que debería ser posible con la ayuda de la directiva sslrequire (en la configuración de apache) verificar algo , supongo que el DN del emisor y del sujeto del certificado de cliente, o habría un campo mejor para esto, para verificar si el cliente tiene un certificado determinado.

algo como (pseudocódigo): sslrequire issuer_dn = 'issuer_dn_from_client_cert' AND subject_dn = 'subject_dn_from_client_cert'

mi pregunta es: ¿eso realmente funcionaría? Quiero decir, si un atacante adivinara el DN del emisor y del sujeto, ¿no podría él mismo hacerse un certificado válido?

apache openssl

pregunta frisbee23 02.04.2014 - 13:01

fuente

1 respuesta

Lea otras preguntas en las etiquetas apache openssl

Conceptos básicos de autorización de API en detalle Obtener clave privada PGP del análisis de RAM RSAKeyFind

score 1 · Accepted Answer

Los certificados están firmados . Cuando un servidor autentica clientes a través de certificados, suceden las siguientes tres cosas:

El cliente demuestra el dominio de la clave privada correspondiente a la clave pública que está contenida en su certificado. Esta parte ocurre dentro de SSL; como parte del protocolo, el cliente calcula una firma en un desafío del servidor. No tiene que preocuparse por eso porque la biblioteca SSL que usa ya lo hace.
El servidor valida el certificado. La validación consiste en asegurarse de que los contenidos del certificado son genuinos. Para validar un certificado, el servidor verifica la firma en el certificado, con respecto a su clave pública de la CA emisora. La clave pública de la CA se obtiene a través del certificado de la CA, que también debe validarse, y así sucesivamente. En última instancia, este proceso se enlaza a una clave pública conocida como a priori , denominada trust anchor o root CA .

El Apache SSLCACertificateFile y SSLCACertificatePath se utilizan para configurar qué CA raíz usará su servidor.
El servidor decide si al usuario autenticado se le debe otorgar acceso o no. Esto es de lo que trata la directiva SSLRequire de Apache: un filtro sobre identidades autenticadas.

El primer paso es el método por el cual el servidor se asegura de que el cliente es "quien posee la clave pública K_p " (como se encuentra en el certificado enviado). El segundo paso es el mecanismo que revela al servidor la identidad I del propietario de K_p . El primer y segundo paso juntos dan al servidor alguna garantía sobre la identidad del cliente. Ahora que el servidor sabe a quién llama , el servidor debe verificar que la persona que llama pueda realizar la llamada. Si queremos usar terminología estricta, los primeros dos pasos son autenticación per se, mientras que el tercer paso es autorización .

Una analogía:

El cliente es Bob.
La clave privada es la cara de Bob.
El certificado es la tarjeta de identificación de Bob.
La directiva SSLRequire es la lista de invitados esperados, en manos del guardia de seguridad.

Bob demuestra ser dueño de su cara en virtud de que esa cara está firmemente sujeta a su cuerpo (el guardia comprueba que la cara no es una máscara); ese es el primer paso.

Los guardias de seguridad inspeccionan la tarjeta de identificación, concluyen que la tarjeta es genuina (asumimos aquí que las tarjetas de identificación no pueden ser falsificadas) y que la foto en la tarjeta de identificación coincide con la cara de la persona que se encuentra frente a él. Dado que el nombre de Bob aparece en la tarjeta de identificación, el guardia de seguridad ahora sabe que está hablando con el verdadero "Bob". Ese es el segundo paso.

Luego el guardia de seguridad verifica si su lista de invitados permitidos contiene el nombre de Bob. Si lo hace, dejará entrar a Bob. De lo contrario, ahuyentará a Bob.

Dave, un agente de fiestas, quiere pasar al guardia de seguridad. Para lograrlo, tiene que romper uno de estos pasos: conseguir una cara falsa de Bob (con una máscara tan perfecta que engañe al guardia), o obtener una tarjeta de identificación falsa (con la cara de Dave pero el nombre de Bob), o alterar la lista de guardias (simplemente agregando su propio nombre a la lista). Volviendo al servidor Apache, esto significa robar la clave privada del cliente (p. Ej., Mediante la ruptura criptográfica - ¡buena suerte con eso!), Obtener un certificado falso (que implica sobornar o piratear a uno de los CA que Apache ha configurado para aceptar), o alterar la configuración de Apache (su directiva SSLRequire ). Dado que alterar la configuración de Apache significa que Dave ya tiene acceso de root a la máquina, esto no suele ser un ataque relevante.

Saber que nombre de Bob no es suficiente para Dave. ESA es la respuesta a su pregunta: no, saber qué colocar en un certificado falso (el DN del emisor y del sujeto requerido por SSLRequire ) no permite elaborar un certificado falso; el atacante todavía tiene que corromper algunos CA para que obtenga su certificado firmado (de una manera que el servidor acepta).