Authentification par certificat Client de GlobalProtect côté change avec PAN-OS 7.1.4

Authentification par certificat Client de GlobalProtect côté change avec PAN-OS 7.1.4

35913
Created On 09/25/18 18:59 PM - Last Modified 04/20/20 23:58 PM


Resolution


Ce document se concentre sur les modifications apportées au PAN-OS version 7.1.4/7.0.10 (Numéro ID 95864) qui peuvent affecter les déploiements qui utilisent l’authentification du certificat client côté GlobalProtect. En particulier, cela concerne les déploiements où les certificats clients sont signés à l'Aide d'algorithmes de hachage SHA512 ou SHA384. La question peut également affecter des utilisateurs où les certificats clients sont SHA1/SHA256 signé, mais l’autorité de certification est signée par SHA384/SHA512.

 

Description du problème

Après mise à niveau sur PAN-OS 7.1.4/7.0.10 (ou plus), les clients de GlobalProtect ne sont pas en mesure de s’authentifier en utilisant les certificats côté client signés avec SHA512 ou SHA384. GlobalProtect Agent est affichage de message d’erreur « Required certificat client n’est pas trouvé ».

 

Comportement avant PAN-OS version 7.1.4/7.0.10

Avant la version 7.1.4/7.0.10, nous avons eu le comportement suivant lors de la poignée de main SSL entre GlobalProtect agent et GlobalProtect Portal/Gateway si TLS 1,2 est utilisé:

  • Client (Agent de GP) envoie des message « Client Hello »
  • Serveur (pare-feu avec GP portail/configurée passerelle) envoie « Serveur Hello » message, ainsi que du certificat côté serveur
  • Si la vérification du certificat client est configurée sur le côté de pare-feu (configuration « Profil de certificat »), le serveur enverra « Demande de certificat » message au client
  • « Demande de certificat » message contient (entre autres) :

1. « Des noms uniques » / liste d’autorités de certification, le serveur attend certificat client doit être signé avec

2. « Signature les algorithmes de hachage » / liste des hachages que le serveur prend en charge **

* *Ce message est envoyé uniquement lorsque TLS 1,2 est utilisé; TLS 1.1/TLS 1,0 n'ont pas ce message spécifié dans la norme

 713_Hash_Advertised.jpg

 

  • Nous pouvons voir que le serveur envoie la liste des algorithmes de hachage supportés : SHA1, SHA256, SHA384 et SHA512

 

Processus de vérification pour le certificat client comprend (entre autres) :

1. Vérifier que le client détache la clé privée du certificat annoncé; Ceci est fait en utilisant le message'certificate verifier' échangé pendant la poignée de main

2. Vérifier que le certificat client est signé par l’autorité mentionnée dans le « émetteur » déposée (vérification de chaîne de certificat)

  • Pare-feu de PAN-OS supporte SHA1 et SHA256 hachages pour vérification de message « Certificat vérifier », mais SHA384 et SHA512 n’étaient pas supportés
  • Hachages plus élevés ont été incorrectement publiés dans TLS 1.2 (dans PAN-OS versions 7.1.3/7.0.9 et en dessous)
  • Dans le même temps, le pare-feu est en mesure de vérifier la chaîne de certiifcate à l’aide de SHA1, SHA256, SHA384 et SHA512 
  • Algorithme de hachage utilisé pour le message'certificate Verify' n' a pas à correspondre à l'algorithme utilisé pour signer le certificat du client (qui est fait par ca)
  • Nous pouvons avoir SHA512 signé le certificat et le message « Vérifier certificat » signé par SHA1 (algorithme utilisé est déterminé par la pile de système d’exploitation SSL côté client)
  • Dans TLS 1.2 « Certificat Verify » message peut être signé par un hachage annoncé par le serveur (dans la liste des hashes supportés) 

 

