fabien29200, le 07/09/2012 - 16:56

Oui, tu as accès à cette information, car ton serveur est un bout de la connexion chiffrée.

Donc c'est logique qu'il y ait accès, et qu'il puisse tenir des logs avec les informations qu'il voit passer.
Petit rappel évident : le chiffrement ne protège que pendant le transport, il ne protège pas les deux bouts que sont le client et le serveur (autrement dit, le destinataire d'une lettre peut retirer l'enveloppe, et doit d'ailleurs le faire pour la lire, mais il ny a aucune garantie sur ce qu'il fera avec les informations contenus dans ladite lettre).

Dans le cas présenté, les serveurs de Wikipédia étant situés en dehors de la Grande-Bretagne, HTTPS permet de revenir dans une situation similaire à la normale : le FAI transporte en aveugle, et Wikipédia peut continuer à tenir des logs des visites pour eux-mêmes (s'ils le faisaient, mais je n'en doute pas), sans obligation de les fournir de manière systématique et automatique aux autorités britanniques.

fabien29200, le 07/09/2012 - 16:20

En même temps, HTTPS n'empêche aucunement de voir à quelles pages on accède sur un site.

Réponse courte : si.

Réponse longue : le client se connecte sur le serveur, négocie la sessions TLS (le reste est chiffré). La demande au serveur (page, envoi des cookies, du nom de domaine demandé, des données de formulaire) est faite ensuite.
Le FAI, lui, va juste voir qu'il y a eu une connexion HTTPS sur le serveur web ayant l'adresse IP ch.i.ff.ré

Que nécessite réellement le https ?
En lisant l'article je comprends que wikipedia le gère mais ne le force pas, mais que tout les sites ne le gèrent pas.
S'il ne le force pas c'est qu'il doit y avoir un effet négatif pour certain internaute ? manipulation sur le client web ou juste le 's' dans l'adresse ? Et si tout les sites ne le gèrent pas, c'est parce qu'il y a un coup supplémentaire pour faire/heberger des sites en https ?

Le chiffrement a en effet un coût : cela fait faire plus de calculs, que ce soit pou le client ou pour les serveurs derrière.
Pour le client, vu la puissance des machines, c'est plus que négligeable, donc il n'y a aucun inconvénient à chiffrer. Pareil pour un serveur qui reçoit peu de visiteurs.
En revanche, sur des grosses infrastructures comme celles de Wikipédia ou Google, si tous les visiteurs se mettent à chiffrer du jour au lendemain, ça va augmenter la charge, et nécessiter des investissements.

skhaen, le 07/09/2012 - 15:54

Dans ce cas là tu vérifies l'empreinte du site sur lequel tu es, des plugins font ça très bien.

Ca ne résouds pas le problème de la première connexion, qui doit être sûre.
Certains modes de fonctionnement de DANE pourraient répondre à ces problématiques, en espérant qu'ils soient déployés un jour : http://www.bortzmeyer.org/6698.html

Dans tous les cas, à moins de se passer d'autorité de certification (ce que permettent les deux derniers modes de DANE), ça ne protège pas contre l'autorité de certification si elle génère totalement le certificat (et le secret associé ) et en garde une copie.

orange, bouyghes et sfr sont aussi dans l'illégalité avec leur pack . portable+forfait.

Non, car ils te proposent d'acheter les téléphones et les forfaits séparéments.

La loi n'empêche pas de faire des lots (Biens + Services), elle dit juste que si c'est le cas, il *doit* être possible d'acquérir les deux séparément.

Au passage, comme l'ont dis certains, un laptop sans OS c'est galère à trouver. Avec leur c*** de Secure Boot, un laptop "débridable" risque aussi de devenir pénible à trouver. Pour les fixes, je ne me fais pas de soucis, on pourra toujours assembler sa machine. Mais un portable, c'est quasiment impossible de faire de l'assemblage. Obliger la séparation de la vente OS et PC "oblige" du même coup à avoir un Secure Boot désactivable, ce qui n'est pas un mal.

L'ironie de l'histoire : vu que Google ne peut contacter individuellement les personnes concernées (c'est impossible de rattacher un SSID a une personne, même avec la géolocalisation), soit les données sont libérées dans la nature (ce qui est totalement contraire à l'objectif, et fera un excellent annuaire des réseaux wifi ouverts), soit un formulaire sera mis en place (où on entre son SSID et sa ville par exemple) et du coup, la collecte de données continuera, mais de manière volontaire.

