Todas las guías e implementaciones de sTunnel en el trabajo hacen lo mismo, dicen que una vez que se crean la clave privada y el certificado público en el servidor, debe agruparlos y luego compartirlos con el host del cliente.
Si bien esto tiene mucho sentido para mí con el certificado público (ya que el cliente cifrará los datos al usarlo), seguramente, compartir la clave privada va en contra de toda la ética de SSL.
Stunnel es SSL y, en SSL, las claves privadas nunca necesitan viajar. El "ethos SSL" es que los certificados X.509 se utilizan para autenticar pares sin un secreto compartido pre-distribuido. Por ejemplo, cuando conecta su navegador web a https://example.com , la capa SSL reconoce el certificado del servidor y puede asegurarse de que habla con "example.com" real sin necesidad de conocer previamente ese sitio específico.
Stunnel está fuera de este modelo, ya que normalmente se usa entre dos máquinas que ya se conocen entre sí. Esto permite utilizar modelos más ligeros.
De forma predeterminada, Stunnel no valida los certificados. Esto se indica así en la página HOWTO (en la sección "¿Cómo verifica el certificado de stunnel?"). Si no cambió esa configuración, entonces no importa en absoluto qué certificados utiliza. Por supuesto, no validar certificados deja el túnel vulnerable a los ataques Man-in-the-Middle . Esto todavía puede ser aceptable, desde un punto de vista de seguridad, si el túnel pretende transmitir solo un protocolo subyacente que ya incluye protección criptográfica; por lo general, utiliza stunnel para atravesar un firewall de la escuela / empresa, pero dentro de usted solo ejecuta algunos SSH. El stunnel está ahí solo para mantener al firewall desprevenido de la naturaleza SSHish de la comunicación. En ese caso específico, no validar certificados está bien. (Bien, bien con respecto a su seguridad. Todavía está eludiendo el cortafuegos de su escuela / empresa, lo que es moralmente y legalmente cuestionable).
La mayoría de las guías de stunnel explican cómo configurar stunnel en ese modo sin verificación, y copiar el certificado tanto en el cliente como en el servidor es la forma más conveniente de mantener las cosas en funcionamiento.
Si configura stunnel para validar certificados, entonces:
El cliente debe poder verificar que el certificado del servidor (el certificado es la parte pública, NO la clave privada), lo que implica conocerlo de antemano o verificar su firma con Se refiere a una CA conocida.
Cuando el cliente ha verificado que el certificado del servidor es original, todavía debe verificar que sea el certificado del servidor deseado.
Si el servidor solicita un certificado del cliente, también debe poder verificarlo y verificar que corresponde a un cliente permitido.
No hay ningún código en stunnel que compare los certificados de cliente y servidor entre sí. Realmente viven en mundos distintos; El certificado del cliente se valida en el servidor, el certificado del servidor se valida en el cliente. Tener el mismo certificado en ambos sistemas no tiene ninguna influencia en el comportamiento de ninguno de ellos.
En un sistema de verificación de certificados, si tanto el cliente como el servidor usan el mismo certificado, entonces el cliente puede hacerse pasar por el servidor y viceversa. Si solo hay dos máquinas, entonces esto no importa mucho. Si hay más máquinas (por ejemplo, dos clientes para conectarse en el mismo servidor), esto puede ser muy importante (no necesariamente quiere permitir que un cliente enmarque a otro cliente con un servidor falso). Y, por supuesto, compartir la clave privada implica que la clave privada viajó de una máquina a otra, que usaba un túnel preexistente (por ejemplo, SSH) o era una operación arriesgada. Las claves privadas deben permanecer privadas, y cuanto más una clave privada viaje, menos privada se vuelve.
No.
Si desea utilizar la autenticación de certificado de cliente, debe copiar la clave privada y el certificado del cliente desde la autoridad de certificación.
Si desea permitir que los clientes autentiquen un servidor, debe copiar la clave privada y el certificado del servidor desde la autoridad de certificación al servidor.
Exactamente cómo desea autenticar los impactos finales remotos en qué otros recursos se necesitan dónde. Tomando el caso más simple de un cliente que se conecta de forma anónima (es decir, sin certificado de cliente) a un servidor, el cliente puede
SSL tiene que ver con un menage-a-trois entre el servidor, el cliente y la autoridad de certificación.
Lea otras preguntas en las etiquetas public-key-infrastructure encryption unix openssl