Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IDP SSL Inspection

Secure Sockets Layer (SSL), également appelé Transport Layer Security (TLS), est une suite de protocoles pour la sécurité Web qui assure l’authentification, la confidentialité et l’intégrité des messages. L’authentification protège contre les transmissions frauduleuses en permettant à un navigateur Web de valider l’identité d’un serveur Web. Les mécanismes de confidentialité garantissent la confidentialité des communications. SSL renforce la confidentialité en cryptant les données pour empêcher les utilisateurs non autorisés d’écouter les communications électroniques. Enfin, l’intégrité des messages garantit que le contenu d’une communication n’a pas été altéré.

Pour plus d’informations, consultez les rubriques suivantes :

Présentation d’IDP SSL

Chaque session SSL commence par un handshake au cours duquel le client et le serveur s’entendent sur la clé de sécurité spécifique et les algorithmes de chiffrement à utiliser pour cette session. À ce stade, le client authentifie également le serveur. En option, le serveur peut authentifier le client. Une fois la poignée de main terminée, le transfert des données cryptées peut commencer.

Juniper Networks fournit une inspection SSL de détection et de prévention des intrusions (IDP) qui utilise la suite de protocoles SSL composée de différentes versions SSL, chiffrements et méthodes d’échange de clés. Associée à la fonction d’identification des applications, la fonction d’inspection SSL permet aux pare-feu SRX Series d’inspecter le trafic HTTP chiffré en SSL sur n’importe quel port. Les protocoles SSL suivants sont pris en charge :

  • SSLv2

  • SSLv3

  • TLS

Chiffrements SSL IDP pris en charge

Un chiffrement SSL comprend le chiffrement par chiffrement, la méthode d’authentification et la compression. Junos OS prend en charge tous les chiffrements pris en charge par OPENSSL qui n’impliquent pas l’utilisation de clés privées temporaires. Pour l’authentification, les méthodes d’authentification NULL, MD5 et SHA-1 sont prises en charge.

Note:

La compression et les chiffrements SSLv2 ne sont pas pris en charge. Actuellement, la plupart des serveurs SSL sont automatiquement mis à niveau vers un chiffrement TLS lorsqu’un chiffrement SSLv2 est reçu dans un message client « hello ». Vérifiez votre navigateur pour voir à quel point les chiffrements peuvent être forts et ceux que votre navigateur prend en charge. (Si le chiffrement ne figure pas dans la liste des chiffrements pris en charge, la session est ignorée pour une inspection approfondie des paquets.)

Le tableau 1 présente les algorithmes de chiffrement pris en charge par les pare-feu SRX Series.

Matériau clé
Tableau 1 : algorithmes de chiffrement pris en charge
Chiffrement Type exportable Matériau clé étendu Clé effective Bits IV Taille

NULL

Non

Flux

0

0

0

S.O.

DES-CBC-SHA

Non

Bloc

8

8

56

8

DES-CBC3-SHA

Non

Bloc

24

24

168

8

AES128-SHA

Non

Bloc

16

16

128

16

AES256-SHA

Non

Bloc

32

32

256

16

Pour plus d’informations sur les algorithmes de chiffrement, consultez Vue d’ensemble du VPN IPsec. Le tableau 2 présente les chiffrements SSL pris en charge.

Tableau 2 : chiffrements SSL pris en charge
Valeur de Cipher Suites

TLS_RSA_WITH_NULL_MD5

TLS_RSA_WITH_NULL_SHA

TLS_RSA_WITH_DES_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

0x0001

0x0002

0x0009

0x000A

0x002F

0x0035

Note:

Les chiffrements RC4 et IDEA ne sont pas pris en charge en raison de la disponibilité de la licence et de la bibliothèque OPENSSL.

Comprendre IDP Internet Key Exchange

IKE (Internet Key Exchange) établit un secret prémaître utilisé pour générer des clés symétriques pour le chiffrement et l’authentification des données en masse. La section F.1.1 de la RFC 2246 définit les méthodes d’authentification TLS (Transport Layer Security) et d’échange de clés. Les trois principales méthodes d’échange sont les suivantes :

  • RSA : Rivest-Shamir-Adleman (RSA) est un algorithme d’échange de clés qui régit la façon dont les participants créent des clés symétriques ou un secret utilisé pendant une session SSL. L’algorithme d’échange de clés RSA est la méthode la plus couramment utilisée.

  • DSA — Digital Signature Algorithm (DSA) ajoute une option d’authentification supplémentaire aux propositions de la phase 1 de l’IKE. Le DSA peut être configuré et se comporte de manière analogue au RSA, ce qui oblige l’utilisateur à importer ou à créer des certificats DSA et à configurer une proposition IKE pour utiliser le DSA. Les certificats numériques sont utilisés pour les signatures RSA, les signatures DSA et la méthode d’authentification basée sur le chiffrement à clé publique RSA dans le protocole IKE.

  • Diffie-Hellman — Diffie-Hellman (DH) est une méthode d’échange de clés qui permet aux participants de produire une valeur secrète partagée. La force de la technique est qu’elle permet aux participants de créer la valeur secrète sur un support non sécurisé sans passer la valeur secrète à travers le fil.

Les méthodes d’échange de clés peuvent utiliser une clé de serveur fixe ou temporaire. IDP ne peut récupérer le secret prémaître que si une clé de serveur fixe est utilisée. Pour plus d’informations sur Internet Key Exchange, reportez-vous à la section Éléments de base de l’ICP dans Junos OS.

Note:

Juniper IDP ne déchiffre pas les sessions SSL qui utilisent l’échange de clés Diffie-Hellman.

Présentation du traitement des clés cryptographiques IDP

