Chrome va bientôt pouvoir automatiquement bloquer les téléchargements HTTP
Si Chrome et Safari ajoutent déjà la mention « non sécurisé » dans la barre d'URL lorsque l'internaute se connecte à un site HTTP, Google envisage d'aller plus loin. Maintenant que le HTTPS est devenu la norme, la firme de Mountain View prépare une option permettant de bloquer les téléchargements HTTP non sécurisés.
Chrome dispose d'une option (désactivée par défaut) permettant de « Toujours utiliser les connexions sécurisées ». Si l'utilisateur tombe sur un site HTTP, le navigateur va tenter de passer sur sa version HTTPS avant d'afficher un avertissement si celle-ci n'est pas disponible.
À l'avenir, Google va améliorer cette option en bloquant au passage les liens de téléchargement HTTP. Cela devrait offrir une sécurité accrue, par exemple dans le cas où l'on clique sur un lien HTTPS redirigeant vers un serveur HTTP frauduleux. La fonction va également bloquer tous les téléchargements provenant d'un site HTTP. Évidemment, l'utilisateur gardera le choix d'outrepasser l'avertissement et de lancer le téléchargement, mais cela devrait éviter quelques mauvaises surprises aux internautes les moins avancés.
La fonction ne devrait cependant pas arriver tout de suite : il est peu probable qu'elle puisse être testée à grande échelle avant Chrome 111, dont la sortie est prévue en mars 2023. Le déploiement officiel devrait donc se faire plus tard dans l'année.
S'ils peuvent aussi ajouter une option pour bloquer http 1 et 2
@koko256
?????
@Change
Pour pousser la transition vers http 3 et se débarrasser un peu plus de l'encombrant TCP
@koko256
Si ça met autant de temps que l'ipv6 😵💫
@Change
L’ipv6 ne prend pas car moins pratique à utiliser, tu meurs… Les adresses sont impossibles à retenir, les routeurs ne sont pas compatibles, le NAT changé, les vlan différents etc. C’est trop extrême. Mais il faudra bien y aller un jour vu le manque d’ipv4.
@Eyquem
Pas pratique pour l'humain.
Pour les machines c'est déjà en place depuis longtemps.
@Eyquem
"le NAT changé"
l'IPv6 ne change pas le NAT. Il supprime cette immondice.
@koko256
Pas nécessaire : ça se fait automatiquement par négociation de protocole dans la requête que tu envoies ;)
Chrome prend tranquillement la grosse tête: c'est le seul navigateur qui indique lors du téléchargement d'un fichier .dmg:
"Ce type de fichier risque d'endommager votre ordinateur".
Et ce, même si le fichier .dmg est correctement signé et notarisé par Apple.
Le comble c'est qu'il affiche ce même message délirant lors du téléchargement de "googlechrome.dmg" !
A moins que ça soit pour faire la nique à Apple ?
Et sur un réseau local ? Comme sur la page d’administration d’un NAS ou d’une imprimante ?
Ces règles anti-https sont un peu stupides. Le https ne garanti en rien que le fichier est sain ou que la connexion est sécurisée ! On peut très bien télécharger des malwares en https… Un certificat s’applique en 3 secondes chrono sur n’importe quel serveur web et est gratuit en passant par let’s encrypt 🤦♂️
Tu confonds le contenu et le contenant.
@ultrabill
On parle du contenant, le https est juste un protocole de transport de données, une sorte de tunnel chiffré. La confusion est justement là, de croire que le https protège. C’est complètement faux.
@Eyquem
C’est exactement ça. Et ceux qui pensent que puisque leur connexion a leur banque est en https ils sont en sécurité, ils se trompent.
Il faut toujours vérifier le certificat.
En entreprise par exemple, le certificat n’est pas celui de la banque, mais du proxy de l’entreprise. Il y a un middle man qui observe tout.
Ceci s’applique aussi lorsque l’on se branche sur des hotspots publics (hôtels, cafés, var, écoles, et j’en passe), on fait confiance aveuglément.
Rien de tel qu’un vpn vers un serveur connu dont on sait qu’il n’y a pas de middle man…
Le https est une fausse preuve de sécurité.
@Sillage
Hum… je ne crois pas. Même avec un proxy au milieu, le https (le TLS pour être plus précis) est établi entre ton navigateur et le site distant. Ce que voit le proxy, c’est le domaine que tu requêtes mais pas le contenu si celui-ci est servi avec https (il me voit mais crypté). A noter que ce n’est pas vrai avec les clients légers type Citrix il me semble.
Et sur un hotspot public, c’est la même chose. Sur ceux-ci tu as aussi souvent le serveur dns qui est imposé ce qui permet au hotspot de savoir les requêtes dns que tu fais. C’est notamment la raison du développement de DNS over TLS et de DNS over HTTPS.
@fornorst
Malheureusement non.
La prochaine fois que tu es derrière un proxy, genre en entreprise, ça sur un site que tu connais, et regarde le certificat. Regarde qui en est l’émetteur. Tu verras que c’est le proxy de la compagnie.
A la maison, tu auras bel et bien le certificat du site distant.
Ceci dit, tu as bel et bien une liaison cryptée, mais entre ton ordinateur et le proxy, et entre le proxy et le serveur distant. Mais c’est en clair pour le proxy.
Le problème des hotspots publics, c’est que n’importe qui créer un hotspot similaire, et observer tout le traffic. C’est la façon avec laquelle des identifiants sont copiés. Très utile quand il n’y a pas de 2FA.
D’où la grande raison pour laquelle il ne faut jamais faire confiance à un hotspot public.
Concernant les DNS, je ne m’y connais pas. J’ai découvert il y a peut AdGuard home, qui te permet de te créer ton propre serveur DNS pour faire simple.
J’ai commencé à découvrir ces DNS over TLS où en HTTPS.
“Sur ceux-ci tu as aussi souvent le serveur dns qui est imposé ce qui permet au hotspot de savoir les requêtes dns que tu fais. “
Le DNS n’est jamais imposé. Tout serveur DHCP te fourni les IPs du serveur DNS. Mais rien ne t’empêche de les changer.
Changer de serveur DNS est utile pour empêcher ton FAI de faire des statistiques sur les pages visitées.
Changer de serveur DNS est utile pour empêcher ton FAI de faire des statistiques sur les pages visitées.
Non, déjà le DNS c'est le nom de domaine et pas les pages. Et comme le FAI voit tout le trafic passer, il voit aussi à minima les adresses IPs (et peux donc plus ou moins trouver le nom de domaine).
@bibi81
Si tu n’utilises pas les serveurs DNS de ton FAI cela limite le tracking fait par eux des sites que tu visites au moyens des logs du serveur DNS.
En revanche, oui, ils peuvent voir tout le traffic et les IPs que tu visites. Rien ne leur empêche de faire ce que tout tu peux faire, genre un wireshark. Je ne sais pas ce qu’ils utilisent, mais ne pas utiliser les serveurs DNS de ton FAI change déjà la donne.
mais ne pas utiliser les serveurs DNS de ton FAI change déjà la donne.
Non, les boîtes noires ont été installées dans les routeurs, pas dans les serveurs DNS.
@fornorst
"Hum… je ne crois pas. Même avec un proxy au milieu, le https (le TLS pour être plus précis) est établi entre ton navigateur et le site distant. Ce que voit le proxy, c’est le domaine que tu requêtes mais pas le contenu si celui-ci est servi avec https"
Beaucoup de mauvaises DSI d'entreprise utilisent encore des "proxy SSL", c'est-à-dire des attaques de l'Homme du Milieu (MITM).
Ça n'a aucune légitimité, mais c'est une pratique encore courante.
Ces proxy reposent sur la PKI interne de l'entreprise, dont le certificat racine est déployés sur tous les terminaux gérés et qui produit des certificats bidons pour tous les domaines consultés par les utilisateurs. Ces certificats étant émis par la PKI interne, connue des terminaux (qui ont son certificat racine), les navigateurs n'y voient que du feu et les utilisateurs de remarquent rien.
Sauf pour les services davantage sécurisés, qui détectent cette attaque et la bloque (APNs par exemple, qui est un cas classique de débat avec les DSI qui doivent déployer des Mac derrière un proxy SSL…).
@Sillage
"Ceci s’applique aussi lorsque l’on se branche sur des hotspots publics (hôtels, cafés, var, écoles, et j’en passe), on fait confiance aveuglément."
Il y en a encore qui font ça oui, mais c'est absolument illégitime et totalement sale en terme de sécurité. Une seule solution quand on est confronté à un tel réseau : ne pas s'y connecter du tout. Un réseau configuré (avec le cul) de la sorte est indigne de confiance.
@nmo
« Il y en a encore qui font ça oui, mais c'est absolument illégitime et totalement sale en terme de sécurité. »
Je privilégie normalement l’usage de mon cellulaire comme hotspot en lieu et place d’un hotspot publique.
Mais dans les cas où on ne peut faire autrement, le VPN protège justement des regards indiscrets intermédiaires. Toujours en VPN quand j’utilise un hotspot publique tel que celui de l’hôtel.
« Une seule solution quand on est confronté à un tel réseau : ne pas s'y connecter du tout. Un réseau configuré (avec le cul) de la sorte est indigne de confiance. »
Comment ça « configure avec le cul » ? (Je ne pige pas vraiment le sens ici).
Réseau ouvert ou pas, n’importe qui peut s’intercaler. Pas vraiment un risque quand la clé est secrète, mais quand inscrite sur un mur au bistro du coin, n’importe quoi peut se mettre comme intermédiaire, et ainsi observer tout ce qui passe. Y compris le HTTPS si fait comme il faut. (Pour ceux qui ne pigent pas, le HTTPS est bien évidemment crypté entre le serveur et le client. Mais quand un serveur intermédiaire existe (proxy), le proxy est le client du serveur distant pour faire simple).
Bien évidemment, la règle est d’éviter tout hotspot publique. Mais il y a moyen de les utiliser intelligemment aussi… Mais ce n’est pas à la portée de tous en effet.
@Eyquem
Dire que ça ne sert à rien parce que "HTTPS ne garanti en rien que le fichier soit sain" c'est comme se plaindre qu'un code PIN d'une carte bancaire ne garanti en rien l'achat d'un produit non contrefait. Ou qu'une capote n'empêche pas les viols.
Les solutions retenues (HTTPS, code PIN, capote) sont efficaces contre les problème visés; tu ne peux pas les dénigrer parce qu'elles ne répondent pas à un autre problème.
Le problème c'est d'utiliser HTTPS pour tout, cela ne sert à rien.
Si tu considères que la confidentialité des données (quelles qu'elles soient) transitant sur un réseau (quel qu'il soit) c'est inutile, alors je comprends ton raisonnement. Mais je n'y adhère pas.
@Eyquem
"Le https ne garanti en rien que le fichier est sain ou que la connexion est sécurisée !"
ça n'est pas une garantie absolue, mais une protection bonne à prendre.
HTTPS vise justement à sécuriser la connexion entre le serveur et le client et donc pour effet, entre autre, de réduire le risque de compromission des données échangées via cette connexion.
Donc bien sûr qu'HTTPS ne garantie pas absolument que le fichier téléchargé soit sain. Mais il complique fortement son interception et altération entre le serveur et le client.
Il faut utiliser HTTPS dès lors qu'on doit s'assurer de l'authenticité de la données échangée. C'est le minimum syndical.
+1. Je ne vois pas l'intérêt.
hors sujet
est-ce que vous savez comment effacer le cache d’une application en particulier sur iphone ?
a part effacer l’historique sur safari je vois pas.
merci
Firefox le fait déjà depuis des lustres avec la comfig ‘https only’