Auteur Sujet: TLS 1.3 arrive...  (Lu 21921 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
TLS 1.3 arrive...
« Réponse #24 le: 30 août 2018 à 08:47:22 »
Annexe C : Conseils pour une mise en œuvre correcte de TLS 1.3

L'annexe C du RFC plaira aux programmeurs, elle donne plusieurs conseils pour une mise en œuvre correcte de TLS 1.3 (ce n'est pas tout d'avoir un protocole correct, il faut encore qu'il soit programmé correctement). Pour aider les développeurs à déterminer s'ils ont correctement fait le travail, un futur RFC fournira des vecteurs de test.

Un des conseils les plus importants est évidemment de faire attention au générateur de nombres aléatoires, source de tant de failles de sécurité en cryptographie. TLS utilise des nombres qui doivent être imprévisibles à un attaquant pour générer des clés de session. Si ces nombres sont prévisibles, toute la cryptographie s'effondre. Le RFC conseille fortement d'utiliser un générateur existant (comme /dev/urandom sur les systèmes Unix) plutôt que d'écrire le sien, ce qui est bien plus difficile qu'il ne semble. (Si on tient quand même à le faire, le RFC 4086 est une lecture indispensable.)

Le RFC conseille également de vérifier le certificat du partenaire par défaut (quitte à fournir un moyen de débrayer cette vérification). Si ce n'est pas le cas, beaucoup d'utilisateurs du programme ou de la bibliothèque oublieront de le faire. Il suggère aussi de ne pas accepter certains certificats trop faibles (clé RSA de seulement 1 024 bits, par exemple).

