EN ESTA PÁGINA
Certificados SSL
El firewall serie SRX actúa como proxy SSL que administra las conexiones SSL entre el cliente en un extremo y el servidor en el otro extremo. El servidor proxy SSL garantiza la transmisión segura de datos con tecnología de cifrado. SSL se basa en certificados y pares de intercambio de claves públicas y privadas para proporcionar la comunicación segura. En este tema, aprenderá cómo generar e instalar un certificado SSL en su dispositivo de seguridad para conexiones SSL.
Configuración y carga de certificados SSL
La figura 1 muestra una descripción general de cómo se configura el proxy SSL. La configuración del proxy SSL incluye:
Configuración del certificado de CA raíz
Carga de un grupo de perfil de CA
Configure el perfil de proxy SSL y asocie el certificado de CA raíz y el grupo de perfiles de CA
Aplicación de un perfil de proxy SSL a una política de seguridad
de la configuración del proxy SSL
Analicemos estos procedimientos en detalle en las siguientes secciones:
Configurar un certificado de CA raíz
Una CA puede emitir varios certificados en forma de estructura de árbol. Un certificado raíz es el certificado superior del árbol, cuya clave privada se utiliza a sign otros certificados. Todos los certificados inmediatamente debajo del certificado raíz heredan la firma o la confiabilidad del certificado raíz. Esto es algo parecido a lo notarizing de una identidad.
Para configurar un certificado de CA raíz, debe
Obtener un certificado de CA raíz (al importar uno)
-
Puede generar un certificado de CA raíz mediante la CLI de Junos OS en un firewall serie SRX.
Obtener un certificado de una CA externa (no cubierto en este tema)
-
Aplicar CA raíz a un perfil de proxy SSL.
Generar un certificado de CA raíz con CLI
Para definir un certificado autofirmado en la CLI, debe proporcionar los siguientes detalles:
Identificador de certificado (generado en el paso anterior)
Nombre de dominio completo (FQDN) para el certificado
Dirección de correo electrónico de la entidad propietaria del certificado
Nombre común y la organización involucrada
Genere un certificado de CA raíz mediante la CLI de Junos OS:
Configurar un grupo de perfiles de CA de confianza
El perfil de CA define la información del certificado para la autenticación. Incluye la clave pública que usa el proxy SSL al generar un certificado nuevo. Junos OS le permite crear un grupo de perfiles de CA y cargar varios certificados en una acción, ver información acerca de todos los certificados de un grupo y eliminar grupos de CA no deseados. Cuando se inicia una conexión, el dispositivo de conexión (como un explorador web) comprueba si el certificado lo emite una CA de confianza. Sin estos certificados, los navegadores no pueden validar la identidad de la mayoría de los sitios web y marcarlos como sitios no confiables.
La configuración de un grupo de perfiles de CA de confianza incluye los siguientes pasos:
Obtención de una lista de certificados de CA de confianza. Puede obtener certificados de CA de confianza mediante uno de los métodos siguientes:
Junos OS proporciona una lista predeterminada de certificados de CA de confianza como archivo PEM (por ejemplo, trusted_CA.pem). Después de descargar el paquete de Junos OS, los certificados predeterminados están disponibles en su sistema.
Desde el modo operativo, cargue los certificados de CA de confianza predeterminados (el nombre del grupo identifica al grupo de perfil de CA):
user@host> request security pki ca-certificate ca-profile-group load ca-group-name group-name filename default
Ejemplo:
user@host> request security pki ca-certificate ca-profile-group load ca-group-name SECURITY-CA-GROUP filename default
Recomendamos usar este método.
Defina su propia lista de certificados de CA de confianza e impórtelos en su sistema. Obtiene la lista de CA de confianza en un solo archivo PEM (por ejemplo , IE-all.pem) y guarda el archivo PEM en una ubicación específica (por ejemplo, /var/tmp). Consulte el artículo de la Base de conocimientos KB23144.
Desde el modo operativo, cargue la lista de confianza en el dispositivo (el nombre del grupo identifica al grupo de perfil de CA):
user@host> request security pki ca-certificate ca-profile-group load ca-group-name SECURITY-CA-GROUP filename /var/tmp/IE-all.pem
Ejemplo:
user@host> request security pki ca-certificate ca-profile-group load ca-group-name SECURITY-CA-GROUP filename /var/tmp/custom-file.pem
Descargue la última lista de paquetes de CA de otro tercero, como Mozilla (https://curl.haxx.se/docs/caextract.html). La lista de autoridades de certificación de confianza puede cambiar con el tiempo, asegúrese de usar el paquete de CA más reciente.
Importe sus propios certificados de CA de confianza mediante la infraestructura de clave pública (PKI). La PKI ayuda a verificar y autenticar la validez de los certificados de CA de confianza. Puede crear grupos de perfiles de CA que incluyen certificados de CA de confianza y, a continuación, importar el grupo en su dispositivo para la autenticación del servidor.
Adjuntar el grupo de CA al perfil de proxy SSL.
Adjuntar todos los grupos de perfiles de CA:
Ejemplo:
[edit] user@host# set services ssl proxy profile PROFILE-1 trusted-ca all
Adjuntar un grupo de perfiles de CA (el nombre del grupo identifica al grupo de perfil de CA).
Ejemplo:
[edit] user@host# set services ssl proxy profile PROFILE-1 trusted-ca orgA-ca-profile
Puede mostrar fácilmente información sobre todos los certificados de un grupo de perfiles de CA:
user@host> show security pki ca-certificates ca-profile-group group-name
Puede eliminar un grupo de perfiles de CA. Recuerde que al eliminar un grupo de perfiles de CA se eliminan todos los certificados que pertenecen a ese grupo:
user@host> clear security pki ca-certificates ca-profile-group group-name
Lo que sigue
Ahora continúe con la configuración del perfil de proxy SSL y aplique el perfil de proxy SSL a la política de seguridad. Consulte Configurar proxy SSL.
Importación de un certificado de CA raíz en un navegador
Para que su navegador o sistema confíe automáticamente en todos los certificados firmados por la CA raíz configurados en el perfil de proxy SSL, debe indicar a su plataforma o navegador que confíe en el certificado raíz de CA.
Para importar un certificado de CA raíz:
Implementación de la cadena de certificados
A partir de Junos OS versión 15.1X49-D30, el proxy de reenvío SSL admite la implementación de la cadena de certificados. Analicemos cómo comprender los conceptos de cadena de certificados y cómo configurarlo en el firewall serie SRX.
Certificate Authority (CA)— CA es un tercero de confianza responsable de validar las identidades de entidades (como sitios web, direcciones de correo electrónico, empresas o personas individuales) y emite un certificado digital mediante el enlace de claves criptográficas. Si su organización posee un servidor de CA, se convertirá en su propia CA y utilizará un certificado autofirmado.
Root Certificate— Un certificado raíz es un certificado emitido por una autoridad de certificación (CA) de confianza. El certificado raíz es el certificado superior del árbol, cuya clave privada se utiliza para firmar otros certificados. Todos los certificados inmediatamente debajo del certificado raíz heredan la firma o la confiabilidad del certificado raíz. Estos certificados se utilizan para establecer la conexión entre dos puntos de conexión.
Intermediate CA Certificate— Un certificado de CA intermedio es un certificado subordinado firmado por la raíz de confianza específicamente para validar certificados de entidad final.
Certificate Chain - Una cadena de certificados es la lista ordenada de certificados que contiene el certificado SSL, el certificado intermedio y el certificado raíz. Algunas autoridades de certificado (CA) no firman con su certificado raíz, sino que utilizan un certificado intermedio. Una CA intermedia puede firmar certificados en nombre del certificado de CA raíz. La CA raíz firma el certificado intermedio, formando una cadena de confianza.
El certificado intermedio debe estar instalado en el mismo servidor que el certificado SSL para que el dispositivo de conexión (navegadores, aplicaciones, dispositivo móvil, etc.) pueda confiar en él.
Cuando inicia una conexión, el dispositivo de conexión (como un navegador Web) comprueba si el certificado es auténtico y lo emite una autoridad de certificación de confianza que está incrustada en el almacén de confianza del navegador.
Si el certificado SSL no es de una CA de confianza, el dispositivo de conexión continúa comprobando si el certificado SSL lo emite una CA intermedia y esta CA intermedia está firmada por una CA raíz. La comprobación continúa hasta que se encuentre la CA raíz. Si encuentra una CA raíz, se establece una conexión segura. Si no encuentra una CA raíz, se pierde la conexión y su navegador web muestra un mensaje de error sobre un certificado no válido o un certificado no de confianza.
En este ejemplo, se muestra cómo instalar la cadena de certificados para permitir que los navegadores confíen en el certificado.
Requisitos
No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar esta función.
Visión general
En este ejemplo, tiene un dominio, ejemplo.dominio-1, y desea comprar un certificado de XYZ-Authority para su dominio. Sin embargo, XYZ-Authority no es una CA raíz y el navegador web que visita solo confía en el certificado raíz-CA. En otras palabras, su certificado no está directamente incrustado en su navegador web y, por lo tanto, no es de confianza explícita.
En este caso, la confianza se establece de la siguiente manera mediante la cadena de certificados (de certificados intermedios).
Topología
Intentemos visualizar esta cadena a través de la Figura 2. La imagen muestra una cadena de certificados completa, desde el certificado de CA raíz hasta el certificado de usuario final. La cadena termina en el certificado de usuario final.
raíz
Usuario |
Usa certificado |
Firmado por |
Tipo |
|---|---|---|---|
ejemplo.domain-1 |
Certificado de usuario final |
Autoridad XYZ |
Certificado de usuario final. El que compra a la CA. |
Autoridad XYZ |
Certificado 1 |
CA-1 intermedio |
Certificado intermedio |
CA-1 intermedio |
Certificado 2 |
CA-2 intermedio |
Certificado intermedio |
CA-2 intermedio |
Certificado 3 |
CA-3 intermedio |
Certificado intermedio |
CA-3 intermedio |
Certificado 4 |
raíz-ejemplo-autoridad. Esta es una CA raíz. |
Certificado raíz Su certificado está directamente integrado en su navegador web; por lo tanto, se puede confiar explícitamente en él. |
Cuando instale el certificado de usuario final para el servidor example.domain-1, debe agrupar todos los certificados intermedios e instalarlos junto con el certificado de usuario final. La cadena de certificados incluye todos los certificados desde el certificado 1 hasta el certificado raíz de CA. Dado que el explorador web confía en la CA raíz, también confía implícitamente en todos los certificados intermedios. Si la cadena de certificados SSL no es válida o está rota, algunos dispositivos no confiarán en su certificado.
Todos los certificados deben estar en formato de correo mejorado para la privacidad (PEM).
Cuando importa el archivo de certificado concatenado en el dispositivo, la CA proporciona un paquete de certificados encadenados que se deben agregar al certificado de servidor firmado. El certificado de servidor debe aparecer antes que los certificados encadenados en el archivo combinado.
Configuración
La configuración de la cadena de certificados SSL incluye las siguientes tareas:
Compre un certificado SSL de una CA que incluya un certificado de firma y una clave respectiva.
Configure un grupo de perfiles de CA de confianza.
Cargue el certificado de firma y la clave en su dispositivo.
Cargue la CA intermedia y raíz en la memoria de infraestructura de clave pública (PKI). Este archivo de certificado contiene todos los certificados de CA necesarios, uno detrás de otro, en formato PEM.
Cree un perfil de CA de confianza para el certificado de CA intermedio o raíz.
Configure el dispositivo para usar el certificado de firma recibido de la CA mediante la configuración y aplicación del perfil de proxy SSL a una política de seguridad. El proxy de reenvío SSL almacena esta información de cadena de certificados (nombre de perfil de certificado de CA) en el perfil SSL respectivo. Como parte de la implementación de la política de seguridad, se utilizan perfiles SSL que tengan la información de cadena de certificados y certificados de CA.
En el procesamiento de la cadena de certificados intervienen los siguientes componentes:
El administrador carga la cadena de certificados y el certificado local (certificado de firma) en la caché de certificados del demonio PKI.
El demonio de seguridad de red (nsd) envía una solicitud al demonio de PKI para proporcionar la información de la cadena de certificados para un certificado de firma configurado en el perfil de proxy SSL.
En este ejemplo, se da por sentado que ya adquirió un certificado SSL de una CA.
Configuración de la cadena de certificados en el dispositivo
Procedimiento paso a paso
Para configurar la cadena de certificados:
Cargue el certificado local en la memoria PKI.
user@host>request security pki local-certificate load filenamessl_proxy_ ca.crt key sslserver.key certificate-id ssl-inspect-caSe muestra el siguiente mensaje:
Local certificate loaded successfully
Tenga en cuenta que el ID de certificado se utilizará en la
root-casección del perfil de proxy SSL.Cargue el certificado de CA intermedio o raíz en la memoria PKI.
user@host>request security pki ca-certificate ca-profile-group load ca-group-name ca-latest filename ca-latest.cert.pemEl perfil de CA incluye la información de certificado utilizada para la autenticación. Incluye la clave pública que usa el proxy SSL al generar un certificado nuevo.
Do you want to load this CA certificate? [yes,no] (no) yes Loading 1 certificates for group 'ca-latest'. ca-latest_1: Loading done. ca-profile-group 'ca-latest' successfully loaded Success[1] Skipped[0]Este certificado se adjuntará como una cadena de certificados.
Adjunte el grupo de perfiles de CA al perfil de proxy SSL. Puede adjuntar CA de confianza de una en una o cargar todo en una acción.
user@host#set services ssl proxy profile ssl-profile trusted-ca allAplique el certificado de firma como ca raíz en el perfil de proxy SSL.
user@host#set services ssl proxy profile ssl-profile root-ca ssl-inspect-caCree una política de seguridad y especifique los criterios de coincidencia para la política. Como criterios de coincidencia, especifique el tráfico para el que desea habilitar el proxy SSL. En este ejemplo, se da por sentado que ya ha creado zonas de seguridad según los requisitos.
user@host#set security policies from-zone trust to-zone untrust policy 1 match source-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match destination-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match application anyuser@host#set security policies from-zone trust to-zone untrust policy 1 then permit application-services ssl-proxy profile-name ssl-profileEl proxy de reenvío SSL almacena esta información de cadena de certificados (nombre de perfil de certificado de CA) en el perfil SSL respectivo. Como parte de la implementación de la política de seguridad, se utilizan perfiles SSL que tengan la información de cadena de certificados y certificados de CA.
Puede ver la cadena de certificados en el explorador Web conectado (es decir, el cliente).
Ignorar error de autenticación del servidor
Autenticación de servidor
La confianza implícita entre el cliente y el dispositivo (porque el cliente acepta el certificado generado por el dispositivo) es un aspecto importante del proxy SSL. Es sumamente importante que la autenticación del servidor no se vea comprometida; sin embargo, en realidad, los certificados autofirmados y los certificados con anomalías son abundantes. Las anomalías pueden incluir certificados vencidos, instancias de nombre común que no coincidan con un nombre de dominio, etc.
La autenticación del servidor se rige estableciendo la ignore-server-auth-failure opción en el perfil de proxy SSL. Los resultados de la configuración de esta opción están disponibles en la Tabla 2.
[edit]user@host#set services ssl proxy profile profile-name actions ignore-server-auth-failure
Acción de perfil de proxy SSL |
Resultados |
|---|---|
La ignore-server-auth-failure opción no está establecida (opción predeterminada) |
|
La ignore-server-auth-failure opción está establecida |
|
Autenticación de cliente
Actualmente, la autenticación de cliente no se admite en el proxy SSL. Si un servidor solicita autenticación de cliente, se emite una advertencia de que un certificado no está disponible. La advertencia permite que el servidor determine si desea continuar o salir.
Listas de revocación de certificados para proxy SSL
Trabajar con las listas de revocación de certificados para el proxy SSL
La autoridad de certificación (CA) publica periódicamente una lista de certificados revocados mediante una lista de revocación de certificados (CRL). El dispositivo de seguridad descarga y almacena en caché la CRL emitida más reciente. La CRL contiene la lista de certificados digitales con números de serie que se cancelaron antes de su fecha de vencimiento.
Ca revoca el certificado emitido si hay alguna posibilidad de que el certificado se vea comprometido. Otras razones para revocar un certificado son:
No especificado (no se da ninguna razón en particular).
La clave privada asociada con el certificado o ca que emitió el certificado se vio comprometida.
El propietario del certificado ya no está afiliado con el emisor del certificado
Otro certificado sustituye al original.
La CA que emitió el certificado dejó de funcionar.
El certificado está en espera de nuevas medidas. Se trata como revocada, pero podría ser aceptada en el futuro.
Cuando un dispositivo participante usa un certificado digital, comprueba la firma y la validez del certificado. De forma predeterminada, la verificación CRL está habilitada en el perfil de proxy SSL.
A partir de Junos OS versión 15.1X49-D30 y Junos OS versión 17.3R1, los firewalls serie SRX admiten la lista de revocación de certificados (CRL). La validación CRL en el firewall de la serie SRX implica comprobar los certificados revocados de los servidores.
En el firewall serie SRX, la comprobación de revocación de certificado está habilitada de forma predeterminada para el perfil de proxy SSL. Puede habilitar o deshabilitar la validación de CRL para cumplir con sus requisitos de seguridad específicos.
Puede permitir o soltar las sesiones cuando la información de CRL no esté disponible por motivos como una falla en la descarga de CRL o no disponibilidad de la ruta CRL en el certificado raíz o intermedio.
Permita las sesiones cuando la información de CRL no esté disponible.
[edit] user@host# set services ssl proxy profile profile-name actions crl if-not-present allow
Retire las sesiones cuando la información de CRL no esté disponible.
[edit] user@host# set services ssl proxy profile profile-name actions crl if-not-present drop
Configure un firewall de la serie SRX para aceptar un certificado sin una confirmación confiable disponible sobre el estado de revocación y permitir las sesiones cuando se revoque un certificado y el motivo de la revocación esté en espera.
[edit] user@host# set services ssl proxy profile profile-name actions crl ignore-hold-instruction-code
Mejoras de rendimiento de SSL
La mejora del rendimiento de SSL en el firewall de la serie SRX incluye las siguientes características:
- Optimización del rendimiento de SSL
- Reanudación de la sesión
- Negociación de la sesión
- Negociación de StartTLS para sesiones SMTP
- Resolución dinámica de nombres de dominio
Optimización del rendimiento de SSL
El protocolo de manos SSL/TLS es un proceso que requiere mucha CPU. Dado que SSL/TLS es el protocolo de seguridad más utilizado en la web, su rendimiento resulta en un impacto significativo en el rendimiento de la web.
A partir de Junos OS versión 15.1X49-D120, puede utilizar las siguientes opciones para optimizar el rendimiento:
Utilice intercambios de claves RSA optimizados
Usar cifrado autenticado con datos asociados (AEAD): AES128-CBC-SHA, AES256-CBC-SHA
Mantenimiento de la caché de certificados: la caché de certificados almacena el certificado de servidor interceptado junto con los detalles del certificado de servidor. Durante el apretón de manos SSL/TLS, el proxy SSL puede presentar el certificado interceptado en caché al cliente en lugar de generar el nuevo certificado interdicto.
Mejorar el rendimiento de SSL da como resultado un mejor rendimiento del sitio web sin comprometer la seguridad y maximizar la experiencia del usuario.
Opcionalmente, puede configurar las siguientes opciones para la caché de certificados. Sin embargo, recomendamos conservar los valores predeterminados.
Ejemplo:
-
(Opcional) Establezca el valor de tiempo de espera de la caché del certificado (por ejemplo, 300 segundos).
[edit]user@host# set services ssl proxy global-config certificate-cache-timeout 300En este ejemplo, la caché del certificado almacena los detalles del certificado durante 300 segundos. El valor predeterminado de tiempo de espera es de 600 segundos.
-
(Opcional) Desactive la caché de certificados.
[edit]user@host# set services ssl proxy global-config disable-cert-cacheCuando deshabilita la caché de certificados, el dispositivo permite el apretón de manos completo ssl para una nueva conexión. De forma predeterminada, la caché de certificados está habilitada.
-
(Opcional) Invalide la caché de certificados existente.
[edit]user@host# set services ssl proxy global-config invalidate-cache-on-crl-updateEn este ejemplo, el dispositivo invalida la caché de certificados existente cuando se actualiza la lista de revocación de certificados (CRL). De forma predeterminada, invalidar la caché de certificados en la actualización de CRL está deshabilitado.
Reanudación de la sesión
La reanudación de sesión SSL proporciona un mecanismo para reanudar una sesión anterior mediante el uso de los IDENTIFICA de sesión ya negociados. La reanudación de la sesión ahorra al cliente y al servidor la sobrecarga computacional de un apretón de manos SSL completo y la generación de nuevas claves principales.
La reanudación de la sesión acorta el proceso de apretón de manos y acelera las transacciones SSL, lo que mejora el rendimiento y mantiene el nivel adecuado de seguridad.
TLS 1.2 admite la reanudación de la sesión con identificadores de sesión y mecanismos de tickets de sesión. Una reanudación de sesión SSL incluye los siguientes pasos:
-
Un mecanismo de almacenamiento en caché de sesión almacena en caché la información de la sesión, como la clave secreta previa al maestro y los cifrados acordados tanto para el cliente como para el servidor.
-
El ID de sesión identifica la información almacenada en caché.
-
En conexiones posteriores, ambas partes acuerdan usar el ID de sesión para recuperar la información en lugar de crear una clave secreta pre-master.
A partir de Junos OS versión 22.1R1, TLS 1.3 admite la reanudación de sesión mediante una clave previamente compartida (PSK) en proxy SSL. La reanudación de la sesión mediante PSK permite reanudar una sesión con una clave secreta compartida previamente establecida para reducir la sobrecarga de manos ssl.
PSK es una clave de cifrado única derivada del apretón de manos TLS inicial. Después de un apretón de manos TLS correcto, el servidor envía una identidad PSK al cliente. El cliente usa esa identidad de PSK en los futuros apretones de manos para negociar el uso de PSK asociada para reanudar la sesión.
Una reanudación de sesión SSL con TLS1.3 incluye los siguientes pasos:
-
Después de un apretón de manos TLS inicial, el servidor envía un nuevo mensaje de ticket de sesión al cliente, el cual contiene la identidad PSK (copia cifrada de la PSK).
- La próxima vez, cuando el cliente intenta reanudar la sesión, envía el mismo ticket de sesión al servidor en el mensaje de saludo.
- El servidor descifra el mensaje, identifica la PSK y recupera la información de la sesión de su caché para reanudar la sesión.
Un SSL-I (iniciación SSL) usa PSK con modo de intercambio de claves ECDHE, y SSL-T (terminación SSL) usa PSK y PSK con modos de intercambio ECDHE.
La sesión de proxy SSL admite la interoperabilidad entre TLS1.3 y TLS1.2 y versiones anteriores en dos extremos de una conexión para la reanudación de la sesión.
De forma predeterminada, la reanudación de sesión está habilitada para el proxy SSL. Puede borrar la reanudación de la sesión o volver a habilitar según sus requisitos.
- Para despejar la reanudación de la sesión:
[edit] user@host# set services ssl proxy profile ssl actions disable-session-resumption
- Para volver a habilitar la reanudación de la sesión:
[edit] user@host# delete services ssl proxy profile ssl actions disable-session-resumption
Utilice el siguiente comando para configurar el valor del tiempo de espera de la sesión.
[edit] user@host# set services ssl proxy global-config session-cache-timeout session-cache-timeout
Negociación de la sesión
El firewall de la serie SRX admite la renegociación de la sesión. Después de crear una sesión y establecer el transporte de túnel SSL, un cambio en los parámetros SSL requiere una negociación. El proxy SSL admite la renegociación segura (RFC 5746) y no segura (TLS v1.0, TLS v1.1 y TLS v1.2). Cuando la reanudación de sesión está habilitada, la renegociación de sesión es útil en las siguientes situaciones:
Es necesario actualizar las claves de cifrado después de una sesión SSL prolongada.
Se deben aplicar cifrados más fuertes para una conexión más segura.
Si modifica el perfil de proxy SSL cambiando un certificado, una fuerza de cifrado o una lista de CA de confianza, el sistema borra las entradas de la caché cuando confirme la política modificada. En este caso, se requiere un apretón de manos completo para establecer los nuevos parámetros SSL. (No hay ningún impacto en las sesiones que no son SSL.)
Si el perfil de proxy SSL no se altera, las entradas de caché correspondientes a ese perfil no se vacían y la sesión continúa.
Negociación de StartTLS para sesiones SMTP
StartTLS habilita una sesión SMTP desde una conexión TCP inicial sin formato hasta una conexión TLS más segura. StartTLS permite la sesión SMTP entre el servidor y el cliente a través de la capa TLS después de la negociación correcta entre los pares. StartTLS actualiza una conexión SMTP no segura a una conexión SSL/TLS segura.
Puede establecer un umbral que le permita decidir cuánto tiempo debe esperar antes de ignorar la sesión si el cliente no recibe StartTLS.
Puede configurar las siguientes opciones:
- umbral de bytes: se permiten bytes mínimos de sesión no cifrada antes de ignorar la sesión si el cliente no recibe StartTLS. Rango de 100 a 300.
- umbral de paquetes: número de paquetes no cifrados permitidos en la dirección del cliente al servidor antes de ignorar la sesión si el startTLS no se recibe del cliente. Rango 1 a 15.
Ejemplo:
[edit] user@host# set services ssl proxy global-config mail-threshold byte-threshold 100
En este exaple, el proxy SSL permite 100 bytes de tráfico SMTP sin formato (no cifrado). Después de alcanzar los 100 bytes, ignora la sesión si no se recibe StartTLS del cliente.
[edit] user@host# set services ssl proxy global-config mail-threshold packet-threshold 2
En este ejemplo, el proxy SSL permite 2 paquetes de tráfico SMTP sin formato (no cifrado). Después de alcanzar 2 paquetes, ignora la sesión si el cliente no recibe StartTLS.
Resolución dinámica de nombres de dominio
Las direcciones IP asociadas con los nombres de dominio son dinámicas y pueden cambiar en cualquier momento. Cada vez que cambia una dirección IP de dominio, se propaga a la configuración del proxy SSL (de manera similar a lo que se hace en la configuración de la política de firewall).