FreeTDS ne parvient pas à se connecter à SQL Server après des correctifs Windows récents et TLS1 étant désactivé

Nous avons eu cette erreur par intermittence après l'application de correctifs Linux et MS. Nous pourrions toujours nous connecter de Linux au server MSSQL mais notre connection se terminerait randomment avec l'erreur EOF … même au milieu d'une requête. J'ai allumé le journal de freetds et j'ai vu un échec de poignée de main de encryption comme ceci:

  net.c:1366:handshake failed: A TLS packet with unexpected length was received. login.c:466:login packet rejected util.c:331:tdserror(0x1e752b0, 0x2c27f40, 20002, 0) 

Après beaucoup de dépannage, nous avons annulé KB3172605 sur le server MS Windows Server 2008 R2 qui exécute notre database MS SQL Server … il a résolu le problème. (KB 3172605 remplace KB 3161639.)

TLDR; J'avais besoin de ré-installer freetds avec le support de gnutls au lieu de openssl.

Après beaucoup (pas, vraiment beaucoup) d'essais et d'erreurs j'ai finalement trouvé une solution à freetds sur le mac ne se connectant pas.

J'ai encore besoin de câbler le rest pour que pyodbc fonctionne, etc. mais voici la solution de base:

brew edit freetds

Remplacer la formule freetds avec ce https://gist.github.com/hanleybrand/dfb7b9004aae250fabd01cd2466251c4

En bref, il ajoute l'option --with-gnutls à l'installation de armsage et s'assure que si elle existe elle se produit avant --with-openssl . Je ne l'ai pas examiné beaucoup, mais je soupçonne que openssl / gnutls est soit / ou et et non et / ou.

brew rm freetds && brew install freetds --with-gnutls --with-unixodbc

Après cela, tsql a bien fonctionné – comme je l'ai mentionné plus haut, je dois encore configurer le rest (unixodbc, pyodbc), mais je suis assez confiant que si tsql fonctionne, le rest le sera également, bien que je ne sois pas entièrement sûr.

Cela peut être lié à des sets de chiffrement dans les deux packages (openssl agains gnutls) comme le souligne @FlipperPA

J'ai fait beaucoup de tests avec ceci, et notre solution était de restaurer ce patch:

https://support.microsoft.com/en-us/kb/3161639

Apparemment, la suite de chiffrement affecte plus que Edge et IE. 🙂 J'ai ouvert une affaire avec Microsoft et ils sont conscients des problèmes que cela a causés. De la bouche du cheval:

Étant donné que le problème ne se produit plus après la désinstallation de cette mise à jour de la base de connaissances, j'ai effectué une search rapide sur cette mise à jour pour les cas antérieurs. À ce jour, il y a eu 21 cas de problèmes avec cette mise à jour depuis le mois dernier. Si vous n'êtes pas au courant de mes searchs, KB 3161639 ajoute des keys de chiffrement supplémentaires qui utilisent le protocole TLS 1.2 introduit dans la mise à jour KB 3161608. Les chiffrements suivants sont probablement ceux qui provoquent le problème:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Je soupçonne que votre server Unix / Linux et / ou FreeTDS ODBC ne supporte pas ces suites de chiffrement ou n'est pas configuré pour cela.
Cela dit, vous avez quelques options:

1. Utilisez la solution de contournement de ne pas avoir la mise à jour KB 3161639 installée
2. Réinstallez la mise à jour KB 3161639. Configurer votre ordre de chiffrement pour vous assurer que les nouvelles suites de chiffrement ne sont pas choisies.

Nous sums allés avec l'option 1, et nous l'avons déployée sur notre réseau, et nous n'avons constaté aucun effet néfaste. J'espère que ça aide.

Je voyais le même comportement sous FreeTDS (version 0.91) après les récents correctifs de Microsoft.

En résumé, la mise à jour de FreeTDS sur l'instantané nocturne disponible sur http://www.freetds.org/ ( 1.00.24 partir de ce post) a résolu le problème pour moi. J'ai compilé la source et mis à jour la ligne de pilote FreeTDS dans le file de configuration odbcinst.ini pour pointer vers le nouveau file object partagé ( <path>/libtdsodbc.so ), par exemple:

 [TDS] Description = FreeTDS Driver Driver = /usr/local/lib/libtdsodbc.so 

Au début de septembre 2016, il y a eu des validations liées à OpenSSL sur FreeTDS, y compris cette validation , qui fait reference à une incompatibilité de correctif Microsoft:

Mettre à jour la list de chiffrement OpenSSL

Cela augmente la security et corrige également une incompatibilité récente entre OpenSSL et SChannel (les versions de SChannel ont été corrigées dans quelques mois).

