Discussion :

[Array]

Bonjour,

Je fais en ce moment un serveur qui envoie des "serial numbers" (un numéro unique d'identification, abrégé ici "uid") à un client afin de reconnaître ce même client à sa prochaine visite...

Le fait est que je SAIS quels IPs iront chercher ces uid (seule une liste d'IPs autorisés y auront accès) par conséquent je peux utiliser bloqeur d'autres tentatives venant d'autres addresses.

Cependant, je ne voudrais pas qu'un scénario particulier se produise:
une attaque visant le serveur, qui envoie un paquet "spoofé" (c'est à dire donc l'addresse de l'envoyeur a été modifiée dans l'entête du paquet) demandant une requête pour l'obtention d'un nouveau uid... en effet si cela se produisait, et que l'addresse corresponde à un des IPs autorisés, je pourrais bien me retrouver à gaspiller énormément de uids et même mon algorithme de génération pourrait potentiellement être découvert.
Il me faut donc empêcher cela.

Je me disais donc que le seul moyen d'être sûr que l'addresse distant soit bel et bien la bonne, je dois faire ces étapes
1- Réception d'un paquet
2- Envoie d'un paquet de confirmation à l'addresse distante
3- L'addresse distante réplique...
4- Réception du paquet de confirmation

Voici mes questions:
1- Est-ce que, lors de l'établissement d'une connection avec l'appel socket(), accept(), etc etc, ces étapes sont déjà faites d'avance (autrement dit est-ce que l'on est sûr de l'autheticité de l'addresse distante)?
2- Avez vous une meilleure idée, plus sécuritaire, afin de palier ce problème?

Merci beaucoup!

Cordialement,
Array

[gangsoleil]

Bonjour,

Lors de l'etablissement d'une connexion securisee, il y a plusieurs echanges qui sont faits - on parle par exemple de 3-way handshake.

Un paquet spoofe seul ne permet pas d'etablir une connexion, car ton serveur va repondre a l'adresse spoofee, pas a l'emetteur.

Ta seule crainte est le man-in-the-middle, et la, il est tres difficile de s'en premunir sans avoir un minimum de controle sur la machine cliente.

Au fait, j'espere bien que tes connexions sont securisees avec SSL ?

[Array]

Au fait, j'espere bien que tes connexions sont securisees avec SSL ?

Mhm en fait non :[]

Pour être franc, c'est une implémentation qui nécessite vraiment d'être rapide dans l'établissement des connexions et des réponses, Le,voie des données etc etc.
Donc... avant d'essayer je me disais... est-ce que SSL ralentit de beaucoup par rapport aux appels standards de l'OS?

Je suis peu connaissant en ce qui a trait aux connexions sécurisées.

[gangsoleil]

c'est une implémentation qui nécessite vraiment d'être rapide dans l'établissement des connexions et des réponses, L'envoie des données etc etc.
Donc... avant d'essayer je me disais... est-ce que SSL ralentit de beaucoup par rapport aux appels standards de l'OS?

Quel est le besoin :
Temps acceptable pour une connexion ?
Est-ce que la connexion peut rester ouverte en permanence, ou bien doit-elle etre refaite a chaque fois ?
Est-ce que l'utilisation CPU est genante (sur un micro-controlleur par exemple) ?
De quel niveau de securite avez-vous besoin ?

A mon avis, tu ne verras memem pas la difference en chiffrant les donnees ou non, pour peu que tu aies des serveurs et pas des terminaux mobiles - et encore.

[matafan]

Avec de l'ARP spoofing on peut tout à fait se faire passer pour autre machine.

Avec un serveur S et une machine pirate P voulant se faire passer pour un client légitime C, la machine P émet des réponses ARP qui disent "l'IP de C, elle correspond à mon adresse MAC". En plus de ça P met son interface en mode promiscuous.

P envoie à S un paquet en mettant l'adresse IP de C en adresse source. Quand S répond, il émet un requête ARP pour connaître l'adresse MAC correspondant à l'adresse IP de C. Il reçoit une des réponses ARP "pirates" émises en permanence par par P. S envoie donc un paquet destiné à C, avec l'IP destination de C, mais l'adresse MAC destination de P. P reçoit la réponse et fait ce qu'il veut avec.

[gangsoleil]

Pour l'ARP spoofing, il faut tout de meme etre sur le meme sous-reseau, donc c'est vite tres tres limitant (heureusement d'ailleurs).