tag:linuxfr.org,2005:/tags/tls/publicLinuxFr.org : les contenus étiquetés avec « tls »2023-10-24T15:04:28+02:00/favicon.pngtag:linuxfr.org,2005:Bookmark/73932023-10-24T15:04:06+02:002023-10-24T15:04:06+02:00Firefox 119 est sorti, avec vraiment beaucoup de nouveautés (dont Encrypted Client Hello – ECH) !<a href="https://clickthis.blog/fr/firefox-119-revamped-firefox-view-encrypted-hello-and-more/">https://clickthis.blog/fr/firefox-119-revamped-firefox-view-encrypted-hello-and-more/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/133723/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/firefox-119-est-sorti-avec-vraiment-beaucoup-de-nouveautes-dont-encrypted-client-hello-ech#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/133723/comments.atomtag:linuxfr.org,2005:Diary/409032023-10-07T22:34:43+02:002023-10-07T22:34:43+02:00Predator files : surveillez les logs Certificate transparency sur vos domainesLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Le 5 octobre, le réseau de médias <a href="https://eic.network/">European Investigative Collaborations</a> a publié les <a href="https://securitylab.amnesty.org/latest/2023/10/global-predator-files-investigation-reveals-catastrophic-failure-to-regulate-surveillance-trade/">Predator Files</a> (en), documentant la commercialisation d'outil de piratage et de cybersurveillance à destination d'états ou d'autorités pas toujours démocratiques, par l'Alliance Intellexa, animée notamment par l'entreprise française Nexa, le nouveau nom d'Amesys, <a href="https://reflets.info/dossiers/amesys-10-ans-3-mois-et-4-mises-en-examen">mise en examen pour complicité de torture suite à la vente de logiciels espions au gouvernement de Mouammar Kadhafi</a> il y a plus de 10 ans maintenant.</p>
<p>Dans <a href="https://securitylab.amnesty.org/latest/2023/10/technical-deep-dive-into-intellexa-alliance-surveillance-products/">le premier document d'analyse</a> (en), le security lab d'Amnesty International présente plusieurs produits vendus par l'alliance Intellexa : des spywares pour téléphones mobiles, des outils d'interception et infection WiFi, GSM ou réseau et des produits d'analyse et de corrélation du trafic à l'échelle d'un pays pour identifier les membres de groupes utilisant des messageries pourtant chiffrées de bout-en-bout (WhatsApp, Signal…).</p>
<p>J'attire votre attention sur le programme Jupiter, qui propose de modifier le trafic chiffré entre une cible (téléphone mobile) et un site internet domestique (du pays dont l'autorité a acquis Jupiter) pour y injecter une attaque permettant de déployer le logiciel espion sur la cible.</p>
<p>La technique est la suivante :<br>
- l'État place un boîtier Jupiter sur le réseau proche du site internet qui servira à l'infection, idéalement juste devant sa passerelle vers internet.<br>
- Le boîtier demande et obtient un certificat TLS, par exemple via <a href="https://letsencrypt.org/">let's encrypt</a>, en utilisant le challenge HTTP et en interceptant le trafic entre le serveur de vérification et le site (MitM entre le site et l'autorité de certification).<br>
- Grâce à ce certificat, il peut se faire passer pour le site en question et déchiffrer le trafic entre les utilisateurs et ce site, et ainsi glisser sa charge malveillante.</p>
<p>En tant qu'utilisateur ciblé, il n'est pas possible de se défendre contre cette attaque. Mais en tant que "site internet", il y a 2 mesures à prendre :</p>
<ul>
<li>
<strong>Empêcher l'attaque</strong> : si vous utilisez une autorité de certification qui ne propose pas de délivrer un certificat sur simple requête HTTP, vous pouvez ajouter une information <a href="https://fr.wikipedia.org/wiki/DNS_Certification_Authority_Authorization">Certification Authority Authorization</a> dans votre zone DNS de façon à interdire à tout autre autorité de certification de délivrer un certificat valide pour votre domaine.</li>
<li>
<strong>Détecter l'attaque</strong> : tous les certificats émis étant journalisés dans <a href="https://certificate.transparency.dev/">les logs Certificate Transparency</a>, vous pouvez comparer la liste des certificats émis pour vos domaines avec la liste des certificats que vous avez demandé. S'il y en a en plus, il y a un problème, et s'il est confirmé que ce certificat n'est pas légitime, vous devez demander sa révocation et expatrier votre serveur. À titre personnel, j'utilise <a href="https://sslmate.com/certspotter/">certspotter</a> de sslmate pour suivre les journaux Certificate Transparency. Il existe aussi <a href="https://crt.sh/">crt.sh</a> par Sectigo, et probablement d'autres.</li>
</ul>
<div><a href="https://linuxfr.org/users/samuel/journaux/predator-files-surveillez-les-logs-certificate-transparency-sur-vos-domaines.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/133568/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/samuel/journaux/predator-files-surveillez-les-logs-certificate-transparency-sur-vos-domaines#comments">ouvrir dans le navigateur</a>
</p>
Samuelhttps://linuxfr.org/nodes/133568/comments.atomtag:linuxfr.org,2005:Bookmark/72952023-10-06T16:09:13+02:002023-10-06T16:09:13+02:00Mozilla déploie Encrypted Client Hello pour chiffrer les adresses des sites visités<a href="https://www.nextinpact.com/article/72598/mozilla-deploie-encrypted-client-hello-pour-chiffrer-adresses-sites-visites">https://www.nextinpact.com/article/72598/mozilla-deploie-encrypted-client-hello-pour-chiffrer-adresses-sites-visites</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/133557/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/colargol/liens/mozilla-deploie-encrypted-client-hello-pour-chiffrer-les-adresses-des-sites-visites#comments">ouvrir dans le navigateur</a>
</p>
Colargolhttps://linuxfr.org/nodes/133557/comments.atomtag:linuxfr.org,2005:Diary/407112023-05-21T03:05:39+02:002023-05-21T03:05:39+02:00Comment, via un résolveur DNS alternatif, se protéger : 1) de la censure et 2) du pistage ?Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Bonsoir nal,</p>
<p>Dans la famille <code>gens-réputés-de-confiance-et-s-y-connaître</code>, <a href="https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html">après Stéphane Bortzmeyer</a>, vous avez vu passer ici l'info que c'est <a href="//linuxfr.org/users/glandos/journaux/fdn-propose-du-dns-plus-securise-avec-doh-et-dot">au tour de FDN de proposer gracieusement le DoH ou DNS over HTTPS</a>.</p>
<p>Vous savez aussi que Firefox permet facilement d’activer le DNS via HTTPS et de choisir le résolveur DoH de son choix.</p>
<p>Vous vous souvenez peut-être que Firefox a expérimenté la chose main dans la main avec <a href="https://fr.wikipedia.org/wiki/Cloudflare" title="Définition Wikipédia">Cloudflare</a>, visiblement en pointe sur ces sujets. Mais que bien que les intentions de Cloudflare semblent correctes a priori, cela n'en reste pas moins une entité 1°) commerciale 2°) américaine : deux raisons qui peuvent faire hésiter à leur confier notre navigation web.</p>
<p>Cependant il peut être intéressant, d'un point de vue technique, de suivre les solutions technologiques proposées par Cloudflare, et ce d'autant qu'ils font des efforts pour vulgariser tout ça. Ainsi ils présentent <a href="https://www.cloudflare.com/ssl/encrypted-sni/">une page de test</a> de 4 fonctionnalités :</p>
<ul>
<li>Secure DNS</li>
<li>DNSSEC</li>
<li>TLS 1.3</li>
<li>Encrypted Client Hello ou ECH (anciennement Secure SNI) [1]</li>
</ul>
<p>Pour autant, si j'ai bien compris, toutes les fonctionnalités ne sont pas liées à DoH.<br>
Ainsi avec le résolveur DoH de Stéphane Bortzmeyer, ladite page de test m'en valide 2 : DNSSEC et TLS 1.3 (J'obtiens un point d'interrogation pour Secure DNS et un échec pour ECH/Secure SNI). Ensemble ces deux confirment l'activation de DoH si j'ai bien compris. Si je prends celui de Cloudflare, les 4 sont validées. Mais je ne saisis pas ce qu'apportent Secure DNS et ECH.</p>
<p><strong>Quelqu'un pourrait-il expliciter les différents mécanismes ?</strong><br>
Je crois pour cela qu'il serait intéressant de distinguer 2 types de tiers – aux pouvoirs différents – dont on voudrait se cacher : notre FAI ; tout autre tiers ?</p>
<p>1) Ainsi, si j'ai bien compris, avec le navigateur et un site configurés pour HTTPS, il est possible de savoir que vous avez consulté tel site mais pas telle page de tel site. Ni ce que vous avez écrit sur tel site. <a href="https://www.eff.org/https-everywhere/faq/#what-does-https-everywhere-protect-me-against">https://www.eff.org/https-everywhere/faq/#what-does-https-everywhere-protect-me-against</a><br>
Est-ce que cela s'applique également à notre FAI, ou celui-ci peut connaître précisément la page visitée malgré la configuration HTTPS ?</p>
<p>2) a/ Avec DoH, il n'est plus possible, sauf pour le résolveur choisi, de savoir quel site est visité ? À l'exception cependant de notre FAI peut-être ?<br>
J'ai ainsi vu que Bouygues Telecom censurerait l'accès aux sites de ses abonnés malgré le paramétrage d'un résolveur DNS alternatif… <a href="https://nitter.fdn.fr/JohnShaftFr/status/807600947639762944">https://nitter.fdn.fr/JohnShaftFr/status/807600947639762944</a><br>
Auquel cas, pour masquer sa navigation à son FAI, il faut utiliser les traditionnels « tunnels » (VPN, réseau Tor) ?</p>
<p>b/ J'ai fait le test d'accéder à un site censuré auprès des 4 grands FAI nationaux (uptobox.com) avec un résolveur DoH alternatif. Firefox me répond que « Hum, nous ne parvenons pas à trouver ce site »… Qu'en conclure ? Je précise que mon FAI est Bouygues Telecom.</p>
<p>3) ECH ?</p>
<p>Merci d'avance de m'aider à y voir plus clair…</p>
<hr>
<p>[1] Pour activer cette fonctionnalité en développement (spécification en cours de finalisation auprès de l'IETF) dans Firefox, aller dans about:config et passer <code>network.dns.echconfig.enabled</code> et – si ce n'est pas fait par défaut – <code>network.dns.use_https_rr_as_altsvc</code> à <code>true</code>. Explications <a href="https://lafibre.info/cryptographie/encrypted-sni/msg834683/#msg834683">ici</a>, méta-bogue pour Firefox <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1725938">là</a>. Tester <a href="https://defo.ie/ech-check.php">ici</a> ou <a href="https://crypto.cloudflare.com/cdn-cgi/trace/">là</a>.</p>
<div><a href="https://linuxfr.org/users/antistress/journaux/comment-via-un-resolveur-dns-alternatif-se-proteger-1-de-la-censure-et-2-du-pistage.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/131300/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/journaux/comment-via-un-resolveur-dns-alternatif-se-proteger-1-de-la-censure-et-2-du-pistage#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/131300/comments.atomtag:linuxfr.org,2005:News/414862023-04-28T14:28:20+02:002023-04-28T14:28:20+02:00OpenSSL Cookbook est maintenant en libre diffusion (CC By NC)Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>OpenSSL est un des logiciels libres les plus réussis et les plus importants (oui, oui, pas la peine d’avoir des boutons !). Réussi de par sa large utilisation ; important parce que l’infrastructure d’internet en dépend.</p>
<p>Le projet OpenSSL contient une implémentation haute performance d’algorithmes cryptographiques clés, une pile TLS et PKI complète et une boîte à outils en ligne de commande.</p>
<p>Mais il a toujours manqué d’une documentation exhaustive. Et pourtant elle existe : Ivan Ristić a écrit une somme sur le sujet, dont ce petit livre pratique est extrait.<br>
<img src="//img.linuxfr.org/img/68747470733a2f2f7777772e6665697374796475636b2e636f6d2f6c6962726172792f6f70656e73736c2d636f6f6b626f6f6b2f6173736574732f696d6167652d6d61696e2d766965772e706e67/image-main-view.png" alt="Couverture d’OpenSSL Cookbook" title="Source : https://www.feistyduck.com/library/openssl-cookbook/assets/image-main-view.png"></p>
</div><ul><li>lien nᵒ 1 : <a title="https://www.feistyduck.com/library/openssl-cookbook/" hreflang="en" href="https://linuxfr.org/redirect/112064">OpenSSL Cookbook. à lire en ligne ou à télécharger </a></li><li>lien nᵒ 2 : <a title="https://www.feistyduck.com/bulletproof-tls-newsletter/issue_100_openssl_cookbook_released_under_cc_by_nc" hreflang="en" href="https://linuxfr.org/redirect/112065">Bullet Proof TLS newsletter </a></li><li>lien nᵒ 3 : <a title="https://www.feistyduck.com/books/bulletproof-tls-and-pki/" hreflang="en" href="https://linuxfr.org/redirect/112066">"Le" livre de référence Bulletproof SSL and PKI</a></li></ul><div><p>Dès que vous vous préoccupez de sécurité, développement Web ou d’administration système, vous êtes confronté à OpenSSL, même à un petit niveau. C’est pourquoi ce livre s’occupe d’aspects pratiques. Il couvre deux manières d’utiliser OpenSSL, en deux chapitres.</p>
<h2 id="toc-ligne-de-commande-openssl">Ligne de commande OpenSSL</h2>
<p>Pour vous aider dans vos scripts de génération de clés et de certificats ou dans la configuration des programmes qui dépendent d’OpenSSL pour la fonctionnalité TLS. Ce chapitre explique aussi comment créer une autorité de certification privée complète. Ça vous sera utile comme développeur, comme enseignant, en auto apprentissage ou pour un réseau local.</p>
<h2 id="toc-tester-tls-avec-openssl">Tester TLS avec OpenSSL</h2>
<p>Deuxième usage, les tests de sécurité du serveur. Bien que parfois chronophage, ce type de test de bas niveau ne peut être évité lorsque vous souhaitez savoir exactement ce qui se passe.</p>
<hr>
<p>Les deux chapitres sont extraits de <em>Bulletproof TLS et PKI</em>, fameux et copieux livre de référence sur le sujet. </p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e6665697374796475636b2e636f6d2f696d61676573322f62756c6c657470726f6f662d746c732d616e642d706b692d3265642e706e67/bulletproof-tls-and-pki-2ed.png" alt="couverture de Bulletproof SSL and PKI" title="Source : https://www.feistyduck.com/images2/bulletproof-tls-and-pki-2ed.png"></p>
<p>Les chapitres OpenSSL sont publiés en livre séparé pour combler le vide : il manque une documentation de qualité et facilement disponible. Comme c’est souvent le cas pour les projets complexes et de longue durée, la documentation OpenSSL que vous pouvez trouver sur Internet est souvent erronée, obsolète et dispersée.</p>
<p>D’ailleurs pour vous tenir au courant sur ce sujet d’importance, Ivan Ristić publie régulièrement <a href="https://www.feistyduck.com/bulletproof-tls-newsletter/issue_100_openssl_cookbook_released_under_cc_by_nc">une lettre d’actualités passionnante et bien documentée</a>. Et c’est pour célébrer la centième lettre qu’il a décidé de passer à une licence plus permissive (le livre était déjà gratuit).</p>
<p>La nouvelle license d’OpenSSL Cookbook (<a href="https://creativecommons.org/licenses/by-nc/3.0/fr/">Creative Commons Attribution-NonCommercial</a>) fête, comme un cadeau, les 10 ans de la première édition. C’est aussi un encouragement pour tous ceux qui voudraient s’en inspirer pour écrire de la documentation et… à tous les traducteurs !</p>
<p>Il y a 10 ans donc, l’auteur s’était engagé à garder ce livre à jour et à l’amender de vos remarques. Vous êtes donc invités, lecteurs, à lui faire autant de retours que possible sur les défauts rencontrés.</p>
<p>(cet article est très librement adapté de la préface).</p>
</div><div><a href="https://linuxfr.org/news/openssl-cookbook-est-maintenant-en-libre-diffusion-cc-by-nc.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/131078/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/openssl-cookbook-est-maintenant-en-libre-diffusion-cc-by-nc#comments">ouvrir dans le navigateur</a>
</p>
orfenorBenoît SibaudgUINÿcoXavier Teyssierhttps://linuxfr.org/nodes/131078/comments.atomtag:linuxfr.org,2005:Diary/404112022-10-08T12:10:42+02:002022-10-08T12:10:42+02:00Brother ne mettra pas à jour les micrologiciels des imprimantes qui utilisent TLS 1.0Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Les imprimantes Brother qui ont environ 10 ans utilisent TLS 1.0 pour chiffrer les échanges en HTTPS. TLS 1.0 est maintenant bloqué par les navigateurs web car pas assez sécurisé.<br>
Donc on ne peut plus administrer à distance ces imprimantes Brother.<br>
La réponse du support Brother : les microcodes ne seront pas mis à jour, vive l’obsolescence programmée.<br>
<a href="https://imgur.com/a/QSE3rsA">https://imgur.com/a/QSE3rsA</a></p>
<div><a href="https://linuxfr.org/users/tout/journaux/brother-ne-mettra-pas-a-jour-les-micrologiciels-des-imprimantes-qui-utilisent-tls-1-0.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/128970/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/tout/journaux/brother-ne-mettra-pas-a-jour-les-micrologiciels-des-imprimantes-qui-utilisent-tls-1-0#comments">ouvrir dans le navigateur</a>
</p>
touthttps://linuxfr.org/nodes/128970/comments.atomtag:linuxfr.org,2005:Post/430062022-07-07T01:17:02+02:002022-07-07T01:17:02+02:00TLSv1 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)<p>Bonsoir a tous,</p>
<p>Je m-apelle Catalin, et je besoin d'aide. Ca c'ete tout ma Francais, car je puex expliquer mieux en Anglais. :)</p>
<p>Recently, I had to switch from http to https. I have modified the IP tables of Linux server to block http and allow https.<br>
As we are running on geo-redundancy we have 2 similar servers with the same function.<br>
After this change, I'm able to access by https only one server out of 2. </p>
<p>Taking a dump, I can observe that after Client Hello, I get, Alert: Handshake Failure.<br>
For successfull one TLS V1.2 is used<br>
For unsuccessful one TLS V1.0 is used<br>
(how can I make sure that same TLS V1.2 is used for unsuccessful example)</p>
<p>I'm using the same browser IE for both servers.</p>
<p>Extrachecks:<br>
On firewall, both destinations are part of the same zone.<br>
I have compared ssl.conf file between the two servers and there is no difference.</p>
<p>Merci beaucoup,<br>
Catalin</p>
<div><a href="https://linuxfr.org/forums/linux-general/posts/tlsv1-record-layer-alert-level-fatal-description-handshake-failure.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/128227/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-general/posts/tlsv1-record-layer-alert-level-fatal-description-handshake-failure#comments">ouvrir dans le navigateur</a>
</p>
Catalinhttps://linuxfr.org/nodes/128227/comments.atomtag:linuxfr.org,2005:Bookmark/46302022-05-02T15:05:47+02:002022-05-02T15:05:47+02:00Considered “18+”<a href="https://daniel.haxx.se/blog/2022/05/02/considered-18/">https://daniel.haxx.se/blog/2022/05/02/considered-18/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/127628/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/oulala/liens/considered-18#comments">ouvrir dans le navigateur</a>
</p>
Tonton Thhttps://linuxfr.org/nodes/127628/comments.atomtag:linuxfr.org,2005:Bookmark/36742021-10-05T12:45:03+02:002021-10-05T12:45:03+02:00Crack all the common current encryption<a href="https://daniel.haxx.se/blog/2021/10/04/post-quantum-curl/">https://daniel.haxx.se/blog/2021/10/04/post-quantum-curl/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/125623/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/oulala/liens/crack-all-the-common-current-encryption#comments">ouvrir dans le navigateur</a>
</p>
Tonton Thhttps://linuxfr.org/nodes/125623/comments.atomtag:linuxfr.org,2005:Post/423512021-09-04T12:19:20+02:002021-09-04T12:19:20+02:00Orange ne prend pas (complètement) en charge le TLS - Comment les contacter quand on 'est pas client<p>Bonjour,</p>
<p>Depuis quelques temps mes contacts m'écrivant depuis une adresse de courriel en @orange.fr ne peuvent plus me joindre ; les messages n'arrivent pas dans ma boîte de réception @posteo.de.<br>
Je n'ai aucun souci avec les courriels provenant d'autres « hébergeurs » de courriels.</p>
<p>Après quelques recherches je me suis rappelé avoir activé la « garantie de réception par TLS » dans ma boîte Posteo : celle-ci permet de refuser « la réception d’un e-mail lorsqu’un serveur essaie de le distribuer sans chiffrement à jour lors de l’acheminement » d'après <a href="https://posteo.de/fr/aide/activer-garantie-reception-tls#alternative">la page d'aide chez Posteo</a>. Cela m'a paru une bonne chose et j'ai coché la case sans chercher plus loin.</p>
<p>Toujours d'après Posteo, moins de 5% des serveurs actifs ne sont pas encore mis à jour vers TLS 1.2 ou TLS 1.3. Surprise, ceux d'Orange en font apparemment partie. En cherchant un peu j'ai trouvé des notifications du serveur Posteo qui m'informe effectivement avoir rejeté la réception de multiples courriel en l'absence d'une connexion TLS.</p>
<p>(Ça m'a rappelé leur paramétrage surprenant, sur lequel j'étais tombée il y a une dizaine d'année, qui donnait libre accès à la boîte de courriel liée à l'abonnement du moment qu'on avait pu se connecter à la livebox du domicile.)</p>
<p>Je pourrais évidemment désactiver cette « protection TLS » mais ça ne me semble pas une bonne idée. Si tous les autres fournisseurs ont fait le choix d'implémenter une version récente de TLS ça ne doit âs être juste pour faire joli ? Ou bien ?</p>
<p>Bref, je me suis mise en tête de leur envoyer un courriel pour le leur signaler et leur suggérer de faire la bascule - c'est mon côté Don Quichotte - mais pas moyen de trouver une adresse de courriel. Je tourne en rond sur orange.fr avec toujours le même résultat : il faut être abonné Orange pour arriver à les contacter par courriel.</p>
<p>Sauriez-vous où trouver cette adresse ? Au pire je passerai à l'enveloppe cachetée si je retrouve ma plume et mon encrier.</p>
<p>Merci d'avance !</p>
<div><a href="https://linuxfr.org/forums/general-general/posts/orange-ne-prend-pas-completement-en-charge-le-tls-comment-les-contacter-quand-on-est-pas-client.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/125302/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/general-general/posts/orange-ne-prend-pas-completement-en-charge-le-tls-comment-les-contacter-quand-on-est-pas-client#comments">ouvrir dans le navigateur</a>
</p>
thiolhttps://linuxfr.org/nodes/125302/comments.atomtag:linuxfr.org,2005:News/403542021-05-29T17:29:23+02:002021-05-29T17:29:23+02:00Le protocole QUIC désormais normaliséLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Le protocole de transport QUIC (couche 4 du modèle OSI) vient d’être normalisé, sous la forme de plusieurs RFC. QUIC, déjà largement déployé, peut changer pas mal de choses sur le fonctionnement de l’Internet, en remplaçant, au moins partiellement, TCP. C’est quoi, QUIC, et à quoi ça sert ? <img src="//img.linuxfr.org/img/68747470733a2f2f7175696377672e6f72672f61737365742f62616467652e706e67/badge.png" alt="Logo du groupe de travail QUIC" title="Source : https://quicwg.org/asset/badge.png"></p>
</div><ul><li>lien nᵒ 1 : <a title="https://www.rfc-editor.org/info/rfc9000" hreflang="en" href="https://linuxfr.org/redirect/108372">La norme de base de QUIC, le RFC 9000</a></li><li>lien nᵒ 2 : <a title="https://www.rfc-editor.org/info/rfc9001" hreflang="en" href="https://linuxfr.org/redirect/108373">La norme d'interaction entre QUIC et TLS, le RFC 9001</a></li><li>lien nᵒ 3 : <a title="https://www.rfc-editor.org/info/rfc8999" hreflang="en" href="https://linuxfr.org/redirect/108374">La norme sur les invariants de QUIC, le RFC 8999</a></li><li>lien nᵒ 4 : <a title="https://http3-explained.haxx.se/" hreflang="en" href="https://linuxfr.org/redirect/108375">Le livre libre et gratuit de Daniel Stenberg, qui couvre HTTP/3 mais aussi QUIC</a></li><li>lien nᵒ 5 : <a title="https://http3-explained.haxx.se/fr" hreflang="fr" href="https://linuxfr.org/redirect/108376">Sa version en français</a></li><li>lien nᵒ 6 : <a title="https://github.com/quicwg/base-drafts/wiki/Implementations" hreflang="en" href="https://linuxfr.org/redirect/108377">Une liste bien gérée des nombreuses mises en œuvre de QUIC</a></li><li>lien nᵒ 7 : <a title="https://www.rfc-editor.org/info/rfc9002" hreflang="en" href="https://linuxfr.org/redirect/108378">La norme sur la récupération en cas de perte de paquets, le RFC 9002</a></li><li>lien nᵒ 8 : <a title="https://hacks.mozilla.org/2021/04/quic-and-http-3-support-now-in-firefox-nightly-and-beta/" hreflang="en" href="https://linuxfr.org/redirect/108379">L'arrivée de QUIC dans Firefox</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#toc-couche-transport">Couche transport</a><ul>
<li><a href="#toc-quelles-limites-pour-comprendre-il-faut-revenir-%C3%A0-ce-%C3%A0-quoi-sert-la-couche-de-transport">Quelles limites ? Pour comprendre, il faut revenir à ce à quoi sert la couche de transport.</a></li>
<li><a href="#toc-maintenant-que-nous-avons-r%C3%A9vis%C3%A9-les-t%C3%A2ches-de-la-couche-transport-quelles-sont-ces-limites-de-tcp-dont-je-parlais-et-qui-justifient-le-d%C3%A9veloppement-de-quic">Maintenant que nous avons révisé les tâches de la couche transport, quelles sont ces limites de TCP dont je parlais, et qui justifient le développement de QUIC ?</a></li>
</ul>
</li>
<li><a href="#toc-quic-en-deux-mots">QUIC en deux mots</a></li>
<li><a href="#toc-les-d%C3%A9tails-de-mise-en-%C5%93uvre">Les détails de mise en œuvre</a></li>
<li><a href="#toc-les-normes">Les normes</a></li>
<li><a href="#toc-le-pass%C3%A9">Le passé</a></li>
<li><a href="#toc-et-pour-aller-encore-plus-loin">Et pour aller encore plus loin</a></li>
</ul>
<h2 id="toc-couche-transport">Couche transport</h2>
<p>QUIC n’est pas un protocole d’application (couche 7) comme peuvent l’être HTTP ou SSH. Les utilisateurs ordinaires ne verront pas la différence, ils se serviront des mêmes applications, via les mêmes protocoles applicatifs. QUIC est un protocole de transport (couche 4 du <a href="https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI">traditionnel modèle en couches OSI</a>), donc un concurrent de TCP, dont il vise à résoudre certaines limites, notamment dans le contexte du Web. </p>
<h3 id="toc-quelles-limites-pour-comprendre-il-faut-revenir-à-ce-à-quoi-sert-la-couche-de-transport">Quelles limites ? Pour comprendre, il faut revenir à ce à quoi sert la couche de transport.</h3>
<p>Placée entre les paquets d’IP, qui peuvent arriver ou pas, dans l’ordre ou pas, et les applications, qui comptent en général sur un flux d’octets ordonnés, où rien ne manque, la couche transport est chargée de surveiller l’arrivée des paquets, de signaler à l’émetteur qu’il en manque pour qu’il puisse réémettre, et de mettre dans le bon ordre les données. Dit comme ça, cela semble simple, mais cela soulève beaucoup de problèmes intéressants. Par exemple, il ne faut pas envoyer toutes les données sans réfléchir : le réseau n’est peut-être pas capable de les traiter, et un envoi trop brutal pourrait mener à la congestion du réseau. De même, en cas de pertes de paquet, il faut certes ré-émettre, mais aussi diminuer le rythme d’envoi, la perte pouvant être le signal que le réseau est saturé. C’est à la couche transport de gérer cette congestion, en essayant de ne pas la déclencher ou en tout cas de ne pas l’aggraver. En pratique, la couche transport est donc très complexe, comme le montre le nombre de RFC sur TCP.</p>
<h3 id="toc-maintenant-que-nous-avons-révisé-les-tâches-de-la-couche-transport-quelles-sont-ces-limites-de-tcp-dont-je-parlais-et-qui-justifient-le-développement-de-quic">Maintenant que nous avons révisé les tâches de la couche transport, quelles sont ces limites de TCP dont je parlais, et qui justifient le développement de QUIC ?</h3>
<p>Notez d’abord qu’elles ont surtout été mentionnées dans le contexte du Web. Celui-ci pose en effet des problèmes particuliers, notamment le désir d’une faible latence (quand on clique, on veut une réponse tout de suite) et le fait que l’affichage d’une seule page nécessite le chargement de plusieurs ressources (images, vidéos, code JavaScript, CSS, etc). La combinaison de TCP et de TLS n’est pas satisfaisante question latence, puisqu’il faut d’abord établir la connexion TCP, avant de pouvoir commencer la négociation qui mènera à l’établissement de la session TLS. Ensuite, TCP souffre du manque de parallélisme : quand on veut récupérer plusieurs ressources, il faut soit ouvrir plusieurs connexions TCP, qui ne partageront alors plus d’information (délai aller-retour, taux de perte, etc) ou de calculs (cryptographie…), soit multiplexer à l’intérieur d’une connexion TCP, ce que fait HTTP/2 mais, alors, on risque le <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">head-of-line blocking</a>, où la récupération d’une ressource bloque les suivantes, et le fait que la perte d’un seul paquet va faire ralentir tous les téléchargements.</p>
<h2 id="toc-quic-en-deux-mots">QUIC en deux mots</h2>
<p>Quels sont les concepts de base de QUIC ? QUIC gère des <em>connexions</em> entre machines, comme TCP. Par contre, contrairement à TCP, ces connexions portent ensuite des <em>ruisseaux</em> (<em>streams</em>) séparés, ayant leur propre contrôle de congestion, en plus du contrôle global à la connexion. Les ruisseaux peuvent être facilement et rapidement créés. Ce n’est pas par hasard que le concept ressemble à celui des ruisseaux de HTTP/2, dans les deux cas, le but était de s’adapter au désir des navigateurs Web de charger toutes les ressources d’une page en parallèle, sans pour autant « payer » l’établissement d’une connexion pour chaque ressource.</p>
<p>Avec QUIC, le chiffrement est obligatoire. Il n’y a pas de version de QUIC en clair. Non seulement les données applicatives sont chiffrées, comme avec TLS ou SSH mais une bonne partie de la couche transport l’est également. Pourquoi ?</p>
<ul>
<li>En raison de la prévalence de la surveillance massive sur l’Internet ; moins on expose de données, moins il y a de risques.</li>
<li>Afin d’éviter que les <em>middleboxes</em> (les boitiers intermédiaires qui regardent au-dessus de la couche 3) ne se croient capables d’analyser le fonctionnement de la couche transport, et ne se croient autorisées à y intervenir, ce qui mènerait à une <a href="https://en.wikipedia.org/wiki/Protocol_ossification">ossification de l’Internet</a>. Si tout est chiffré, on pourra faire évoluer le protocole sans craindre l’intervention de ces fichus intermédiaires.</li>
<li>Certains FAI (Fournisseur d’accès à l’Internet) ont déjà exploité le caractère visible de TCP pour des attaques, par exemple en envoyant des paquets RST (<em>ReSeT</em>) pour couper le trafic BitTorrent. TLS et SSH ne protègent pas contre ce genre d’attaques.</li>
<li>L’observation de la couche transport peut permettre d’identifier les services utilisés et d’en dé-prioritiser certains. Le chiffrement du transport peut donc aider à préserver la neutralité du réseau.</li>
</ul>
<p>On peut prévoir que les habituels adversaires du chiffrement protesteront d’ailleurs contre QUIC, en l’accusant de gêner la visibilité (ce qui est bien le but).</p>
<p>QUIC utilise le classique protocole TLS pour le chiffrement <em>mais</em> pas de la manière habituelle. Normalement, TLS fait la poignée de main initiale, l’échange des clés <em>et</em> le chiffrement des données. Avec QUIC, TLS ne fait que la poignée de main initiale et l’échange des clés. Une fois les clés obtenues, QUIC chiffrera tout seul comme un grand, en utilisant les clés fournies par TLS.</p>
<h2 id="toc-les-détails-de-mise-en-œuvre">Les détails de mise en œuvre</h2>
<p>Puisqu’on a parlé des <em>middleboxes</em> : déployer un nouveau protocole de transport dans l’Internet d’aujourd’hui est très difficile, en raison du nombre d’équipements qui interfèrent avec le trafic (les routeurs NAT, par exemple). Conceptuellement, QUIC aurait pu tourner directement sur IP. Mais il aurait alors été bloqué dans beaucoup de réseaux. D’où le choix de ses concepteurs de le faire passer sur UDP. QUIC utilise UDP comme il utiliserait IP. On lit parfois que QUIC, ce serait « HTTP au-dessus d’UDP », mais c’est une grosse incompréhension. QUIC est une couche de transport complète, concurrente de TCP, dont le fonctionnement sur UDP n’est qu’un détail nécessaire au déploiement. QUIC n’a aucune des propriétés d’UDP. Par exemple, comme TCP, mais contrairement à UDP, QUIC teste la réversibilité du trafic, ce qui empêche l’usurpation d’adresses IP et toutes les attaques UDP qui reposent dessus.</p>
<p>QUIC est parfois présenté comme « tournant en mode utilisateur et pas dans le noyau du système d’exploitation ». En fait, ce n’est pas spécifique à QUIC. Tout protocole de transport peut être mis en œuvre en mode utilisateur ou noyau (et il existe des mises en œuvre de TCP qui fonctionnent en dehors du noyau). Mais il est exact qu’en pratique la plupart des mises en œuvre de QUIC ne sont pas dans le noyau du système, l’expérience prouvant que les mises à jour du système sont souvent trop lentes, par rapport au désir de faire évoluer en permanence la couche transport. Et puis, sur Microsoft Windows, Google, premier promoteur de QUIC, n’aime pas dépendre de Microsoft pour les performances de son navigateur Chrome.</p>
<h2 id="toc-les-normes">Les normes</h2>
<p>Les RFC normalisant QUIC sont :</p>
<ul>
<li>
<a href="https://datatracker.ietf.org/doc/html/rfc9000">RFC 9000</a> est la norme principale, décrivant le socle de base de QUIC ;</li>
<li>
<a href="https://datatracker.ietf.org/doc/html/rfc9001">RFC 9001</a> normalise l’utilisation de TLS avec QUIC ;</li>
<li>
<a href="https://datatracker.ietf.org/doc/html/rfc9002">RFC 9002</a> spécifie les mécanismes de récupération de QUIC, quand des paquets sont perdus et qu’il faut ré-émettre, sans pour autant écrouler le réseau ;</li>
<li>
<a href="https://datatracker.ietf.org/doc/html/rfc8999">RFC 8999</a> est consacré aux invariants de QUIC, aux points qui ne changeront pas dans les nouvelles versions de QUIC.</li>
</ul>
<p>J’ai dit que QUIC, comme TCP, est un protocole de transport généraliste, et qu’on peut faire tourner plusieurs applications différentes dessus. En pratique, QUIC a été conçu essentiellement en pensant à HTTP mais dans le futur, d’autres protocoles pourront profiter de QUIC, notamment s’ils ont des problèmes qui ressemblent à ceux du Web (désir de faible latence, et de multiplexage).</p>
<p>Pour HTTP, la version de HTTP qui tourne sur QUIC se nomme HTTP/3 et sera normalisée dans un futur RFC. Comme HTTP/2, HTTP/3 a un encodage binaire, mais il ne fait plus de multiplexage, celui-ci étant désormais assuré par QUIC.</p>
<h2 id="toc-le-passé">Le passé</h2>
<p>QUIC a eu une histoire longue et compliquée. À l’origine, vers 2012, QUIC était un projet Google. Si les motivations étaient les mêmes que celles du QUIC actuel, et que certains concepts étaient identiques, il y avait quand même deux importantes différences techniques : le QUIC de Google utilisait un protocole de cryptographie spécifique, au lieu de TLS, et il était beaucoup plus marqué pour son utilisation par HTTP uniquement. Et il y a aussi bien sûr une différence politique, QUIC était un protocole privé d’une entreprise particulière, il est maintenant une norme IETF (<em>Internet Engineering Task Force</em>).</p>
<h2 id="toc-et-pour-aller-encore-plus-loin">Et pour aller encore plus loin</h2>
<ul>
<li>La norme de base sur TCP, le <a href="https://www.rfc-editor.org/info/rfc793">RFC 793</a> </li>
<li>Une <a href="https://www.rfc-editor.org/info/rfc7414">liste commentée des RFC à lire sur TCP</a> </li>
<li>Le <a href="https://www.rfc-editor.org/info/rfc7540">RFC sur HTTP/2</a> </li>
<li>Le <a href="https://www.rfc-editor.org/info/rfc7258">RFC sur la surveillance massive, et l’engagement de l’IETF</a> à lutter contre cette attaque </li>
<li>Sur la notion d’« image montrée au réseau », le <a href="https://www.rfc-editor.org/info/rfc8546">RFC 8546</a> </li>
<li>Un <a href="//linuxfr.org/news/google-veut-reduire-la-latence-sur-internet-avec-quic">ancien article de LinuxFr.org sur QUIC</a>
</li>
</ul>
</div><div><a href="https://linuxfr.org/news/le-protocole-quic-desormais-normalise.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/123568/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/le-protocole-quic-desormais-normalise#comments">ouvrir dans le navigateur</a>
</p>
Stéphane BortzmeyerclaudexorfenorYsabeau 🧶 🧦AnonymeBenoît Sibaudesdeempalm123Stefane FermigierLtrlgkptedYves Bourguignonhttps://linuxfr.org/nodes/123568/comments.atomtag:linuxfr.org,2005:Post/419802021-03-25T00:30:49+01:002021-03-25T00:30:49+01:00Faire un proxy SMTP TLS pour des outils ne sachant faire que du SMTP port 25<p>Hello,</p>
<p>Ma boite vient de passer sur une solution de messagerie commerciale bien connue pour laquelle j'éviterais de faire de la pub.<br>
Pour acheminer correctement les mails envoyés par nos apps legacy l'éditeur nous conseille très fortement de faire du smtp/tls (port 587).<br>
Cependant nos applis (propriétaires) legacy ne savent faire que de l'envoie vers des serveurs smtp en port 25.<br>
Comme je n'y comprends rien en crypto (ssl/tls) pensez vous qu'il soit possible de proxyfier le flux de smtp en port 25 via haproxy (que j'utilise déjà) et que haproxy transfert ce flux vers notre nouvelle solution de messagerie en TLS sur le port 587?</p>
<p>Est-ce que eventuellement vous auriez un exemple de config sur haproxy pour faire ça?</p>
<p>Merci par avance de vos réponses.</p>
<div><a href="https://linuxfr.org/forums/linux-general/posts/faire-un-proxy-smtp-tls-pour-des-outils-ne-sachant-faire-que-du-smtp-port-25.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/123689/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-general/posts/faire-un-proxy-smtp-tls-pour-des-outils-ne-sachant-faire-que-du-smtp-port-25#comments">ouvrir dans le navigateur</a>
</p>
Orwellhttps://linuxfr.org/nodes/123689/comments.atomtag:linuxfr.org,2005:Bookmark/27312021-02-25T23:30:49+01:002021-02-25T23:30:49+01:00Bulletproof TLS Newsletter #74 - Rust and cryptographic code<a href="https://www.feistyduck.com/bulletproof-tls-newsletter/issue_74_rust_and_cryptographic_code">https://www.feistyduck.com/bulletproof-tls-newsletter/issue_74_rust_and_cryptographic_code</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/123404/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/anonyme/liens/bulletproof-tls-newsletter-74-rust-and-cryptographic-code#comments">ouvrir dans le navigateur</a>
</p>
Anonymehttps://linuxfr.org/nodes/123404/comments.atomtag:linuxfr.org,2005:Bookmark/24892021-01-07T21:03:17+01:002021-01-07T21:03:17+01:00Encrypted Client Hello: the future of ESNI in Firefox - blog.mozilla.org<a href="https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/">https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/122857/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/encrypted-client-hello-the-future-of-esni-in-firefox-blog-mozilla-org#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/122857/comments.atomtag:linuxfr.org,2005:Diary/395202020-12-23T22:42:12+01:002020-12-23T22:42:12+01:00Android < 7.1 va refuser les connections TLS certifiées par Let's EncryptLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Hello,</p>
<p>En novembre dernier, Let's Encrypt a <a href="https://letsencrypt.org/2020/11/06/own-two-feet.html">annoncé</a> que ~ 33,4% utilisateurs d'Android (ceux dont la version Android est plus vieille que la 7.1.1) ne pourront plus se connecter aux sites webs et ressources Internet certifiées par leurs certificats.</p>
<p>En effet, ils ont noté à juste titre que le certificat racine <code>DST Root X3</code> d'<em>IdenTrust</em> va expirer en septembre 2021.</p>
<p>Or, c'est ce certificat racine qui est utilisé pour signer le certificat intermédiaire <code>Let's Encrypt Authority X3</code> de Let's Encrypt et permettre d'avoir la chaîne complètement validée sur les anciens systèmes d'exploitations.</p>
<p>En effet, ces anciens systèmes ne reçoivent plus de mises à jour et ils n'ont pas intégré le nouveau certificat racine <code>ISRG Root X1</code> de Let's Encrypt. La chaîne de confiance ne pourra donc théoriquement plus être confirmée après septembre 2021.</p>
<p>Vous noterez que Let's Encrypt proposait 3 solutions à ce problème pour les propriétaires de sites web:<br>
1. Faire installer Firefox aux utilisateurs d'anciennes versions d'Android<br>
2. Basculer en HTTP sans TLS<br>
3. Ne plus utiliser Let's Encrypt pour créer ses certificats, mais un des CA disponible dans ces cersions</p>
<p>Malheureusement, Firefox ne résoudrait le problème que pour le web et uniquement pour Android version 5.0 ou supérieur.</p>
<p>Le 21 décembre dernier, Let's Encrypt <a href="https://letsencrypt.org/2020/12/21/extending-android-compatibility.html">remercie</a> l'innovation de sa communauté et la confiance d'<em>IdenTrust</em>. En effet, ils ont trouvé ensemble un moyen de conserver encore 3 ans la sécurité pour les utilisateurs d'Android < 7.1.1.</p>
<p>La communauté a remarqué qu'Android fait confiance inconditionnellement aux certificats racines installés sur le système (1). Donc, même si le certificat racine <code>DST Root X3</code> d'<em>IdenTrust</em> ne devrait plus être valide à partir de septembre 2021, Android continue de lui faire confiance.</p>
<p><em>IdenTrust</em> a accepté de cross-signer le certificat racine <code>ISRG Root X1</code> de Let's Encrypt pour une durée de 3 ans. Oui, cette fois, c'est bien le certificat racine de Let's Encrypt qui est directement cross-signé et non pas le certificat intermédiaire.</p>
<p>Cette solution permet à Let's Encrypt de passer à leur nouvelle chaîne de certificat tout en restant compatible avec les anciennes versions d'Android, comme montré dans leur schéma:</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f6c657473656e63727970742e6f72672f696d616765732f323032302e31322e32312d616e64726f69642d636f6d7061742d636572742d636861696e2e706e67/2020.12.21-android-compat-cert-chain.png" alt="Transition de chaîne de certificat" title="Source : https://letsencrypt.org/images/2020.12.21-android-compat-cert-chain.png"></p>
<p>Comme vous pouvez le voir sur ce schéma, la nouvelle chaîne livrée par défaut aux clients de Let's Encrypt va contenir 4 certificats. D'un côté, ça va ralentir un peu l'initialisation de la connexion TLS, mais d'un autre, ça donne 3 ans de compatibilité Android en plus.</p>
<p>Le client pourra demander expressément d'utiliser la nouvelle chaîne avec uniquement 3 certificats, mais il perdra alors la compatibilité avec les anciennes versions d'Android. Dans ce cas, le client Let's Encrypt doit permettre de trouver les chaînes alternatives. C'est déjà le cas pour certbot et j'ai décidé de ne pas l'implémenter pour <a href="https://projects.adorsaz.ch/adrien/acme-dns-tiny/-/issues/13">acme-dns-tiny</a>.</p>
<p>Bref, les utilisateurs d'Android ont eu chaud, mais ils ont plus de répit 😅</p>
<hr>
<p>1: J'ai appris dans cet article, que le standard précise que pour valider les <em>trust anchors</em> (certificats racines de confiances du système), le client TLS (le système d'exploitation, le navigateur…) peut choisir ou non de suivre les indications des différents champs présents. Android a décidé de ne pas utiliser le champ <em>notAfter</em> dans leur implémentation et ça aide bien Let's Encrypt pour cette fois. Il se peut que d'autres systèmes fassent de même.</p>
<div><a href="https://linuxfr.org/users/trim/journaux/android-7-1-va-refuser-les-connections-tls-certifiees-par-let-s-encrypt.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/122718/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/trim/journaux/android-7-1-va-refuser-les-connections-tls-certifiees-par-let-s-encrypt#comments">ouvrir dans le navigateur</a>
</p>
Adrien Dorsazhttps://linuxfr.org/nodes/122718/comments.atom