Grâce à la fonction de déchiffrement SSL (Secure Sockets Layer) d’Intrusion Detection and Prevention (IDP), les pare-feu SRX Series chargent les clés privées RSA configurées en mémoire et les utilisent pour établir des clés de session SSL afin de déchiffrer les données. IDP est tenu de déchiffrer les clés RSA et d’en vérifier l’intégrité avant d’effectuer des opérations normales de chiffrement ou de déchiffrement à l’aide des clés.

L’objectif principal de cette fonctionnalité est de s’assurer que les clés privées RSA utilisées par IDP ne sont pas stockées sous forme de texte brut ou dans un format facilement compréhensible ou utilisable. Les clés sont déchiffrées pour effectuer des opérations normales de chiffrement ou de déchiffrement. Cette fonctionnalité implique également des contrôles de détection d’erreurs lors de la copie des clés d’un emplacement mémoire à un autre, ainsi que l’écrasement du stockage intermédiaire par des modèles non nuls lorsque les clés ne sont plus nécessaires.

La set security idp sensor-configuration ssl-inspection key-protection commande de configuration CLI permet d’activer cette fonctionnalité.

Présentation de la gestion des clés de serveur SSL IDP et de la configuration des stratégies

L’appareil peut prendre en charge jusqu’à 1000 clés privées de serveur. Chaque clé peut avoir jusqu’à 100 serveurs qui l’utilisent. Cette capacité est la même quel que soit le nombre de SPU disponibles sur l’appareil, car chaque SPU doit pouvoir accéder à toutes les clés.

Plusieurs serveurs peuvent partager la même clé privée ; Toutefois, un serveur ne peut avoir qu’une seule clé privée. Le déchiffrement SSL est désactivé par défaut. Les clés simples et chiffrées sont prises en charge.

Note:

Junos OS ne chiffre pas le fichier de clés SSL.

Note:

Vous pouvez définir la valeur du paramètre de délai d’expiration du cache de l’ID de session SSL à l’aide de la set security idp sensor-configuration ssl-inspection session-id-cache-timeout commande. La valeur par défaut du paramètre de délai d’expiration du cache est 600 secondes.

Configuration d’une inspection SSL IDP (procédure CLI)

Le décodeur SSL est activé par défaut. Si vous devez l’activer manuellement via l’interface de ligne de commande, utilisez la commande CLI suivante.

Pour configurer une inspection SSL IDP, utilisez la procédure CLI suivante :

Le capteur inspecte désormais le trafic pour lequel il dispose d’une paire clé/serveur.

Note:

Nombre maximal de sessions prises en charge par SPU : la valeur par défaut est 10 000 et la plage est comprise entre 1 et 100 000. La limite de session est par SPU, et elle est la même quel que soit le nombre de SPU sur l’appareil.

Ajout de clés SSL IDP et de serveurs associés

Lorsque vous installez une clé, vous pouvez la protéger par mot de passe et l’associer à un serveur.

Pour installer une clé PEM (Privacy-Enhanced Mail), utilisez la commande CLI suivante :

Note:

Dans un cluster SRX Series à deux nœuds, la clé doit être copiée manuellement sur le nœud 0 et le nœud 1 au même emplacement pour que la commande request réussisse.

Vous pouvez également associer la clé à un serveur ultérieurement à l’aide de la commande add server CLI. Un serveur ne peut être associé qu’à une seule clé. Pour associer un serveur à la clé installée, utilisez la commande CLI suivante :

Note:

La longueur maximale du nom de clé est de 32 octets, y compris la terminaison « \0 ».

Suppression des clés SSL IDP et des serveurs associés

  • Pour supprimer toutes les clés et tous les serveurs, utilisez la commande CLI suivante :

    Toutes les clés installées sont supprimées ainsi que tous les serveurs associés.

  • Pour supprimer une clé spécifique et tous les serveurs associés à cette clé, utilisez la commande CLI suivante :

    Supprime la clé spécifiée et tous les serveurs associés à cette clé.

  • Pour supprimer un seul serveur, utilisez la commande CLI suivante :

    Supprime le serveur spécifié lié à la clé spécifiée.

Affichage des clés SSL IDP et des serveurs associés

  • Pour afficher toutes les clés de serveur installées et le serveur associé, utilisez la commande CLI suivante :

    Affiche toutes les clés de serveur et les adresses IP liées à ces clés. L’exemple suivant montre la sortie CLI lorsque la show security idp ssl-inspection key commande est utilisée :

  • Pour afficher les adresses IP liées à une clé spécifique, utilisez la commande CLI suivante :

    Voici un exemple de sortie CLI reçue lorsque la show security idp ssl-inspection key <key-name> commande est utilisée :

Exemple : configuration d’IDP lorsque le proxy SSL est activé

Cet exemple décrit comment IDP prend en charge la fonctionnalité d’identification d’application (AppID) lorsque le proxy SSL est activé.

Exigences

Avant de commencer :

Aperçu

Cet exemple montre comment configurer IDP dans une règle de stratégie lorsque le proxy SSL est activé.

Configuration

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez-collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.

Procédure

Procédure étape par étape

L’exemple suivant vous demande de naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la procédure à suivre, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande.

Dans cet exemple, vous configurez une stratégie de sécurité qui utilise IDP comme service d’application.

  1. Configurez une stratégie pour traiter le trafic avec le profil proxy SSL ssl-profile-1.

  2. Définissez IDP comme le service d’application.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant la show security policies commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.

Vérification

Vérifiez que la configuration fonctionne correctement. La vérification dans IDP est similaire à la vérification dans Application Firewall. Voir Pare-feu applicatif.

Tableau de l’historique des versions
Libération
Description
15,1X49-D100
À partir de 15.1X49, la fonctionnalité IDP SSL Inspection est obsolète. Juniper recommande d’utiliser la fonctionnalité de proxy SSL.