Basé sur d'autres commentaires ici qui pointent vers un problème de compatibilité de la suite de chiffrement, cela peut avoir été le commit qui a arrangé les choses. Cependant, à partir de ce post, il n'y a pas encore eu de version officielle de FreeTDS incluant ce commit (la dernière version officielle était la version 1.0 en mai 2016).

Références aux correctifs Microsoft mentionnés dans d'autres commentaires:

• KB3161639 à partir de juin 2016 correctifs cumulatifs.

  Cet article décrit une mise à jour dans laquelle les nouvelles suites de chiffrement TLS sont ajoutées et les priorités par défaut de la suite de chiffrement sont modifiées dans Windows RT 8.1, Windows 8.1, Windows Server 2012 R2, Windows 7 ou Windows Server 2008 R2. Ces nouvelles suites de chiffrement améliorent la compatibilité avec les servers qui prennent en charge un set limité de suites de chiffrement.

• KB3172605 à partir de juillet 2016 patchs rollups (et re-publié en septembre 2016). Description de ce correctif de l'article de l' historique des mises à jour de Windows Server 2008 R2 SP1 :

  21 juillet 2016 – KB3172605 Cette mise à jour inclut des améliorations de la qualité. Aucune nouvelle fonctionnalité du operating system n'est introduite et aucune nouvelle mise à jour de security n'est incluse. Les principaux changements include:

  • Prise en charge améliorée dans l'interface de programmation d'applications cryptocharts Microsoft (CryptoAPI) pour aider à identifier les sites Web qui utilisent l'algorithm de hachage sécurisé 1 (SHA-1).
  • Problème résolu dans Microsoft Secure Channel (SChannel) qui provoque parfois l'échec des connections TLS (Transport Layer Security) 1.2 selon que le certificate racine est configuré comme faisant partie de la string de certificates pour l'authentification du server.

Après des essais et des erreurs, j'ai eu l'expérience contraire de Peter Hanley qui est documentée dans l'un des messages ci-dessus, bien que, comme Peter le fait remarquer, l'erreur est un peu différente. Je rencontre l'erreur EOF mentionnée par Scott qui est enracinée dans un code d'erreur TLS 20 (MAC_logging incorrect). Du côté MS, il est signalé comme une erreur SChannel.

Comme je me déployais sur plusieurs servers et que je voulais un RPM, j'ai édité le file freetds.spec pour supprimer le –with-gnutls et l'ai remplacé par –with-openssl = yes, puis j'ai reconstruit les RPM avec rpmbuild, en vérifiant que rpmbuild fait utilisé la directive que j'ai ajouté et ne contient pas –with-gnutls.

Pour tester, j'ai écrit un petit utilitaire Perl qui se connecte à la database / déconnecte en succession rapide.

J'ai vérifié plusieurs fois que lorsque –with-gnutls est utilisé, l'erreur TLS / SChannel / EOF est rencontrée entre 0,5% et 1% du time.

Lorsque seule la directive –with-openssl = yes est utilisée et sans –with-gnutls présent, je ne reçois aucune erreur. Ces tests ont été effectués à quelques minutes d'intervalle et ont impliqué 5000 tentatives de connection en succession rapide (environ 10 connections ouvertes et fermées par seconde). Aucune autre option de configuration de freetds n'a été modifiée. La seule différence entre les deux tests sont les directives énumérées ci-dessus. La construction et l'installation du RPM, les files de configuration freetds, etc. étaient tous automatisés et ne changeaient pas entre les tests.

Lorsque l'erreur se produit, elle est signalée du côté client comme suit:

DBI connect ('MYDBNAME', 'mydomain \ myusername', …) a échoué:
[unixODBC] [FreeTDS] [SQL Server] Impossible de se connecter à la source de données (SQL-08001) [l'état était 08001 maintenant 01000]
[UnixODBC] [FreeTDS] [SQL Server] La connection à Adaptive Server a échoué (SQL-01000)
[unixODBC] [FreeTDS] [SQL Server] EOF inattendu du server (SQL-01000) à ./dbconnectiontestlots.pl ligne 18

Ce test utilisait freetds-1.00.24-1.x86_64, téléchargé directement à partir de freetds.org, construit sur RHEL6 . Les RPM suivants ont été installés à partir du dossier / root / rpmbuild / RPMS / pour ce test après avoir exécuté rpmbuild à chaque fois:

386996 5 janvier 14:28 freetds-1.00.24-1.x86_64.rpm
187560 5 janv. 14:28 freetds-unixodbc-1.00.24-1.x86_64.rpm

UnixODBC x86_64 2.2.14-14.el6 a également été installé directement via yum.

Mise à jour: bien que cette solution fonctionne sur les systèmes RHEL6 32 bits et 64 bits, elle ne fonctionne pas sur les systèmes RHEL5 32 bits