Message « Certificate Verify » est :

  • Utilisé pour démontrer le client possède la clé privée du certificat qu’il a envoyé précédemment (pendant la négociation SSL)
  • Créé par previosly échangée SSL handshake messages de hachage avec la clé privée du client
  • Souvent hachés à l’aide de SHA1 et ce hachage est pris en charge par le pare-feu

 

Même si le certificat a été signé avec SHA512, si le message « Vérifier certificat » a été signé avec SHA1 ou SHA256, nous pouvons toujours effectuer vérification de certificat approprié : tant pour le client et l’émetteur/chaîne de possession de clés privées

  Certificate_Verify.jpg

 

De pare-feu déboguer des journaux :

2016-09-26 10:40:49.276 + 0200 Debug: pan_ssl3_server_process_handshake (pan_ssl_server. c:1648): Receive Certificate Verify
2016-09-26 10:40:49.276 + 0200 Debug: pan_ssl3_server_verify_client_certificate (pan_ssl_server. c:1358): dans le client CERT, TLS 1.2 ou over est utilisé avec SHA1.

 

Si message « Certificat vérifier » fini par être signée par SHA384 ou SHA512 (les deux algorithmes ont été annoncés), on serait pas en mesure de vérifier le certificat correctement

 

 

Comportement à PAN-OS version 7.1.4 et versions ultérieures

Dans Pan-OS 7.1.4/7.0.10, nous avons le changement de comportement suivant lors de la poignée de main SSL si TLS 1,2 est utilisé:

  • Client (GlobalProtect Agent) et le serveur (GlobalProtect portail/passerelle) échangent des messages SSL « Hello »
  • Serveur demande certificat client en envoyant « Demande de certificat » 
  • « Demande de certificat » est maintenant mentionner uniquement les hashs nous soutenons effectivement pour « Certificat ordonnancée » : SHA1 et SHA256

 
714_Hash_Advertised.jpg

 

  

  • Si le client utilise des certificats de client signés SHA384 ou SHA512, le système d'exploitation peut décider de ne pas les utiliser du tout, car ils sont hachés avec les algorithmes non pris en charge par le serveur  
  • Similaire peut se produire si le certificat client est signé avec hachage SHA256/SHA1, mais l’autorité de certification est signée avec SHA384/SHA512
  • Le résultat final peut être que le client n’envoie pas le certificat du tout et l’authentification échoue 
  • L’authentification peut être couronnée de succès si le système d’exploitation a décidé d’envoyer le certificat et l’utilisation de SHA1/SHA256 pour message « Certificat vérifier »

 714_Error_Zero_Lenght.jpg

 

 

Solutions de contournement

TLS 1,1, comme opossed à TLS 1,2, n'envoie pas la liste des «algorithmes de hachage de signature» (hachages pris encharge) dans le message «demande de certificat».  Si nous limitons TLS/SSL profil lié à GlobalProtect portail/porte de TLS 1.1, nous pouvons avoir un comportement similaire aux communiqués de pre-7.1.4/7.0.10. Nous ne limiterons pas système de mode côté client en envoyant des certificats avec des hachages plus élevés. Notez que ce déploiement peut encore avoir des problèmes si le message « Vérifier certificat » est signé avec SHA384/SHA512.

 TLS_Profile_Changes.jpg

 

 

TLS 1.2 peut être utilisé pour SHA1/SHA256 signé les certificats.

 

Si tous les certificats utilisés sont SHA384 ou supérieur, les paramètres de protocole peuvent être définis sur TLSv1.2 ou plus

Max tls.png

 

Remarque

PAN-OS 7.1.8 ajouté le support pour le certificat de côté de client SHA384. Depuis les notes de version :

« PAN‐62057 fixe un problème où le GlobalProtect agent n’a pas pu s’authentifier en utilisant un client de certificat qui avait un algorithme de signature qui n’était pas SHA1/SHA256. Grâce à cette correction, le pare-feu prend en charge l’algorithme SHA384 de signature pour l’authentification client‐based. »



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClScCAK&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language