Anzufvytar, le 22/11/2010 - 13:43

Facile, il suffit de deviner une de tes adresses MAC

C'est encore plus facile quand tu sais que les adresses mac sont diffusées en clair. Donc il suffit juste d'attendre que tu t'y connecte.
Même chose pour le SSID masqué : il se retrouve à la connexion (ta carte broadcaste une liste des SSID auxquelles elle veut s'associer). Bref, deux "protections" qui n'en sont pas. Juste de quoi faire perdre 30s à une personne expérimentée.

jvachez, le 18/10/2010 - 18:05

Cette pénurie n'est pas grave. Les opérateurs ont déjà trouvé la solution et cela sans utiliser IPv6. La technique s'appelle le NAT. C'est déjà utilisé en 3G où des milliers d'utilisateurs sont regroupés sous la même IP. Grâce au NAT un opérateur peut gérer des miliers d'abonnés avec seulement une dizaine d'IP.

Heu... Le NAT est utilisé à grande échelle depuis une dizaine d'années (notamment dans les box) et on a bien vu ce que ça donne. àa casse le bout en bout, donc :
-àa empêche les gens derrière un NAT d'être joignable, donc d'avoir un serveur. Si on fait l'analogie avec le téléphone, tu pourrais appeler mais personne ne pourrait t'appeler (car tu n'aurais pas de n° de téléphone). Par extension, cela empêche le P2P.
-àa casse plein de protocoles (au hasard, FTP, SIP, IPSec, etc) qui transmettent des adresses au niveau applicatif, ou qui signent le paquet en tenant compte des en-têtes IP.
Il a été estimé que ces contraintes techniques augmentaient le budget des applis réseaux de 10% (notamment pour faire du nAT entrant de façon transparente sans que l'utilisateur final ne s'en aperçoive).
http://g6.asso.fr/bl...expert-1108.pdf (page 6, "Pourquoi pas le NAT").

Sans compter les contraintes légales/humaines, genre le bannissement d'UNE IP blackliste tout ceux qui sont derrière un même équipement, donc potentiellement beaucoup de monde...

Zarkoff, le 05/10/2010 - 13:08

Gnommy, le 05/10/2010 - 13:04

Ca existe déjà, chez sfr ( 14,90 ), chez bouygues ( 19,90 ) chez NC ( 19.90 ) mais encore faut-il le savoir, l'exiger et avoir son propre modem routeur...

Même en dégroupage total ?

Bon, on va récapituler : les frais dépendant de la consommation de BP/des services sur la ligne/etc sont quasi-nuls !
Ce qui coûte le plus, c'est de déployer une infrastructure, et ce sont des coûts fixes. Une fois que l'on a cette infra, cela coûte peanuts d'ajouter des services dessus, quels qu'ils soient.

Quand au dégroupage total en dessous de 25€, même pas pensable : les FAIs louent la ligne de cuivre à FT 9€ pour du dégroupage total. Les 15€ pour de l'Internet seul, ça couvre uniquement les frais fixes (grosso-modo amener des équipements et du réseau dans le central téléphonique), un peu de BP et quasi-aucune marge. Pour de la TV ou du téléphone seul, on arrive au même prix minimal.

dieangel, le 11/08/2010 - 17:52

Au passage, Quid d'un article pour pouvoir utiliser un modem non free sur un abonnement free?

àa, ce n'est pas très dur. C'est même expliqué sur la FAQ de Free, et ça marche très bien .
En gros, il te faut un modem tout simple, ton IP et ta passerelle (il suffit de remplacer le dernier octet de ton adresse IP par 254). Ou alors un modem-routeur respectant la RFC 2684.
http://www.free.fr/a...modem-adsl.html

Marco46, le 27/07/2010 - 20:52

Mouai ... Je suis pas sûr que tu comprennes ce que tu dis.
Ce n'est pas parce que ton FAI de donne une IP dynamique qui change chaque semaine ou à chaque fois que tu rebootes ta box que chaque IP qui t'a été attribuée t'appartient.

Jusqu'à preuve du contraire, lorsque tu as une seule connexion à Internet (un abonnement comme quelqu'un te l'a dit plus haut), tu as une seule IP sur le réseau. Et c'est tout ce qui compte. VPNs et autres Proxy n'ont strictement rien à voir, il ne s'agit pas de ton adresse de ton connexion sur le réseau, c'est à dire ton IP publique.

Le VPN "consomme" une IP publique hein... Forcément. Elle t'est attribué.

Autre chose, on attribue des IPs par blocs. Ces blocs ont des tailles indivisibles (des puissance de deux). Donc il y a forcément des pertes. Si je veut 24 adresses IPs, je suis forcé de prendre un bloc de 32. Car on ne sait pas faire entre 16 et 32, tout simplement.

À cela, il faut compter les serveurs, etc... À vue de nez, j'ai 3 adresses IP publiques (1 sur ma connexion, 2 sur mon serveur... Oui, un PC peut avoir plusieurs adresses IPs, c'est le cas notamment des routeurs, qui doivent avoir une adresse sur chaque réseau qu'ils relient)... Quand tu compte comme ça, ça part trèèès vite les IPs publiques.

@OursBlanc : Pour l'IPv6, pas besoin de changer d'adresse mac pour changer d'adresse IP hein.
En autoconfiguration stateless, comme te l'a indiqué obcd, il y a la RFC 4941 (avtivé par défaut sous Windows, même si c'est très déconseillé par cette même RFC). Résultat, Mme Michu aura une IPv6 qui change en permanence, au moins à chaque redémarrage de son ordinateur, sans qu'elle n'ait à faire d'action particulière (voir http://www.bortzmeyer.org/4941.html). Et effectivement, sur Linux c'est un flag à ajouter.

Enfin, j'ajoute que changer son adresse IPv6 pour en prendre une autre manuellement dans le subnet qui nous est alloué, c'est 10s de temps maximum .

Gnommy, le 25/06/2010 - 19:00

"Reste maintenant à imaginer quelle pourrait être la véritable portée d'une telle loi, dans la mesure où Internet est un réseau décentralisé."

Hein ?

Kékidit le môssieu ?

Décentralisé ?

Où ça ?

Tous les principaux réseaux sociaux sont centralisés,
tous les principaux ' messengers ' se connectent à un serveur pour permettre la connexion entre 2 utilisateurs ou plus.

Hein ? Quoi ? Tu est sûr que tu ne confonds pas Internet avec le Minitel ?
http://www.fdn.fr/In...-Minitel-2.html

submerged, le 25/06/2010 - 20:51

Oula... Internet ne se résume pas aux réseaux sociaux et à la messagerie instantanée hein... Il y a aussi, voyons voir... les sites web ? l'email ? le peer to peer ?

Internet est un réseau décentralisé. Ce n'est peut-être pas le cas de toutes les applications qui sont construites dessus, mais là on fait référence à l'infrastructure sous-jacente. Au fait que si la moitié des routeurs du monde tombent en panne demain, il est bien possible que je puisse toujours consulter les mêmes sites en passant par ailleurs.

+1

Le coeur d'Internet est maillé, avec des liens multiples entre les opérateurs. Si demain les USA (ou tout autre pays) est coupé d'Internet, le reste du réseau pourra fonctionner sans problème, c'est juste que la partie coupée sera inaccessible.

Au moment de la coupure, ça risque de créer des problèmes, mais les routeurs vont se débrouiller pour trouver tous seuls les routes pour joindre ce qui fonctionne encore . Bref, techniquement ça marchera.

Et pour ton information, moins on aura de contenu "au centre" (ie chez les gros hébergeurs de contenu), mieux ça vaudra pour la résistance du réseau. En effet, si tout le contenu est chez des gros hébergeurs, il suffit de les couper eux pour que tout le contenu soit inaccessible. Il vaut bien mieux répartir le contenu un peu partout, justement pour qu'on puisse tout couper d'un coup (que cette coupure soit politique ou l'issue d'une attaque).

Bon, cela ne justifie pas de donner le pouvoir de couper le réseau à un homme. C'est même franchement inquiétant cette idée de prendre la main sur les infrastructures, quel qu'en soit la raison. Cette loi, si elle est votée, serait un coup de plus pour ce qu'il reste de notre Internet libre. Et un coup encore plus dur porté à la liberté d'expression.

Je ne regarde pas le foot (je n'en vois pas l'intérêt), mais pour ceux qui regardent, il parait que le son s'étale sous tellement peu de fréquences qu'on peut le filtrer facilement.
http://www.korben.in...r-vuvuzela.html

Croux, le 19/06/2010 - 02:15

Il n'y a techniquement aucun problème a utiliser le même certificat pour des sous-domaines, car un certificat peut contenir des noms alternatifs au sujet (contenant le distinguished name généralement unique lui, et qui inclue le common name comme nom de domaine). On peut aussi bien y déclarer plusieurs adresses IP (IP:1.2.3.4,IP:5.6.7.8) que d'autres noms (DNS:supermerdouille.fr), et même utiliser le caractère étoile pour faire référence à tous les sous domaines possibles (DNS:*.merdouille.fr)

En théorie oui. En pratique, ça se fait assez mal :
- Il y a peu d'autorités de certification donnant des certificats de ce type (ou alors avec un surcout délirant),
- Un certain nombre de navigateurs ne reconnaissent pas ces certificats comme valides (oua lors, cela varie très fortement d'une version à l'autre).

OVH tente de le faire depuis un petit moment maintenant. À chaque fois qu'Octave (fondateur d'OVH) nous propose de tester son système (sur les mailing lists), il y a toujours un ou deux navigateurs affichant une alerte sur les certificats (que ce soit avec des noms alternatifs ou des wildcards).

