Certificats SSL

Authentification du serveur

La confiance implicite entre le client et l’appareil (car le client accepte le certificat généré par l’appareil) est un aspect important du proxy SSL. Il est extrêmement important que l’authentification du serveur ne soit pas compromise. Cependant, dans les faits, les certificats auto-signés et les certificats présentant des anomalies sont abondants. Les anomalies peuvent inclure des certificats expirés, des instances de nom commun ne correspondant pas à un nom de domaine, etc.

L’authentification du serveur est régie par la définition de l’option ignore-server-auth-failure dans le profil proxy SSL. Les résultats de la définition de cette option sont disponibles dans le tableau 1.

Tableau 1 : Ignorer l’option d’échec d’authentification du serveur

Action de profil de proxy SSL	Résultats
L’option ignore-server-auth-failure n’est pas définie (option par défaut)	Si l’authentification réussit, un nouveau certificat est généré en remplaçant les clés et en remplaçant le nom de l’émetteur par le nom de l’émetteur configuré dans le certificat de l’autorité de certification racine dans le profil proxy. En cas d’échec de l’authentification, la connexion est interrompue.
L’option ignore-server-auth-failure est définie	Si le certificat est auto-signé, un nouveau certificat est généré en remplaçant les clés. Le nom de l’émetteur n’est pas modifié. Ainsi, le navigateur client affiche un avertissement indiquant que le certificat n’est pas valide. Si le certificat a expiré ou si le nom usuel ne correspond pas au nom de domaine, un nouveau certificat est généré en remplaçant les clés et en changeant le nom de l’émetteur en SSL-PROXY : DUMMY_CERT :GÉNÉRÉ EN RAISON D’UN ÉCHEC DE L’AUTHENTIFICATION SRVR. Ainsi, le navigateur client affiche un avertissement indiquant que le certificat n’est pas valide. Nous déconseillons cette option d’authentification, car sa configuration a pour conséquence que les sites Web ne sont pas authentifiés du tout. Toutefois, vous pouvez utiliser cette option pour identifier efficacement la cause racine des sessions SSL interrompues. Reportez-vous à la section Activation du débogage et du suivi pour le proxy SSL.

Authentification du client

Actuellement, l’authentification des clients n’est pas prise en charge dans le proxy SSL. Si un serveur demande l’authentification du client, un avertissement est émis indiquant qu’un certificat n’est pas disponible. L’avertissement permet au serveur de déterminer s’il doit continuer ou quitter.

Optimisation des performances SSL

L’établissement de liaison SSL/TLS est un processus gourmand en ressources processeur. Étant donné que SSL/TLS est le protocole de sécurité le plus utilisé sur le Web, ses performances ont un impact significatif sur les performances Web.

À partir de Junos OS version 15.1X49-D120, vous pouvez utiliser les options suivantes pour optimiser les performances :

• Utiliser des échanges de clés RSA optimisés

• Utiliser le chiffrement authentifié avec données associées (AEAD) : AES128-CBC-SHA, AES256-CBC-SHA

• Gestion du cache de certificats : le cache de certificats stocke le certificat du serveur intercepté ainsi que les détails du certificat du serveur. Lors de l’établissement de liaison SSL/TLS, le proxy SSL peut présenter le certificat interdit mis en cache au client au lieu de générer le nouveau certificat interdit.

L’amélioration des performances SSL permet d’améliorer les performances du site Web sans compromettre la sécurité et d’optimiser l’expérience utilisateur.

Si vous le souhaitez, vous pouvez configurer les paramètres suivants pour votre cache de certificats. Toutefois, nous vous recommandons de conserver les valeurs par défaut.

Exemple:

• (Facultatif) Définissez la valeur du délai d’expiration du cache de certificats (par exemple, 300 secondes).

  Dans cet exemple, le cache de certificats stocke les détails du certificat pendant 300 secondes. La valeur par défaut du délai d’attente est de 600 secondes.

• (Facultatif) Désactivez le cache de certificats.

  Lorsque vous désactivez le cache de certificat, l’appareil autorise l’établissement de liaison SSL complet pour une nouvelle connexion. Par défaut, le cache de certificat est activé.

• (Facultatif) Invalider le cache de certificats existant.

  Dans cet exemple, l’appareil invalide le cache de certificats existant lors de la mise à jour de la liste de révocation de certificats (CRL). Par défaut, l’option Invalider le cache de certificat lors de la mise à jour de la liste de révocation de certificats est désactivée.

Reprise de session

La reprise de session SSL fournit un mécanisme permettant de reprendre une session précédente à l’aide d’ID de session déjà négociés. La reprise de session évite au client et au serveur les frais de calcul liés à l’établissement d’une liaison SSL complète et à la génération de nouvelles clés primaires.

La reprise de session raccourcit le processus d’établissement de liaison et accélère les transactions SSL, ce qui permet d’améliorer les performances tout en maintenant un niveau de sécurité approprié.

TLS 1.2 prend en charge la reprise de session avec des identificateurs de session et des mécanismes de tickets de session. La reprise d’une session SSL comprend les étapes suivantes :

