GuiGui's Show

Soit un contrôleur iDRAC 8. Jusqu'à aujourd'hui, j'ai bossé exclusivement avec des iDRAC 6 mais bon, ça doit bien rien changer, non ? Comme d'hab, je lance la console virtuelle. Comme d'hab, je récupére un fichier « .jnlp ». Pour l'exécuter, sous Debian GNU/Linux Jessie (l'actuelle stable), il faut les packages openjdk-7-jre icedtea-7-plugin.

Mais, cette fois-ci, l'exécution foire : « Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line. ». La console java est juste imbitable donc allons-y pour exécuter en ligne de commande :

$ javaws viewer.jnlp
Attempted to download https://192.0.2.1:443/images/logo.gif, but failed to connect!
Attempted to download https://192.0.2.1:443/software/avctKVMIOLinux64.jar, but failed to connect!
Attempted to download https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar, but failed to connect!
Attempted to download https://192.0.2.1:443/software/avctKVM.jar, but failed to connect!
JAR https://192.0.2.1:443/software/avctKVM.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctKVMIOLinux64.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctKVM.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctKVMIOLinux64.jar not found. Continuing.
JAR https://192.0.2.1:443/software/avctVMAPI_DLLLinux64.jar not found. Continuing.
netx: Initialization Error: Could not initialize application. (Fatal: Initialization Error: Unknown Main-Class. Could not determine the main class for this application.)
[…]

Hum, donc l'applet n'arrive pas à récupérer des libs et des ressources en HTTPS depuis la BMC et donc forcément, elle n'a aucun code à exécuter… Pourtant, depuis ma machine, un wget https://192.0.2.1:443/images/logo.gif fonctionne très bien.

Sortons Wireshark. En utilisant l'applet java, on constate que la BMC interrompt directement la communication après la réception (ack) du message TLS « Client Hello ». Avec wget, aucun problème. Ça ne peut pas être un erreur de certificat puisque le serveur a refusé d'établir une session TLS avant même de transmettre son certif'. Dans ce type de cas, généralement, on est sur des grosses erreur bateau genre version de TLS ou suite d'algo de chiffrement/intégrité.

Avec l'applet java, la version TLS demandée au serveur est TLS 1.0. Avec wget, la version TLS demandée est TLS 1.2. Huuum, sortons notre openssl :

$ openssl s_client -connect 192.0.2.1:443 -tls1
CONNECTED(00000003)
140316040763024:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637:
[…]

Hé oui, à partir d'iDRAC 7 ou 8 version 2.40.40 ou supérieure, TLS 1.0 est désactivé par défaut.

Que faire ?

• Activer la prise en charge de TLS 1.0 côté BMC en utilisant racadm : nope, nope, nope. La version 1.0 de TLS est une passoire et le fait que la BMC soit dans un VLAN isolé n'est pas un motif suffisant pour l'utiliser !
  
  
• openjdk-8-jre et icedtea-8-plugin, dont on peut attendre une prise en charge de TLS 1.2 (ou au moins 1.1 :- ) ne sont dans dans Debian stable à l'heure actuelle. Je ne vais pas utiliser des packages de testing.
  
  
• Se passer de Java. Surtout que les applets Java seront dépréciées dans Java 9. C'est possible à partir d'iDRAC 8 qui propose une version HTML 5 de la console virtuelle. Pour l'activer, il faut aller dans l'item « Console virtuelle » du menu « Présentation générale ». Il faut changer la valeur de « Type de plug-in » pour « HTML5 ».