Seguridad en Apache VI: comunicación HTTPS y autenticación con certificado cliente
En esta nota se describirá cómo configurar de manera segura el protocolo HTTPS, que proporciona cifrado de la comunicación y autenticación del servidor.
Los conceptos sobre algoritmos de cifrado de clave pública y clave privada, certificados o sobre cómo generarlos se salen del alcance de este artículo. Si se desea más información, se pueden consultar las siguientes páginas web:
•Cómo entender los certificados web
•Certificados digitales con validación extendida
•SSL/TLS Strong Encryption: FAQ. Contiene comandos concretos sobre cómo crear un certificado.
Se recomienda que la clave privada asociada al certificado del sitio web tenga una longitud de 2048 bits.
Ventajas de HTTPs sobre HTTP
HTTPS se diferencia de HTTP en que utiliza el protocolo SSL/TLS lo que le proporciona las siguientes ventajas:
•Comunicación cifrada que por tanto imposibilita que se capture la información (eavesdropping).
•Autenticación del servidor, si su certificado ha sido emitido por una CA de confianza, con lo que se evitan ataques de tipo man-in-the-middle.
Por contra, el proceso de cifrado y descifrado la realiza el servidor, lo que puede llegar a suponer un problema en páginas web con mucho volumen de visitas.
Configuración segura de HTTPS
Protección de los archivos de clave privada
Al crearse el archivo de clave privada puede especificarse una contraseña con la que se cifrará el archivo. Al iniciar Apache esta contraseña será solicitada al administrador para que Apache pueda descifrar y utilizar la clave privada.
Si este archivo no se encuentra cifrado debe tener permisos de acceso sólo por el usuario root. El servicio de Apache se inicia con el usuario root para después crear varios procesos que proporcionan el servicio web pero que son ejecutados con el usuario de Apache.
Suites de cifrado seguras
La directiva SSLCipherSuite establece los protocolos de autenticación y de cifrado que admite el servidor web. Se recomienda establecerla a los siguientes valores:
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
SSLHonorCipherOrder es necesaria para que las preferencias del servidor tenga prioridad sobre las del cliente en la negociación de qué algoritmos criptográficos utilizar. La configuración anterior establece lo siguiente:
•En primer lugar, si el cliente lo admite, utilizar RC4-SHA. Esta medida tiene el objetivo de evitar, si el cliente lo permite, los algoritmos de cifrado CBC que son vulnerables al ataque Beast que permiten descifrar la información.
•El parámetro "HIGH" establece que se utilicen claves de por lo menos 128 bits. Esta valor se refiere a la clave de sesión que cifra las comunicaciones, a diferencia de la clave privada del certificado de 2048 bits que se utiliza en la autenticación y en el establecimiento de los parámetros de la comunicación.
•El valor "!ADH" elimina de los algoritmos anteriores los que utilizan el protocolo Anonymous Diffie-Hellman, porque no proporcionan autenticación del servidor.
No permitir la renegociación SSL/TLS
Existe una vulnerabilidad en el protocolo SSL/TLS en la renogociación de los parámetros de comunicación que permite a un atacante enviar peticiones al servidor como procedentes del cliente (spoofing).
Motivado por esta vulnerabilidad, Apache ha desactivado esta funcionalidad por defecto.
Permitir únicamente acceso por HTTPS
Lo más común es que los portales sean en su mayoría accesibles por HTTP y sólo las páginas en las que se transmite información confidencial, como formularios o que permiten realizar acciones, sean sobre HTTPS.
Esta doble configuración podría permitir que partes accesibles por HTTPS lo fueran también por HTTP. Este problema se puede evitar con la siguiente configuración que obliga a que el directorio al que se refiere sólo pueda ser accedido por HTTPS:
SSLRequireSSL;
Como medida de seguridad adicional se puede configurar Apache para que utilice HTTP Strict Transport Security o HSTS, para informar al navegador del usuario de que el acceso debe realizarse por HTTPS. Esta medida es útil en el caso de que se produzca un error en el servidor o en la configuración que permita el acceso por HTTP a contenidos restringidos a HTTPS.
Comprobación de la seguridad de HTTPS
Se pueden comprobar el nivel de seguridad de la configuración HTTPS de un portal a través de la web www.trustworthyinternet.org/ssl-pulse/, que muestra un informe con las debilidades en la configuración y cómo solventarlas, o utilizar una herramienta como sslyze:
Autenticación del usuario por certificado
Además de por contraseña, Apache permite la autenticación de un usuario mediante certificado. El servidor únicamente ha de verificar la firma del certificado de los usuarios. Por ello, sólo necesita el certificado de la CA que emite los certificados clientes, que no tiene porqué ser el mismo que el utilizado en el protocolo HTTPS.
En los ejemplos siguientes se autorizará el acceso a aquellos clientes que presenten el certificado de autenticación del DNIe. La configuración de Apache debe ser la siguiente:
# Se establece el archivo que contiene el certificado de las CA raíz en formato PEMSSLCACertificateFile "/etc/httpd/ssl.crt/dnie-acraiz-sha256.pem"
# Porque la cadena de validación se compone de 2 niveles: una CA raíz y 3 subordinadas:SSLVerifyDepth 2
# Es oligatorio que el cliente presente un certificado válido:SSLVerifyClient require
# Para exportar la información del certificado y que pueda ser usada en los CGI:SSLOptions +StdEnvVars +ExportCertData
La funcionalidad de comprobación de la revocación del certificado mediante OCSP no la proporciona Apache, ha de realizarse mediante CGI.
Criterios compuestos de autorización
Mediante la directiva Require y la nueva forma de definir expresiones lógicas en Apache se puede hacer uso de toda la información del certificado cliente para definir unos requisitos de acceso complejos que utilicen entre sus requisitos determinada información del certificado.
En el siguiente ejemplo, extraído de la web de Apache, sólo se permite el acceso a aquellos usuarios que se conecten en horario laboral, con un certificado de la organización "Snake Oil, Ltd.", de la unidad organizativa "Staff", "CA" o "Dev" que no hayan utilizado protocolos inseguros, o bien que se conecten desde la red 192.76.162.255:
Require (%{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
También se podría utilizar la directiva SSLRequire, pero esta directiva tiene previsto eliminarse (está en estado deprecated).
Fuente: http://cert.inteco.es/cert/Notas_Actualidad/seguridad_apache_vi_comunicacion_https_autenticacion_certificado_cliente_20120614
Los conceptos sobre algoritmos de cifrado de clave pública y clave privada, certificados o sobre cómo generarlos se salen del alcance de este artículo. Si se desea más información, se pueden consultar las siguientes páginas web:
•Cómo entender los certificados web
•Certificados digitales con validación extendida
•SSL/TLS Strong Encryption: FAQ. Contiene comandos concretos sobre cómo crear un certificado.
Se recomienda que la clave privada asociada al certificado del sitio web tenga una longitud de 2048 bits.
Ventajas de HTTPs sobre HTTP
HTTPS se diferencia de HTTP en que utiliza el protocolo SSL/TLS lo que le proporciona las siguientes ventajas:
•Comunicación cifrada que por tanto imposibilita que se capture la información (eavesdropping).
•Autenticación del servidor, si su certificado ha sido emitido por una CA de confianza, con lo que se evitan ataques de tipo man-in-the-middle.
Por contra, el proceso de cifrado y descifrado la realiza el servidor, lo que puede llegar a suponer un problema en páginas web con mucho volumen de visitas.
Configuración segura de HTTPS
Protección de los archivos de clave privada
Al crearse el archivo de clave privada puede especificarse una contraseña con la que se cifrará el archivo. Al iniciar Apache esta contraseña será solicitada al administrador para que Apache pueda descifrar y utilizar la clave privada.
Si este archivo no se encuentra cifrado debe tener permisos de acceso sólo por el usuario root. El servicio de Apache se inicia con el usuario root para después crear varios procesos que proporcionan el servicio web pero que son ejecutados con el usuario de Apache.
Suites de cifrado seguras
La directiva SSLCipherSuite establece los protocolos de autenticación y de cifrado que admite el servidor web. Se recomienda establecerla a los siguientes valores:
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
SSLHonorCipherOrder es necesaria para que las preferencias del servidor tenga prioridad sobre las del cliente en la negociación de qué algoritmos criptográficos utilizar. La configuración anterior establece lo siguiente:
•En primer lugar, si el cliente lo admite, utilizar RC4-SHA. Esta medida tiene el objetivo de evitar, si el cliente lo permite, los algoritmos de cifrado CBC que son vulnerables al ataque Beast que permiten descifrar la información.
•El parámetro "HIGH" establece que se utilicen claves de por lo menos 128 bits. Esta valor se refiere a la clave de sesión que cifra las comunicaciones, a diferencia de la clave privada del certificado de 2048 bits que se utiliza en la autenticación y en el establecimiento de los parámetros de la comunicación.
•El valor "!ADH" elimina de los algoritmos anteriores los que utilizan el protocolo Anonymous Diffie-Hellman, porque no proporcionan autenticación del servidor.
No permitir la renegociación SSL/TLS
Existe una vulnerabilidad en el protocolo SSL/TLS en la renogociación de los parámetros de comunicación que permite a un atacante enviar peticiones al servidor como procedentes del cliente (spoofing).
Motivado por esta vulnerabilidad, Apache ha desactivado esta funcionalidad por defecto.
Permitir únicamente acceso por HTTPS
Lo más común es que los portales sean en su mayoría accesibles por HTTP y sólo las páginas en las que se transmite información confidencial, como formularios o que permiten realizar acciones, sean sobre HTTPS.
Esta doble configuración podría permitir que partes accesibles por HTTPS lo fueran también por HTTP. Este problema se puede evitar con la siguiente configuración que obliga a que el directorio al que se refiere sólo pueda ser accedido por HTTPS:
SSLRequireSSL;
Como medida de seguridad adicional se puede configurar Apache para que utilice HTTP Strict Transport Security o HSTS, para informar al navegador del usuario de que el acceso debe realizarse por HTTPS. Esta medida es útil en el caso de que se produzca un error en el servidor o en la configuración que permita el acceso por HTTP a contenidos restringidos a HTTPS.
Comprobación de la seguridad de HTTPS
Se pueden comprobar el nivel de seguridad de la configuración HTTPS de un portal a través de la web www.trustworthyinternet.org/ssl-pulse/, que muestra un informe con las debilidades en la configuración y cómo solventarlas, o utilizar una herramienta como sslyze:
Autenticación del usuario por certificado
Además de por contraseña, Apache permite la autenticación de un usuario mediante certificado. El servidor únicamente ha de verificar la firma del certificado de los usuarios. Por ello, sólo necesita el certificado de la CA que emite los certificados clientes, que no tiene porqué ser el mismo que el utilizado en el protocolo HTTPS.
En los ejemplos siguientes se autorizará el acceso a aquellos clientes que presenten el certificado de autenticación del DNIe. La configuración de Apache debe ser la siguiente:
# Se establece el archivo que contiene el certificado de las CA raíz en formato PEMSSLCACertificateFile "/etc/httpd/ssl.crt/dnie-acraiz-sha256.pem"
# Porque la cadena de validación se compone de 2 niveles: una CA raíz y 3 subordinadas:SSLVerifyDepth 2
# Es oligatorio que el cliente presente un certificado válido:SSLVerifyClient require
# Para exportar la información del certificado y que pueda ser usada en los CGI:SSLOptions +StdEnvVars +ExportCertData
La funcionalidad de comprobación de la revocación del certificado mediante OCSP no la proporciona Apache, ha de realizarse mediante CGI.
Criterios compuestos de autorización
Mediante la directiva Require y la nueva forma de definir expresiones lógicas en Apache se puede hacer uso de toda la información del certificado cliente para definir unos requisitos de acceso complejos que utilicen entre sus requisitos determinada información del certificado.
En el siguiente ejemplo, extraído de la web de Apache, sólo se permite el acceso a aquellos usuarios que se conecten en horario laboral, con un certificado de la organización "Snake Oil, Ltd.", de la unidad organizativa "Staff", "CA" o "Dev" que no hayan utilizado protocolos inseguros, o bien que se conecten desde la red 192.76.162.255:
Require (%{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
También se podría utilizar la directiva SSLRequire, pero esta directiva tiene previsto eliminarse (está en estado deprecated).
Fuente: http://cert.inteco.es/cert/Notas_Actualidad/seguridad_apache_vi_comunicacion_https_autenticacion_certificado_cliente_20120614
Comentarios
Publicar un comentario
siempre es bueno, leer tus comentarios