Bonjour à tous,
Depuis quelques temps je rencontre un problème récurrent sur l'ensemble de mes serveurs mutualisés chez ovh. En effet, j'ai l'habitude depuis plusieurs années d 'effectuer des requêtes vers mes serveurs à l'aide d'un micro-controleur (arduino) pour récupérer des données dans des installations. Cela fonctionnait très bien en HTTPS mais depuis quelques mois, moins d'un an impossible d'effectuer la requête sauf si je passe en HTTP. J'ai bien renouvelé le certificat SSL mais rien n'y fait!
OVH me dit que cela ne vient pas d'eux. Et pourtant quand je teste sur un autre prestataire (Hostway) cela fonctionne. Si vous aviez des idées pour m'éclairer car là je ne sais plus quoi faire. Merci par avance.
Bonjour @c929b74ea5e9851a7a48
Utilisez-vous le CDN ?
Si oui, avez-vous essayé de le désactiver ?
J'ai bien renouvelé le certificat SSL
Bonjour,
Votre arduino travaille-t-il avec des algorithmes obsolètes, comme TLS1.0 ou TLS1.1 par exemple ?
Peut-on connaître le nom de domaine hébergé chez OVH, pour voir le certificat et les cryptographies (cipher) supportées ?
Non je n'utilise pas de CDN. Merci pour votre retour.
Bonjour,
Je ne pense pas que cela soit un problème de TLS car l'arduino yun (branché en filaire) que j'utilise fonctionnait encore très bien il y a 8 mois environ et fonctionne encore aujourd'hui sur un autre hébergeur Hostway par exemple…
Pour le certificat et les cryptographies (cipher) supportées voici un des noms de domaine que j'utilise : https://julienlevesque.net/
Merci pour vos lumières !
Je ne pense pas que cela soit un problème de TLS car l'arduino yun (branché en filaire) que j'utilise fonctionnait encore très bien il y a 8 mois
Sachant que OVH a renforcer la connexion et que c'est du TLS1.2+ je vous conseil quand même de vérifier votre arduino.
Quel est le site que vous avez chez hostway ?
Cordialement, janus57
Merci je vais vérifier du coté arduino.
Chez hostway j'ai fait des tests ici. : et ça fonctionne parfaitement en https :
https://anabole.com/data-estu-la/get_val.php?id=1
une idée ? En vous remerciant
https://julienlevesque.net/
Ce serveur (cluster014) supporte TLS1.2 et TLS1.3
Voyez si vos librairies arduino sont compatibles.
Bonjour,
Et l'autre chose est qu'il faudrait le message d'erreur en https.
Cordialement, janus57
Après vérification le serveur https://anabole.com/ est en version tsl1.2 et ça fonctionne!
Ce n'est donc pas un problème de compatibilité de librairie semblerait-il .
encore des idée ? thanks 
Bonjour,
Après vérification le serveur https://anabole.com/ est en version tsl1.2 et ça fonctionne!
Mais avec des vieux ciphers de disponible qui pour 99% ne sont plus disponibles chez OVH.
Quid de l'erreur que vous avez lors de la récupération des données en https ?
Cordialement, janus57
Ce n'est donc pas un problème de compatibilité de librairie semblerait-il .
Outre le problème de version TLS (anabole.com supporte TLS1.2 et rien que TLS1.2)
il faut avoir un cipher (méthode d'encryptage) que les deux partenaires supportent.
HTTPS ça a l'air simple mais c'est une usine à gaz en coulisses.
Quid de l'erreur que vous avez lors de la récupération des données en https ?
Je n'ai pas d'erreur console ni dans l'arduino ni dans la console de la page html. L'arduino n'arrive juste pas a effectuer le run curl command en http sur des serveur ovh... il boucle "run curl command"
Je vais poster mon code si jamais !
#include
#include
#include
int result = 1;
void setup() {
pinMode(13, OUTPUT);
pinMode(12, OUTPUT);
Bridge.begin(); // Initialize the Bridge
Console.begin();
Serial.begin(9600); }
void loop() {
Process s;
s.runShellCommand("/usr/bin/curl -k 'https://julienlevesque.net/artworks/data_estu_la/get_val.php?id=100'");
// pour votre propre projet remplacer l'id ici 100 par l'id de votre équipe exemple : 110, 120, 130 …
Serial.println("run curl command");
while (s.running());
// Read command output. runShellCommand() should have passed "Signal: xx&":
while (s.available()) {
int result = s.parseInt();
Serial.println(result);
if (result == 0) {
digitalWrite(13, LOW); // turn the LED on (HIGH is the voltage level)
delay(500);
digitalWrite(12, LOW); // turn the LED on (HIGH is the voltage level)
delay(500);
}
if (result == 1) {
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
delay(500);
digitalWrite(12, HIGH); // turn the LED on (HIGH is the voltage level)
delay(500);
digitalWrite(13, LOW);
delay(500);
digitalWrite(12, LOW);
delay(500);
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
delay(500);
digitalWrite(12, HIGH); // turn the LED on (HIGH is the voltage level)
delay(500);
digitalWrite(13, LOW);
delay(500);
digitalWrite(12, LOW);
delay(500);
Serial.println("=============ça marche");
}
}
}
Je vais poster mon code si jamais !
Voyez la doc de vos librairies.
J'ai lancé deux tests chez ssllabs.
anabole supporte:
> # TLS 1.2 (suites in server-preferred order)
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS WEAK 128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS WEAK 256
> TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128
> TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256
> TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
> TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK 256
> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128
> TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256
> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112
julienlevesque.net (sur cluster014) supporte:
> # TLS 1.3 (suites in server-preferred order)
> TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519 (eq. 3072 bits RSA) FS 256
> TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519 (eq. 3072 bits RSA) FS 256P
> TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519 (eq. 3072 bits RSA) FS 128
> # TLS 1.2 (suites in server-preferred order)
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS 256
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS 256P
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128
> (P) This server prefers ChaCha20 suites with clients that don't have AES-NI (e.g., Android devices)
Si ton arduino veut absolument emplyer le cryptographie TLS_RSA_WITH_AES_128_CBC_SHA par exemple, qui est un algorithme considéré comme trop faible, il ne pourra pas discuter avec OVH parce que OVH ne l'a pas implémenté.
Cela fonctionnait très bien en décembre dernier lors de mes derniers tests… Arg !!
Cela fonctionnait très bien en décembre dernier
Oui mais rien n'est statique autour de vous...
Je n'ai touché à rien n'est pas une excuse... sinon on serait encore avec Windows 98.
Ah ah Windows 98 !
Donc si je résume mon problème viendrait des librairies employées et l'incompatibilité avec le système cryptographique utilisé par le serveur. J'avoue que cela dépasse un peu mes compétences mais je vais enquêter encore de ce côté.
Merci encore