• Un mécanisme de mise en cache de session met en cache les informations de session, telles que la clé secrète pré-maître et les chiffrements convenus pour le client et le serveur.

• L’ID de session identifie les informations mises en cache.

• Lors des connexions ultérieures, les deux parties conviennent d’utiliser l’ID de session pour récupérer les informations plutôt que de créer une clé secrète pré-master.

À partir de la version 22.1R1 de Junos OS, TLS 1.3 prend en charge la reprise de session à l’aide d’une clé pré-partagée (PSK) dans le proxy SSL. La reprise de session à l’aide de PSK permet de reprendre une session avec une clé secrète partagée précédemment établie afin de réduire les frais d’établissement de liaison SSL.

La PSK est une clé de chiffrement unique dérivée de l’établissement de liaison TLS initial. Après une négociation TLS réussie, le serveur envoie une identité PSK au client. Le client utilise cette identité PSK lors des futures négociations pour négocier l’utilisation de la PSK associée afin de reprendre la session.

La reprise d’une session SSL avec TLS1.3 comprend les étapes suivantes :

1. Après une première négociation TLS, le serveur envoie un nouveau message de ticket de session au client, qui contient l’identité PSK (copie chiffrée de la PSK).

2. La prochaine fois que le client tentera de reprendre la session, il enverra le même ticket de session au serveur dans le message Hello.
3. Le serveur déchiffre le message, identifie la clé PSK et récupère les informations de session de son cache pour reprendre la session.

Un SSL-I (initiation SSL) utilise PSK avec le mode d’échange de clés ECDHE, et SSL-T (terminaison SSL) utilise PSK et PSK avec les modes d’échange ECDHE.

La session proxy SSL prend en charge l’interopérabilité entre TLS1.3 et TLS1.2 et les versions antérieures aux deux extrémités d’une connexion pour la reprise de session.

Par défaut, la reprise de session est activée pour le proxy SSL. Vous pouvez effacer la reprise de session ou la réactiver selon vos besoins.

• Pour effacer la reprise de session :
• Pour réactiver la reprise de session :

Utilisez la commande suivante pour configurer la valeur du délai d’expiration de la session.

Vous pouvez configurer la valeur du délai d’attente entre 300 secondes et 86400 secondes. La valeur par défaut est 86400 secondes (24 heures).

Renégociation de session

Le pare-feu SRX Series prend en charge la renégociation de session. Une fois qu’une session est créée et que le transport de tunnel SSL est établi, une modification des paramètres SSL doit être renégociée. Le proxy SSL prend en charge la renégociation sécurisée (RFC 5746) et non sécurisée (TLS v1.0, TLS v1.1 et TLS v1.2). Lorsque la reprise de session est activée, la renégociation de session est utile dans les situations suivantes :

• Les clés de chiffrement doivent être actualisées après une session SSL prolongée.

• Des chiffrements plus puissants doivent être appliqués pour une connexion plus sécurisée.

Si vous modifiez le profil de proxy SSL en modifiant un certificat, une force de chiffrement ou une liste d’autorités de certification de confiance, le système vide les entrées de cache lorsque vous validez la stratégie modifiée. Dans ce cas, une négociation complète est nécessaire pour établir les nouveaux paramètres SSL. (Il n’y a aucun impact sur les sessions non-SSL.)

Si le profil proxy SSL n’est pas modifié, les entrées de cache correspondant à ce profil ne sont pas vidées et la session se poursuit.

Négociation de StartTLS pour les sessions SMTP

Le StartTLS permet une session SMTP à partir d’une connexion TCP simple initiale vers une connexion TLS plus sécurisée. StartTLS autorise la session SMTP entre le serveur et le client sur la couche TLS après une négociation réussie entre les pairs. StartTLS met à niveau une connexion SMTP ordinaire non sécurisée existante vers une connexion SSL/TLS sécurisée.

Vous pouvez définir un seuil qui vous permet de décider combien de temps attendre avant d’ignorer la session si StartTLS n’est pas reçu du client.

Vous pouvez configurer les options suivantes :

• byte-threshold : nombre minimal d’octets de session non chiffrée autorisés avant d’ignorer la session si StartTLS n’est pas reçu du client. Plage de 100 à 300.
• packet-threshold : nombre de paquets non chiffrés autorisés dans le sens client-serveur avant d’ignorer la session si StartTLS n’est pas reçu du client. Plage de 1 à 15.

Exemple:

Dans cet exemple, le proxy SSL autorise 100 octets de trafic SMTP brut (non chiffré). Après avoir atteint 100 octets, il ignore la session si StartTLS n’est pas reçu du client.

Dans cet exemple, le proxy SSL autorise 2 paquets de trafic SMTP simple (non chiffré). Après avoir atteint 2 paquets, il ignore la session si StartTLS n’est pas reçu du client.

Résolution dynamique des noms de domaine

Les adresses IP associées aux noms de domaine sont dynamiques et peuvent changer à tout moment. Chaque fois qu’une adresse IP de domaine change, elle est propagée à la configuration du proxy SSL (de la même manière que dans la configuration de la stratégie de pare-feu).