Il existe plusieurs moyens avec TLS de ne pas avoir d'authentification du serveur : les clés brutes du RFC 7250 (à la place des certificats), ou bien les certificats auto-signés. Dans ces conditions, une attaque de l'homme du milieu est parfaitement possibe, et il faut donc prendre des précautions supplèmentaires (par exemple DANE, normalisé dans le [ur=http://www.bortzmeyer.org/6698.htmll]RFC 6698[/url], que le RFC oublie malheureusement de citer).

Autre bon conseil de cryptographie, se méfier des attaques fondées sur la mesure du temps de calcul, et prendre des mesures appropriées (par exemple en vérifiant que le temps de calcul est le même pour des données correctes et incorrectes).

Il n'y a aucune bonne raison d'utiliser certains algorithmes faibles (comme RC4, abandonné depuis le RFC 7465), et le RFC demande que le code pour ces algorithmes ne soit pas présent, afin d'éviter une attaque par repli (annexes C.3 et D.5 du RFC). De la même façon, il demande de ne jamais accepter SSL v3 (RFC 7568).

L'expérience a prouvé que beaucoup de mises en œuvre de TLS ne réagissaient pas correctement à des options inattendues, et le RFC rappelle donc qu'il faut ignorer les suites cryptographiques inconnues (autrement, on ne pourrait jamais introduire une nouvelle suite, puisqu'elle casserait les programmes), et ignorer les extensions inconnues (pour la même raison).
[/size]


Annexe D : Problème de communication avec un partenaire qui ne connait pas TLS 1.3

L'annexe D, elle, est consacrée au problème de la communication avec un vieux partenaire, qui ne connait pas TLS 1.3. Le mécanisme de négociation de la version du protocole à utiliser a complètement changé en 1.3. Dans la 1.3, le champ version du ClientHello contient 1.2, la vraie version étant dans l'extension supported_versions. Si un client 1.3 parle avec un serveur <= 1.2, le serveur ne connaitra pas cette extension et répondra sans l'extension, avertissant ainsi le client qu'il faudra parler en 1.2 (ou plus vieux). Ça, c'est si le serveur est correct. S'il ne l'est pas ou, plus vraisemblablement, s'il est derrière une middlebox boguée, on verra des problèmes comme par exemple le refus de répondre aux clients utilisant des extensions inconnues (ce qui sera le cas pour supported_versions), soit en rejettant ouvertement la demande soit, encore pire, en l'ignorant. Arriver à gérer des serveurs/middleboxes incorrects est un problème complexe. Le client peut être tenté de re-essayer avec d'autres options (par exemple tenter du 1.2, sans l'extension supported_versions). Cette méthode n'est pas conseillée. Non seulement elle peut prendre du temps (attendre l'expiration du délai de garde, re-essayer…) mais surtout, elle ouvre la voie à des attaques par repli : l'attaquant bloque les ClientHello 1.3 et le client, croyant bien faire, se replie sur une version plus ancienne et sans doute moins sûre de TLS.

En parlant de compatibilité, le « 0-RTT » n'est évidemment pas compatible avec les vieilles versions. Le client qui envoie du « 0-RTT » (des données dans le ClientHello) doit donc savoir que, si la réponse est d'un serveur <= 1.2, la session ne pourra pas être établie, et il faudra donc réessayer sans 0-RTT.

Naturellement, les plus gros problèmes ne surviennent pas avec les clients et les serveurs mais avec les middleboxes. Plusieurs études ont montré leur caractère néfaste (cf. présentation à l'IETF 100, mesures avec Chrome (qui indique également que certains serveurs TLS sont gravement en tort, comme celui installé dans les imprimantes Canon), mesures avec Firefox, et encore d'autres mesures). Le RFC suggère qu'on limite les risques en essayant d'imiter le plus possible une salutation de TLS 1.2, par exemple en envoyant des messages change_cipher_spec, qui ne sont plus utilisés en TLS 1.3, mais qui peuvent rassurer la middlebox (annexe D.4).



Annexe E : propriétés de sécurité de TLS 1.3

Enfin, le RFC se termine par l'annexe E, qui énumère les propriétés de sécurité de TLS 1.3 : même face à un attaquant actif (RFC 3552), le protocole de salutation de TLS garantit des clés de session communes et secrètes, une authentification du serveur (et du client si on veut), et une sécurité persistante, même en cas de compromission ultérieure des clés (sauf en cas de 0-RTT, un autre des inconvénients sérieux de ce service, avec le risque de rejeu). De nombreuses analyses détaillées de la sécurité de TLS sont listées dans l'annexe E.1.6. À lire si vous voulez travailler ce sujet.

Quant au protocole des enregistrements, celui de TLS 1.3 garantit confidentialité et intégrité (RFC 5116).

TLS 1.3 a fait l'objet de nombreuses analyses de sécurité par des chercheurs, avant même sa normalisation, ce qui est une bonne chose (et qui explique en partie les retards). Notre annexe E pointe également les limites restantes de TLS :

- Il est vulnérable à l'analyse de trafic. TLS n'essaie pas de cacher la taille des paquets, ni l'intervalle de temps entre eux. Ainsi, si un client accède en HTTPS à un site Web servant quelques dizaines de pages aux tailles bien différentes, il est facile de savoir quelle page a été demandée, juste en observant les tailles. (Voir « I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis », de Miller, B., Huang, L., Joseph, A., et J. Tygar et « HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting », de Husak, M., Čermak, M., Jirsik, T., et P. Čeleda). TLS fournit un mécanisme de remplissage avec des données bidon, permettant aux applications de brouiller les pistes. Certaines applications utilisant TLS ont également leur propre remplissage (par exemple, pour le DNS, c'est le RFC 7858). De même, une mise en œuvre de TLS peut retarder les paquets pour rendre l'analyse des intervalles plus difficile. On voit que dans les deux cas, taille des paquets et intervalle entre eux, résoudre le problème fait perdre en performance (c'est pour cela que ce n'est pas intégré par défaut).

- TLS peut être également vulnérable à des attaques par canal auxiliaire. Par exemple, la durée des opérations cryptographiques peut être observée, ce qui peut donner des informations sur les clés. TLS fournit quand même quelques défenses : l'AEAD facilite la mise en œuvre de calculs en temps constant, et format uniforme pour toutes les erreurs, empêchant un attaquant de trouver quelle erreur a été déclenchée.

Le 0-RTT introduit un nouveau risque, celui de rejeu. (Et 0-RTT a sérieusement contribué aux délais qu'à connu le projet TLS 1.3, plusieurs participants à l'IETF protestant contre cette introduction risquée.) Si l'application est idempotente, ce n'est pas très grave. Si, par contre, les effets d'une requête précédentes peuvent être rejoués, c'est plus embêtant (imaginez un transfert d'argent répété…) TLS ne promet rien en ce domaine, c'est à chaque serveur de se défendre contre le rejeu (la section 8 donne des idées à ce sujet). Voilà pourquoi le RFC demande que les requêtes 0-RTT ne soient pas activées par défaut, mais uniquement quand l'application au-dessus de TLS le demande. (Cloudflare, par exemple, n'active pas le 0-RTT par défaut.)


Voilà, vous avez maintenant fait un tour complet du RFC, mais vous savez que la cryptographie est une chose difficile, et pas seulement dans les algorithmes cryptographiques (TLS n'en invente aucun, il réutilise des algorithmes existants comme AES ou ECDSA), mais aussi dans les protocoles cryptographiques, un art complexe. N'hésitez donc pas à lire le RFC en détail, et à vous méfier des résumés forcèment toujours sommaires, comme cet article.

vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
TLS 1.3 arrive...
« Réponse #25 le: 30 août 2018 à 08:47:38 »
Débats lors de la création de TLS 1.3, entre partisans et opposant à la surveillance du contenu des communications TLS 1.3
Au final, l'IETF est restée ferme et n'a pas accepté de compromissions sur la sécurité de TLS.

À part le 0-RTT, le plus gros débat lors de la création de TLS 1.3 avait été autour du concept que ses partisans nomment « visibilité » et ses adversaires « surveillance ». C'est l'idée qu'il serait bien pratique si on (on : le patron, la police, le FAI…) pouvait accéder au contenu des communications TLS. « Le chiffrement, c'est bien, à condition que je puisse lire les données quand même » est l'avis des partisans de la visibilité. Cela avait été proposé dans les Internet-Drafts draft-green-tls-static-dh-in-tls13 et draft-rhrd-tls-tls13-visibility. Je ne vais pas ici pouvoir capturer la totalité du débat, juste noter quelques points qui sont parfois oubliés dans la discussion.

Côté partisans de la visibilité :

- Dans une entreprise capitaliste, il n'y pas de citoyens, juste un patron et des employés. Les ordinateurs appartiennent au patron, et les employés n'ont pas leur mot à dire. Le patron peut donc décider d'accéder au contenu des communications chiffrées.

- Il existe des règles (par exemple PCI-DSS dans le secteur financier ou HIPAA dans celui de la santé) qui requièrent de certaines entreprises qu'elles sachent en détail tout ce qui circule sur le réseau. Le moyen le plus simple de le faire est de surveiller le contenu des communications, même chiffrées. (Je ne dis pas que ces règles sont intelligentes, juste qu'elles existent. Notons par exemple que les mêmes règles imposent d'utiliser du chiffrement fort, sans faille connue, ce qui est contradictoire.)

- Enregistrer le trafic depuis les terminaux est compliqué en pratique : applications qui n'ont pas de mécanisme de journalisation du trafic, systèmes d'exploitation fermés, boîtes noires…

- TLS 1.3 risque de ne pas être déployé dans les entreprises qui tiennent à surveiller le trafic, et pourrait même être interdit dans certains pays, où la surveillance passe avant les droits humains.


Et du côté des adversaires de la surveillance :

- La cryptographie, c'est compliqué et risqué. TLS 1.3 est déjà assez compliqué comme cela. Lui ajouter des fonctions (surtout des fonctions délibérèment conçues pour affaiblir ses propriétés de sécurité) risque fort d'ajouter des failles de sécurité. D'autant plus que TLS 1.3 a fait l'objet de nombreuses analyses de sécurité avant son déploiement, et qu'il faudrait tout recommencer.

- Contrairement à ce que semblent croire les partisans de la « visibilité », il n'y a pas que HTTPS qui utilise TLS. Ils ne décrivent jamais comment leur proposition marcherait avec des protocoles autres que HTTPS.

- Pour HTTPS, et pour certains autres protocoles, une solution simple, si on tient absolument à intercepter tout le trafic, est d'avoir un relais explicite, configuré dans les applications, et combiné avec un blocage dans le pare-feu des connexions TLS directes. Les partisans de la visibilté ne sont en général pas enthousiastes pour cette solution car ils voudraient faire de la surveillance furtive, sans qu'elle se voit dans les applications utilisées par les employés ou les citoyens.

- Les partisans de la « visibilité » disent en général que l'interception TLS serait uniquement à l'intérieur de l'entreprise, pas pour l'Internet public. Mais, dans ce cas, tous les terminaux sont propriété de l'entreprise et contrôlés par elle, donc elle peut les configurer pour copier tous les messages échangés. Et, si certains de ces terminaux sont des boîtes noires, non configurables et dont on ne sait pas bien ce qu'ils font, eh bien, dans ce cas, on se demande pourquoi des gens qui insistent sur leurs obligations de surveillance mettent sur leur réseau des machines aussi incontrôlables.

- Dans ce dernier cas (surveillance uniquement au sein d'une entreprise), le problème est interne à l'entreprise, et ce n'est donc pas à l'IETF, organisme qui fait des normes pour l'Internet, de le résoudre. Après tout, rien n'empêche ces entreprises de garder TLS 1.2.



Mises en œuvre de TLS 1.3 avec GnuTLS

Revenons maintenant aux choses sérieuses, avec les mises en œuvre de TLS 1.3. Il y en existe au moins une dizaine à l'heure actuelle mais, en général, pas dans les versions officiellement publiées des logiciels. Notons quand même que Firefox 61 sait faire du TLS 1.3. Les autres mises en œuvre sont prêtes, même si pas forcèment publiées. Prenons l'exemple de la bibliothèque GnuTLS. Elle dispose de TLS 1.3 depuis la version 3.6.3. Pour l'instant, il faut compiler cette version avec l'option ./configure --enable-tls13-support, qui n'est pas encore activée par défaut. Un bon article du mainteneur de GnuTLS explique bien les nouveautés de TLS 1.3.

Une fois GnuTLS correctement compilé, on peut utiliser le programme en ligne de commande gnutls-cli avec un serveur qui accepte TLS 1.3 :


% gnutls-cli  gmail.com
...
- Description: (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: X25519
 - Curve size: 256 bits
- Version: TLS1.3
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM
- MAC: AEAD
...

Et ça marche, on fait du TLS 1.3. Si vous préférez écrire le programme vous-même, regardez ce petit programme. Si GnuTLS est en /local, il se compilera avec cc -I/local/include -Wall -Wextra -o test-tls13 test-tls13.c -L/local/lib -lgnutls et s'utilisera avec :
% ./test-tls13 www.ietf.org     
TLS connection using "TLS1.3 AES-256-GCM"

%  ./test-tls13 gmail.com 
TLS connection using "TLS1.3 AES-256-GCM"

%  ./test-tls13 mastodon.gougere.fr
TLS connection using "TLS1.2 AES-256-GCM"

% ./test-tls13 www.bortzmeyer.org
TLS connection using "TLS1.2 AES-256-GCM"

% ./test-tls13 blog.cloudflare.com
TLS connection using "TLS1.3 AES-256-GCM"

Cela vous donne une petite idée des serveurs qui acceptent TLS 1.3.

Un pcap d'une session TLS 1.3 est disponible en tls13.pcap. Notez que le numéro de version n'est pas encore celui du RFC (0x304). Ici, 0x7f1c désigne l'Internet-Draft numéro 28. Voici la session vue par tshark :

    1   0.000000 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 94 36866 → https(443) [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=3528788861 TSecr=0 WS=128
    2   0.003052 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 86 https(443) → 36866 [SYN, ACK] Seq=0 Ack=1 Win=24400 Len=0 MSS=1220 SACK_PERM=1 WS=1024
    3   0.003070 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=1 Ack=1 Win=28800 Len=0
    4   0.003354 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1 403 Client Hello
    5   0.006777 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=1 Ack=330 Win=25600 Len=0
    6   0.011393 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 6496 Server Hello, Change Cipher Spec, Application Data
    7   0.011413 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=330 Ack=6423 Win=41728 Len=0
    8   0.011650 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 80 Change Cipher Spec
    9   0.012685 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 148 Application Data
   10   0.015693 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=6423 Ack=411 Win=25600 Len=0
   11   0.015742 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 524 Application Data
   12   0.015770 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0
   13   0.015788 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [FIN, ACK] Seq=6873 Ack=411 Win=25600 Len=0
   14   0.015793 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0

Et, complètement décodée par tshark :
Secure Sockets Layer [sic]
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Version: TLS 1.2 (0x0303)
...
            Extension: supported_versions (len=9)
                Type: supported_versions (43)
                Length: 9
                Supported Versions length: 8
                Supported Version: Unknown (0x7f1c)
                Supported Version: TLS 1.2 (0x0303)
                Supported Version: TLS 1.1 (0x0302)
                Supported Version: TLS 1.0 (0x0301)
Le texte complet est en tls13.txt. Notez bien que la négociation est en clair.


Quelques autres articles à lire :

- L'annonce officielle de l'IETF,
- Le bon résumé de Cloudflare sur la version 1.3,
- Discussion Ycombinator sur la visibilité,
- Liste complète des réponses aux partisans de la visibilité,
- Bon article historique très détaillé sur l'histoire de TLS, jusqu'à la version 1.3,
- Un exemple d'un des ateliers où a été étudié la sécurité de TLS 1.3, à Paris en 2017, et un autre à San Diego en 2016,
- Bon article sur la question des middleboxes, expliquant notamment les extensions « inutiles », mais permettant de tromper ces middleboxes pour ressembler à TLS 1.2.



Source : Blog de Stéphane Bortzmeyer

vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
TLS 1.3 arrive...
« Réponse #26 le: 17 septembre 2018 à 13:28:40 »
OpenSSL 1.1.1 est sorti le 11 septembre 2018 et apporte le support de TLS 1.3.
OpenSSL sera disponible avec Ubuntu 19.04 qui sortira en avril 2019.

Fedora 29, prévue pour début novembre, prendra en charge TLS 1.3 via GnuTLS, une libraire alternative à OpenSSL qui a mis en place le support de TLS 1.3 avec quelques mois d'avance sur OpenSSL.

Chrome 70 apportera le support de TLS 1.3 (RFC 8446) activé par défaut.

Pour Firefox, c'est activé par défaut depuis Firefox 61 :

Firefox 61 est la première version de Firefox vec le support de TLS1.3 activé par défaut

=> https://www.mozilla.org/en-US/firefox/61.0/releasenotes/



alegui

  • Abonné Bbox fibre
  • *
  • Messages: 464
  • FTTH Courbevoie (92)
TLS 1.3 arrive...
« Réponse #27 le: 18 décembre 2018 à 14:56:55 »
TLS v1.3 sera vraisemblablement proposé à la rentrée 2020 (1er octobre 2020 ?) en plus de TLS v1.2. Cela pourrait être avancé, si TLS v1.3 venait a être inclut dans Ubuntu 18.04 LTS, comme une mise à jour de sécurité. La configuration d'Apache permettant l'activation de TLS v1.3 dés qu'il est disponible, cela se ferait alors automatiquement, lors de le mise à jour d'OpenSSL.
Apparemment, OpenSSL 1.1.1 va être rétroporté et Apache et OpenSSH mis à jour pour un support de TLSv1.3 dans les semaines suivantes.

zoc

  • Abonné Orange Fibre
  • *
  • Messages: 4 258
  • Antibes (06) / Mercury (73)
TLS 1.3 arrive...
« Réponse #28 le: 18 décembre 2018 à 15:16:32 »
Et nginx ?  ::)

vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
TLS 1.3 arrive...
« Réponse #29 le: 18 décembre 2018 à 15:57:15 »
C'est une bonne nouvelle.

Je suis curieux de voir comment ces mises à jour sont proposés, car il me semble impossible de les pousser à tous comme une mise à jour de sécurité, il y a des choses qui ne peuvent plus marcher avec des versions plus récentes.

Par exemple la connexion a des vieux réseaux WiFi WPA2 Enterprise Protected EAP pose problème avec Open SSL 1.1.0 :


We suspected OpenSSL incompatibility in the OS, so as the PEAP is creating underlying TLS tunnel for auth and we see an error in wpa_supplicant regarding TLS negotiation (hello).
[...]
We think the issue directly relates to remove 3DES from Bionic:
openssl ciphers -V '3DES'
Error in cipher list
139999040823744:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:../ssl/ssl_lib.c:2129:

Source : Launchpad bug #1748839

J'imagine que la moise à jour pourrait être poussée avec les LTS Enablement Stacks qui permettent d'avoir un kernel et un serveur X plus récent sur une LTS.
( cf LTS Enablement Stacks )

alegui

  • Abonné Bbox fibre
  • *
  • Messages: 464
  • FTTH Courbevoie (92)
TLS 1.3 arrive...
« Réponse #30 le: 18 décembre 2018 à 16:46:17 »
Et nginx ?  ::)
A priori pas besoin de mise à jour supplèmentaire dans ce cas-là.

J'imagine que la moise à jour pourrait être poussée avec les LTS Enablement Stacks qui permettent d'avoir un kernel et un serveur X plus récent sur une LTS.
( cf LTS Enablement Stacks )
Probablement pas, dans le message initial il est rappelé qu'au contraire de la version 1.1.1, la 1.1.0  n'est pas une version LTS au niveau de l'équipe OpenSSL, et que les API / ABI ne changent pas. Par ailleurs aucun problème significatif n'a été relevé pour l'instant ni sur le PPA de test ni sur Ubuntu 18.10 (ce qui ne veut pas dire pas de bug du tout, cf le lien du dessus pour ngix)

vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
TLS 1.3 arrive...
« Réponse #31 le: 19 décembre 2018 à 21:11:32 »
Effectivement, OpenSSL 1.1.1 sera proposé en remplacement d'OpenSSL 1.1.0 dans quelques mois.

Cf https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386

Attention, La version d'Apache livré avec Ubuntu 18.04 ou Ubuntu 18.10 n'est pas compatible TLS 1.3

Il y aura donc ultérieurement une mise à jour d'Apache, porbablement dans la version qui sera livrée avec Ubuntu 19.04... (ce sont des suppositions de ma part)

Sendell

  • Abonné SFR fibre FttH
  • *
  • Messages: 15
  • Lyon
    • Site perso
TLS 1.3 arrive...
« Réponse #32 le: 20 décembre 2018 à 14:35:52 »
J'ai récemment changé mon serveur dédié et en ai profité pour y installer Debian 10 Buster (actuelle testing) ; j'ai openssl1.1.1, apache2.4.37, et du coup TLS1.3 actif. J'ai fêté ça en retirant TLSv1 et TLSv1.1
SSL Pulse de Qualys permet de suivre l'utilisation de ces protocoles côté serveurs.
« Modifié: 20 décembre 2018 à 15:10:07 par Sendell »

Ilyazam

  • Abonné MilkyWan
  • *
  • Messages: 118
  • proche Rennes (35)
TLS 1.3 arrive...
« Réponse #33 le: 23 décembre 2018 à 19:34:45 »
Du côté de F5 (célèbre fabricant de load-balancers) le support de TLS1.3 n'est pas encore complet :
https://support.f5.com/csp/article/K10251520

F5 ne conseille pas de l'utiliser en production pour le moment.


vivien

  • Administrateur
  • *
  • Messages: 47 080
    • Twitter LaFibre.info
TLS 1.3 arrive...
« Réponse #34 le: 25 février 2019 à 21:59:35 »
Mettre à jour OpenSSL sans toucher au reste ne semble pas aussi simple.

Le mail envoyé ce soir par Dimitri John Ledkov qui travail pour mettre OpenSSL 1.1.1 sur Ubuntu 18.04 LTS :

There are many moving parts involved to safely land the OpenSSL 1.1.1
update in Bionic.

SRU bug report https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386

Landing OpenSSL and related updates (pythons, ruby, r-cran, etc) will
trigger many autopkgtests and may regress package buildability. Thus
before landing the update, I would like to land stand-alone SRUs that
fix and resolve FTBFS and autopkgtests regressions that will become
apparent once new OpenSSL is in proposed.

These are:
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=uvloop
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=libevent-rpc-perl
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=python-httplib2
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=python-imaplib2
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=ruby2.5

The changes and fixes in above are openssl-version agnostic. Ideally
I'd want the above at least in -proposed, if not -updates, before
accepting openssl 1.1.1 update.
Then there is a bunch of syncs:

openssl (bionic-proposed/main) [1.1.0g-2ubuntu4.3 => 1.1.1-1ubuntu2.1~18.04.0]

python2.7 (bionic-proposed/main) [2.7.15~rc1-1ubuntu0.1 =>
2.7.15-4ubuntu4~18.04] (core) (sync)
python3.6 (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04.1]
(core) (sync)
python3.7 (bionic-proposed/universe) [3.7.1-1~18.04 =>
3.7.2-1~18.04.1] (no packageset) (sync)
python-cryptography (bionic-proposed/main) [2.1.4-1ubuntu1.2 =>
2.1.4-1ubuntu1.3] (core) (sync)

ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.3]
(kubuntu, ubuntu-desktop, ubuntu-server) (sync)
ruby-openssl (bionic-proposed/universe) [2.0.5-1build3 =>
2.0.9-0ubuntu1] (no packageset) (sync)

libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 =>
2.060-3~ubuntu18.04.0] (core) (sync)
libnet-ssleay-perl (bionic-proposed/main) [1.84-1build1 =>
1.84-1ubuntu0.1] (core) (sync)

r-cran-openssl (bionic-proposed/universe) [1.0.1-1ubuntu1 =>
1.0.1-1ubuntu1.1] (no packageset) (sync)

nova (bionic-proposed/main) [2:17.0.7-0ubuntu2 => 2:17.0.7-0ubuntu2.1]
(openstack, ubuntu-server) (sync)

These were built in security pocket, in a bileto ppa, thus are
suitable for publishing in either (or both) -security or -updates
pockets.
These are built in correct order, thus e.g. python-cryptography was
built agains pythons that are built against openssl 1.1.1, and thus
all binaries are collectively installable on publication.
As you can notice 3.6 and 3.7 are point release bumps, that not only
introduce openssl 1.1.1 compatibility (fixes in test suite asumptions
re:tlsv1.3) but also add functionality to exploit/limit usage of
tlsv1.3.
Note that python3.7 is neither default nor supported python version,
it's standalone/inert in bionic by default - technology preview used
by some upstream CIs to gain access to python3.7 interpreter without
any other system dependencies.
Similarly with the rest of the syncs, they introduce
testsuites/adt-tests/ftbfs fixes and compatibility for openssl 1.1.1.
We (doko) do want to SRU the python3.6/3.7 point releases regardless
of openssl SRU, but doing this in one go, saves on validation
resources / adt testing, as python triggers a long tail of tests. Also
it may be cumbersome to split hairs of the python3.6/3.7 point release
update into openssl and non-openssl update portions.

The diffs for these uploads are quite large, and I am not sure what's
the best way to present these SRUs to the SRU team for review. In
addition to above syncs I could upload source only uploads into the
queue, however, the binaries here need to be built in security pocket
only (such that we have ability to push these update into security
pocket, if and when needed). Please let me know if you want any
changes from me to conquer reviewing all of the above SRUs.

--
Regards,

Dimitri.

zoc

  • Abonné Orange Fibre
  • *
  • Messages: 4 258
  • Antibes (06) / Mercury (73)
TLS 1.3 arrive...
« Réponse #35 le: 26 février 2019 à 08:52:37 »
Effectivement...

De mon coté, vu que tous mes serveurs Ubuntu sont en fait des VM Proxmox, je ferai des snapshots avant de me lancer dans les mises à jour... S’il y a un avantage à utiliser des VM c’est bien celui-là...