Bref, c'est loin d'être utilisé partout. Et pour cause...

Croux, le 19/06/2010 - 00:00

Utiliser le cryptage n'empêche pas d'identifier le protocole ne serait-ce que statistiquement (par la taille des paquets, le nombre d'échanges entre pairs et leurs directions, le contenu des négociations initiales nécessairement en clair effectuées dans le but d'établir un accord sur le cryptage, ...). Le cryptage n'empêche en rien d'établir la distinction entre les protocoles : Bittorrent, eMule, SSH, VNC, HTTPS, SMTPS, XMPP, ... car ils se comportent tous différemment ; même une encapsulation dans du HTTPS n'empêche pas une analyse statistique.

A partir de là il n'y a aucun obstacle à brider tous les échanges suivants entre deux pairs sans chercher à réanalyser le contenu des paquets.

Je confirme, l'analyse statistique permet de déduire énormément de choses sur un flux de données, chiffré ou non. Par exemple, le web suppose un trafic très asymétrique entre 2 IPs. Tous les téléchargements ont des "gros" paquets, remplis au maximum possible. Par contre, un protocole de chat en texte entre 2 personnes (typiquement IRC et/ou XMPP) aura un trafic avec un ratio plus faible (surtout XMPP si on héberge son propre serveur), et des paquets plus petits. Tous les protocoles p2p se repèrent aux nombres de connexions ouvertes dans les 2 sens et au fait d'avoir un trafic très symétrique... On peut continuer comme ça à l'infini.

