Je suis récemment passé à Haproxy de AWS ELB. Je me termine SSL à l'équilibreur de charge (Haproxy 1.5Dev19).
Depuis la commutation, je continue d'obtenir des erreurs de connexion SSL dans le journal haproxy (5 à 10% du nombre total de demandes). Il y a trois types d'erreurs répétant: Connexion fermée pendant la poignée de main SSL Timeout pendant la poignée de main SSL Échec de la poignée de main SSL (celle-ci se produit rarement)
J'utilise un certificat StartsSL gratuit, alors ma première pensée était que certains hôtes ont du mal à accepter ce certificat et que je n'ai pas vu ces erreurs dans le passé, car ELB n'offre aucune journalisation. Le seul problème est que certains hôtes ont finalement des connexions réussies.
Je peux me connecter aux serveurs sans aucune erreur, je ne sais donc pas comment reproduire ces erreurs à ma fin.
3 Réponses :
Cela ressemble à des clients qui disparaissent au milieu de la poignée de main (TCP TVS ou Timeout). Ce serait normal à un certain taux, mais 5-10% semble trop élevé. Il est possible que c'est un problème de certificat; Je ne suis pas certain de savoir exactement comment cela représente
choses qui se produisent pour moi:
Voyez-vous des hôtes individuels qui réussissent parfois et parfois échouent? Si tel est le cas, il est peu probable que ce soit un problème de certificat. Je ne sais pas comment les connexions sont traitées lorsqu'un utilisateur rejette un certificat non approuvé.
Vous pouvez utiliser Wireshark sur la machine Haproxy pour capturer des poignées de main SSL et les analyser (vous n'aurez pas besoin de déchiffrer les sessions de l'analyse de la poignée de main, bien que vous puissiez puisque vous avez la clé privée du serveur).
Merci tim pour une réponse très approfondie. En réalité, c'était exactement votre première hypothèse, donc je posterai les détails ici au cas où n'importe qui a un problème similaire. Nous avons utilisé ce backend pour servir un certain nombre d'applications Android qui envoiaient des analyses tout comme elles étaient fermées. Parfois (souvent sur Android, moins souvent sur iOS), il n'y avait pas assez de temps pour compléter la demande et l'application serait tuée lors de la négociation HTTPS ou immédiatement après, ce qui a entraîné une demande BADREQ marquée par Haproxy. Finalement, j'ai fini par utiliser Ssldump et analysez exactement ce qui se passait mal.
Comment votre frontend Haproxy SSL est-il configuré?
Par exemple, j'utilise ce qui suit pour atténuer les attaques de bêtes: Bind X.x.x.x: 443 SSL CRT /ETC/HAPROXY/SSL/XXXX.PEM NO-SSLV3 CIPHERS RC4-SHA: AES128-SHA: AES256-SHA
Mais certains clients semblent générer les mêmes erreurs de «défaillance de la poignée SSL». Je pense que c'est parce que la configuration est trop restrictive.
J'avais cela aussi. Les éléments suivants sont apparus pour la première fois SSL Handshake Echec puis après la mise hors tension AT Premièrement, je me suis assuré que tous les délais d'attelage étaient corrects. Malheureusement, le problème figurait dans la section Il y avait une ligne avec Il semble que certains clients étaient lents à se connecter et de se faire expulser pendant la poignée de main SSL. Vérifiez votre frontage pour les délais d'attente du client. OPTION DONTLOGNULL Nous avons également le délai d'expiration pendant la poignée de main SSL dans les journaux HAPROXY. frontal Timeout Client 60 que je suppose que signifie signifie 60ms au lieu de 60s . .
Merci, Adnan. C'était en effet la question, j'ai documenté cela dans mon commentaire sur la réponse de Tim.