TLS avec SAS : Les erreurs fréquentes
Lorsque vous vous attaquez à la sécurisation de votre environnement SAS, vous rencontrez, peut-être, des problèmes lors de l’intégration TLS.(Transport Layer Security, la norme de sécurisation par chiffrement de l'information, succédant à SSL).
Aussi, je vous propose ici les erreurs les plus fréquentes ainsi que quelques pistes pour le corriger.
ERROR: Unable to load extension: (tkessl)
Une erreur classique; la première que vous pouvez otbenir. Pour faire simple, SAS ne parvient à charger tkessl, le module en charge de la communication SSL (Secure Sockets Layer).
D'abord, vérifions la présence de la librairie TKESSL ;
Ce qui donne :
-r-xr-xr-x 1 sastux techsup 286414 Jun 19 2013 tkessl.so
puis, localison les libssl :
Ce qui donne :
Maintenant que nous avons vérifier la présence des pré-requis, nous pouvons faire quelques tests :
Ces premiers éléments devraient vous aider à y voir plus clair et vous aider à corriger votre problème.
Si ces quelques commandes ne vous permettent pas de fixer cette erreur, il faut aller plus lins et activer les traces.
Les événements liés à la sécurité sont maintenant enregistrées via le mécanisme SAS de logging facilty. Aussi, si l'option LOGCONFIGLOC = système est spécifié lorsque SAS démarre, l'enregistrement est effectué par AS logging facility. Ainsi, pour activer les traces SSL, vous pouvez ajouter le bloc suivant dans logconfig.xml :
Vous trouverez la liste des “Logger” SSL utilizable dans la documentation SAS Encryption:
SAS Logging Facility
Vous pouvez également obtenir ce message d’erreur si vous essayez d’accèder à une URL en HTTPS depuis une PROC http :
Ce message d’erreur se produit également si vous ne disposez pas de SAS/SECURE ou depuis SAS University Edition. Dans ce cas, pas de solution, HTTPS et FTPS ne sont pas supporté par SAS University Edition.
ERROR: HTTP proxy handshake failed.
Une connexion TLS (ou SSL) commence toujours pas un échange de message appelé hanshake (Poignée de main) ou négociation SSL. Cet étape permet au serveur de s’identifier auprès du client via un échange de clé publique, puis permet au client et au serveur de « coopérer » dans le processus de chiffrement/Déchiffrement. Sans se handshake préalable, pas de données chiffrées entre les deux parties.
Ce message peut se produire lors de la vérification du SNI (Server Name Indication).
En effet, le client indique le nom d'hôte (hostname) avec lequel il tente de démarrer une négociation TLS. Pour ne plus avoir ce message :
Ces erreurs remontent un problème lié à la FIPS 140-2, une norme de sécurité informatique du gouvernement américain utilisé pour accréditer les modules cryptographiques. FIPS 140-2 est pas une technologie, mais une définition de ce que les mécanismes de sécurité devraient faire. La norme définit les exigences de sécurité qui doivent être remplies par un module cryptographique utilisé dans un système de sécurité protégeant les informations non classifiées dans les systèmes informatiques.
Dans SAS, si FIPS est activé,SAS va tenter de charger un sous-ensemble particulier de bibliothèques OpenSSL, contenues dans le cadre du module d'objet OpenSSL FIPS. Ces bibliothèques ne sont pas présents par défaut et devront être téléchargés et compilés conformément aux instructions spécifiques spécifiées par la norme FIPS. Par conséquent, l'activation de FIPS est généralement pas recommandée, sauf si absolument nécessaire par la politique d'un client.
Pour vérifier si FIPS est activé :
Bien entendu, les bibliothèques OpenSSL standard sont capables de fournir un cryptage AES. Cependant, seules les bibliothèques de modules d'objets FIPS OpenSSL satisfont à la norme FIPS. Si l'option ENCRYPTFIPS est activée et que les bibliothèques ne sont pas présentes, le système SAS génère donc une erreur lorsqu'un serveur SAS doit agir en tant que client TLS et communiquer via le protocole HTTPS.
1 2 |
cd /install/SASFoundation/9.4/sasexe/ ls -lrt tkessl.so |
1 |
locate libssl |
1 2 3 4 5 6 |
/install/SASFoundation/9.4/sasexe/libssl.so install/SASFoundation/9.4/sasexe/libssl.so.0.9.8 install/SASFoundation/9.4/sasexe/libssl.so.1.0.0 /usr/lib64/libssl.so.1.0.0 /usr/lib64/libssl.so.10 /usr/lib64/libssl3.so |
1 |
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /saswork/GOLDEN/RC/LAX.V94.M3/install/SASFoundation/9.4 |
1 |
ldd –v tkessl.so |
1 2 3 4 |
linux-vdso.so.1 => (0x00007fff431ff000) libssl.so.0.9.8 (0x00007f869ed26000) libcrypto.so.0.9.8 (0x00007f869e999000) ... |
1 2 3 4 |
<logger name="App.tk.eam.ssl"> <level value="Trace"/> <appender-ref ref="TimeBasedRollingFile"/> </logger> |
1 2 3 |
proc http url="https://www.nicolas-housset.fr" ; run; |
1 2 3 4 |
RROR: Could not find extension: (tkessl) ERROR: An SSL cipher handle could not be created. ERROR: TK extension TKEAM could not be loaded. Most likely secure communications are not available on this system. ERROR: Unable to establish an SSL connection. |
- Sur les serveurs UNIX, assurez-vous que la variable d'environnement USE SSL SNI est pas définie.
- Sur les serveurs Windows, SNI est toujours envoyé. Hormis de désactiver la vérification du nom (Subject Alternative Name) sur les certificats de serveur, il n'y a actuellement pas solution de contournement (SAS 9.4 M3 Mai 2016)

1 |
proc options option = ENCRYPTFIPS;run; |