Pour les échanges non-interactifs, on peut se permettre d'essayer de reproduire le comportement d'une connexion HTTPS (beaucoup plus de données dans un sens, des paquets "bourrés", etc) pour tromper la DPI. Mais ça suppose une dégradation des performances.

Sinon, pour TCP vs UDP, c'est simple : vu qu'UDP a tendance à saturer les réseaux par son absence de régulation, et qu'il est souvent jugé moins "important" que TCP (car utilisé pour les jeux, mais aussi pour les VPN), il risque d'être plus "ralenti" que n'importe quelle autre connexion (sauf quelques exceptions, comme le DNS ou la VoIP, mais les FAI risquent de privilégier LEUR solutions dans ce cas)

Croux, le 19/06/2010 - 01:27

kankan, le 19/06/2010 - 00:03

[...] la personnalisation des règles est très simple quand on connait le XML et les Regex. J'en ai déjà fait quelques-unes (LinuxFR, la console de gestion Free, SixXS, le moodle de mon école ).

La difficulté n'est pas de faire des règles mais d'être sûr qu'elles couvrent l'intégralité des urls du site (ne pas oublier les sous-domaines) tout en permettant un bon fonctionnement.

Convertir des "http://www.merdouille.fr/" en "https://www.merdouille.fr/" est facile mais il faut aussi savoir si dans quelques pages on n'utilise pas des "http://images.merdouille.fr/"... (et ensuite il faut qu'un service https existe dans ce cas)

Oui, en effet... Mais la plupart du temps, la méthode simple fonctionne très bien (LinuxFR et Free par exemple, ou la console est suffisemment bien fichu pour que si tu te connecte en HTTPS, tu y reste durant toute ta session).

Et pour les sous domaines genre "static.merdouille.com" ou "images.merdouille.com", il n'y a pas de HTTPS, car en général il ne peut y avoir qu'un certificat par coupe IP/port, et ces sous-domaines sont en général sur le même serveur avec les ports par défaut.

Enfin, l'essentiel c'est de protéger l'authentification et les ID de sessions. Si on a un sous-domaine non sécurisé pour servir le contenu statique, c'est beaucoup moins critique qu'un mot de passe transitant en clair (ou un ID de session). Bon, il faut aussi que les cookies soient créé uniquement pour ce domaine et pas les sous-domaines non protégés aussi.

àa fait un moment que je cherchais une extension de ce type. En revanche, je suis surpris du buzz qui tourne autour (une extension qui modifie les URLs à la volée, ça existait déjà bien avant). De plus, je me demande pourquoi elle n'est pas répertoriées sur https://addons.mozilla.org. Mais bon.

Ceci dit, elle a l'air franchement bien faite, et la personnalisation des règles est très simple quand on connait le XML et les Regex. J'en ai déjà fait quelques-unes (LinuxFR, la console de gestion Free, SixXS, le moodle de mon école ). Quelqu'un sait s'il y a un site officiel où les uploader ? (au pire je les mets sur mon propre site, mais elles ne seront franchement pas visibles)

pastamiam, le 17/06/2010 - 10:34

Pour changer d'IP, je pense que la seule solution c'est une lettre recommandé A/R à un dirigeant de Free et une autre en copie à la CNIL. Techniquement Free change de numéro de téléphone très facilement, pour changer d'IP ça serait également très simple (serveur authentification / DHCP / modif de la base / rehash et hop t'as une nouvelle IP libre).

C'est pas si simple hein. L'adresse IP chez Free correspond à la prise du DSLAM sur laquelle tu est branché.
Chaque DSLAM se voit attribué par Free 4 /24 (en général consécutifs, mais pas toujours). Ensuite, le DHCP du DSLAM attribue au modem branché sur la prise 1 la première IP du 1er /24, celui branché sur la prise 2 la seconde, etc.

Pour changer d'IP, il faut soit renuméroter le DSLAM (clairement inenvisageable) soit recâbler la ligne (cher pour du confort, donc jamais fait).

Après, une résiliation/réabonnement entrainera en principe un recâblage (et avec un peu de chance tu sera branché sur une autre prise, mais ce n'est pas forcément le cas, notamment si ton NRA est saturé. Mais il faudra payer les frais de résiliation et probablement passer 2/3 mois sans connexion avec un bazar administratif pas possible entre Free et FT.

Croux, le 23/04/2010 - 19:51

Effectivement l'adresse MAC apparait dans les adresses IPv6 mais uniquement dans certains cas d'autoconfiguration.

Pour info, l'adresse MAC est utilisée par défaut pour la construction de l'adresse IP en IPv6, quand on utilise l'autoconfiguration.
Toutefois, il existe d'autres méthodes pour la construire de manière aléatoire en autoconfiguration (cas par défaut sous Windows). On peut aussi définir arbitrairement l'adresse IP utilisée, comme en IPv4.

Sinon, effectivement, voir une société privée enregistrer les adresses MAC des connectés à un point d'accès, c'est loin d'être une bonne chose. Il y a une différence entre faire un relevé à des fins statistiques (par exemple pour compter le nombre d'AP ouverts/mal sécurisés/mieux sécurisés, etc) et jeter les données ensuite, et les relever pour les conserver pour on ne sait trop quelle raison.

Kouika, le 16/04/2010 - 16:20

Je ne comprends pas pourquoi TMG aurait la naïveté d'utiliser des IP fixes ? Pour mieux se faire repérer ?

Pour le moment, la seule chose dont on est sûr est que ces IPs appartiennent à TMG (via un whois). Ils les utilisent peut-être pour leur test grandeur nature (ils ne peuvent rien faire tant que les décrets n'ont pas étés publiés). Après, rien ne garantit qu'ils n'utilisent pas des FAI grands-publics pour avoir une connexion "banalisée" par la suite.