dimanche, décembre 08, 2024
Nom d'utilisateur : Mot de passe :
[NEWS]
Envoyé par unreal
Pourquoi ce dossier ?

Il peut être parfois intéressant de sortir par un VPN. Par exemple pour contourner un blocage de site ou pour accéder à du contenu qui n'est pas encore disponible dans le pays où l'on habite. Le soucis c'est qu'utiliser un VPN implique généralement plusieurs choses :

- Installer un logiciel sur son ordinateur
- Envoyer inconditionnellement tout son trafic par le VPN à partir du moment où le client VPN est démarré
- Beaucoup de difficultés si l'on souhaite utiliser le VPN sur un appareil mobile, tel qu'un smartphone

La solution proposée dans ce dossier est de configurer le VPN sur un serveur (et non sur le client) et d'utiliser un proxy HTTP installé sur le même serveur pour communiquer avec le VPN. Le client peut alors sélectivement utiliser le proxy (par le bias d'un fichier .pac par exemple) pour router son trafic Web selon ses besoins.

Le schéma ci-dessous résume la architecture :

proxy_openvpn.png



Avant de commencer

Je vous propose quelques lectures en rapport avant de se lancer dans le vif du sujet :

- Policy routing avec Packet Filter
- Gérer multiples tables de routage avec setfib
- Article de Wikipedia sur le PAC
- La documentation officielle Packet Filter


Configuration requise

Pour réaliser ce projet, nous allons utiliser les applications et services suivants :

- Le service VPN TunnelBear qui se base sur OpenVPN ; vous pouvez utiliser le service de votre choix.
- FreeBSD 8.2 avec support multiples tables de routage (important !)
- Squid 3.1


Configuration

TunnelBear

Téléchargez et installez l'application proposée car elle vous permettra de créer un compte gratuit avec 500Mo de quota mensuel. Ils ont des abonnements payants si vous avez besoin de plus de 500Mo mensuel. Localisez les fichiers suivants et copiez-les sur le serveur dans /usr/local/etc/openvpn :

- tbearProd.ovpn
- ca.crt
- key.crt
- key.key

Démarrez la connexion VPN avec le client officiel sur le serveur souhaité et utilisez la commande netstat pour déterminer l'IP du serveur et son port (443 normalement).

Installez ensuite /usr/ports/security/openvpn en choisissant "PW_SAVE Interactive passwords may be read from a file". Créez un fichier /usr/local/etc/openvpn/password lisible uniquement par root avec votre login et mot de passe sur deux lignes.

Nous allons maintenant créer une configuration tunnelbear.conf à partir de tbearProd.ovpn. Le mien ressemble à ceci :

client
dev tun0
proto tcp
remote <ip serveur> <port serveur>
persist-key
persist-tun
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/key.crt
key /usr/local/etc/openvpn/key.key
ns-cert-type server
resolv-retry infinite
nobind
comp-lzo
verb 3
status /var/log/openvpn-status.log
log /var/log/openvpn.log
auth-user-pass /usr/local/etc/openvpn/password
ping 10
route-nopull


Configurez /etc/rc.conf pour activer OpenVPN :

# OpenVPN client
openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/usr/local/etc/openvpn/tunnelbear.conf"
openvpn_dir="/usr/local/etc/openvpn"


Enfin, démarrez la connexion VPN, et vérifiez avec ifconfig que vous parvenez à vous connecter :

# /usr/local/etc/rc.d/openvpn start
...
ifconfig tun0


Si le VPN démarre correctement, nous pouvons passer à la configuration du proxy Squid.

Squid

Installez /usr/ports/www/squid31 en prenant soin de désélectionner toutes les options pour alléger l'installation. Côté configuration, si vous ne voulez pas qu'on sache que vous surfez par un proxy, je vous conseille d'ajouter les directives suivantes dans votre configuration :

via off
forwarded_for delete


Nous n'allons pas démarrer Squid de la façon habituelle (en l'activant dans rc.conf) car nous avons besoin qu'il démarre en utilisant une table de routage alternative. Pour ce faire, nous allons utiliser un script rc spécifique qui aura comme rôle de configurer les routes et démarrer Squid :

/usr/local/etc/rc.d/setfibroutes
#!/bin/sh
#
#
# PROVIDE: setfibroutes
# REQUIRE: LOGIN openvpn
#

. /etc/rc.subr

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin

GWROUTE="`ifconfig tun0 inet | grep inet | awk '{ print $4; }'`"

echo -n "Waiting for network"
COUNT=0
while [ ! "$GWROUTE" ] && [ $COUNT -lt 50 ]; do
        sleep 1
        echo -n "."
        GWROUTE="`ifconfig tun0 inet | grep inet | awk '{ print $4; }'`"
        COUNT=`expr $COUNT + 1`
done


[ ! $GWROUTE ] && echo " Failed." && exit 1

echo " OK."

echo "Setting setfib routes..."

/usr/sbin/setfib 1 route delete -net 0.0.0.0
/usr/sbin/setfib 1 route add -net 0.0.0.0 $GWROUTE

echo "Starting Squid..."

/usr/sbin/setfib 1 /usr/local/etc/rc.d/squid onestart


Redémarrez le serveur (si possible) pour vérifier que tous les services (OpenVPN et Squid) démarrent correctement.

Utilisation reply-to avec PF

Si vous tentez d'utiliser le Squid à ce stade, vous allez constater qu'il ne fonctionne pas ; en effet il reçoit bien les requêtes sur l'interface publique re0 du serveur, mais il répond vers tun0, ce qui ne peut pas fonctionner. Pour éviter ce soucis, nous allons utiliser une règle très utile de PF :

/etc/pf.conf

# Interface definitions
ethif0 = "re0"
ethgw0 = "1.2.3.4"

table <allowedproxy> {         1.1.2.3, \
                                2.3.4.5, \
                                3.4.5.6 }

# Proxy must reply to re0 interface
pass in quick on $ethif0 reply-to ($ethif0 $ethgw0) inet proto tcp from <allowedproxy> to any port 22222 keep state
block drop in quick on $ethif0 inet proto tcp from any to any port 22222


Note : 22222 est le port d'écoute du proxy Squid.

Relancez PF et normalement tout fonctionne maintenant. Squid répond bien sur l'interface publique pour discuter avec le client, et utilise l'interface tun0 pour sortir.


Conclusion

J'espère que vous avez aimé ce petit dossier et n'hésitez pas à faire des remarques si vous en avez, bien sûr.

Posté le 19/11/11 à 15:20 - 0 Commentaires...

[NEWS]
Envoyé par unreal
Nous avons déjà évoqué certaines fonctionnalités avancées de PF, par exemple la protection anti DOS et le filtrage IPv6. Dans cet article, nous allons explorer les possibilités de policy routing ou politique de routage en français. Ce type de configuration est nécessaire quand le routeur dispose de plusieurs accès Internet et que vous souhaitez contrôler les flux.

Ci-dessous un schéma de principe :

dossier_policy_routing.png


Plusieurs remarques importantes :

- le routeur, installé en FreeBSD 8.1 x64, offre déjà les fonctionnalités de NAT/FW
- vlan1 et tun1 ont des IP publiques statiques (mais seulement vlan1 a une route par défaut)
- le laptop et serveur ont le routeur comme gw vers Internet


Gestion des flux entrants

Pour commencer, nous allons configurer PF pour que l'interface tun1 puisse répondre à l'ICMP echoreq (ping) et que le serveur Web soit accessible depuis les deux IP publiques. Le routeur héberge un serveur SSH sur port 2222, nous allons autoriser les connexions depuis tun1.

Pour ce faire, nous allons utiliser l'option reply-to qui permet de forcer le chemin de retour ailleurs que par la route par défaut.

pf.conf
# Definitions d'interfaces
def_if = "em0"
nc_if = "vlan1"
loopback_if = "lo0"
pppoe_if = "tun1"

# Definitions IP et port
pppoe_gw="111.222.333.1"
macmini = "192.168.1.1"
macmini_web_ports = "{ 80, 443 }"

# Translations de port
rdr on $nc_if proto tcp from any to any port $macmini_web_ports -> $macmini
rdr on $pppoe_if proto tcp from any to any port $macmini_web_ports -> $macmini

# Connexions entrantes
# Tout refuser par défaut
block in on $nc_if all
block in on $pppoe_if all
# ICMP
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto icmp all icmp-type echoreq
# SSH
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto tcp from any to any port 2222 keep state
# Web
pass in on $nc_if proto tcp from any to any port $macmini_web_ports keep state
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto tcp from any to any port $macmini_web_ports keep state



Cet exemple est assez explicite et ne contient que la partie qui nous intéresse, à savoir le routage des flux. On peut noter que l'adresse de la passerelle de l'interface pppoe_gw est configurée statiquement, car elle est utilisée par l'option reply-to pour router les paquets.

Un autre cas de figure qui est intéressant de gérer c'est les flux sortants.

Gestion de flux sortants

Le but cette fois-ci sera de contrôler par quel lien passera le traffic (naté) sortant.

Ceci peut présenter plusieurs intérêts :

- router des flux sensibles (SSH, VoIP, jeux en ligne) via un lien dédié
- dédier un lien à un utilisateur ou à un groupe d'utilisateurs
- réduire les coûts en routant les flux non critiques via un lien bon marché
- améliorer la performance en profitant des accords de peering de plusieurs opérateurs, en routant par exemple vers Google via l'opérateur qui a la meilleure connectivité vers Google

Ainsi de suite.

Ceci se fait avec l'option route-to, comme dans l'exemple ci-dessous :

pppoe_if = "tun1"
nc_if = "vlan1"
def_if = "em0"
internal_net = "192.168.10.0/24"
pppoe_gw="178.32.37.1"

# NAT
# Exception du routage de flux
nat on $pppoe_if proto tcp from $internal_net to myip.dk port 80 -> ($pppoe_if)
# Route par defaut
nat on $nc_if from $internal_net to any -> ($nc_if)

# Exception du routage de flux
pass in on $def_if route-to ($pppoe_if $pppoe_gw) inet proto tcp from $internal_net to myip.dk port 80 keep state


Cet exemple se contente de rerouter les flux vers http://myip.dk/ via tun1, alors que la passerelle par défaut est vlan1.

On peut formuler plusieurs remarques par rapport au fonctionnement de cet exemple :

- Le re-routage des flux sortants se fait en deux étapes : routage vers la bonne interface ($pppoe_if), puis réécriture de l'IP source.
- La règle de pass in est appliquée avant le NAT, qu'on applique donc bien sur l'interface de sortie souhaitée $pppoe_if.
- Les règles de NAT sont évaluées de haut en bas. La première règle qui correspond est appliquée ; il faut donc mettre la directive par défaut en bas, et les exceptions en haut.

Conclusion

PF est un outil très flexible pour réaliser de la politique de routage statiques grâce aux options reply-to et route-to.

Historique :
- 20110216 : première version
- 20110222 : refonte de la partie sur les flux sortants

Posté le 16/02/11 à 10:52 - 0 Commentaires...

[NEWS]
Envoyé par unreal
A l'heure où j'écris ces lignes, dans un peu plus de 400 jours les reserves de blocs IPv4 seront épuisés. Alors que beaucoup d'opérateurs disposent de réseaux IPv6 au niveau des backbones, la connectivité native tarde à arriver vers les extrêmités du réseau, c'est-à-dire chez les clients. Le déploiement limité d'IPv6 native n'encourage pas les fournisseurs de contenus à migrer leurs services en IPv6 du fait d'un intérêt limité. Le tunnelbroker apparaît alors comme une solution de transition peu coûteuse et facile à déployer.

Dans ce dossier, nous allons configurer une machine FreeBSD avec un tunnelbroker pour offrir une connectivité IPv6 sécurisée vers des machines d'un réseau local.

Typologie

Nous allons travailler avec une machine FreeBSD 8.0 ayant une seule carte réseau physique (em0), reliée sur le réseau local. La connectivité Internet IPv4 arrive par une interface virtuelle (vlan1), dont l'interface parent est em0.

Configuration d'un tunnel basique

Plusieurs sociétés offrent de la connectivité IPv6 tunnelisée. Nous allons utiliser le service Tunnelbroker de Hurricane Electric qui propose des options intéressantes comme la délégation RDNS ou l'allocation de plusieurs subnets.

Creez un compte sur le site de HE.

Séléctionnez ensuite "Create Regular Tunnel" et saisissez votre IPv4 publique (fixe de préférence). Vous allez pouvoir créer un /64 routé et générer la configuration pour divers systèmes d'exploitation, dont FreeBSD. Dans cet exemple nous allons supposer que votre IP publique est 85.1.2.3 et que votre /64 alloué est 2001:11:22:33::/64.

Cela nous donne :

ifconfig gif0 create
ifconfig gif0 tunnel 85.1.2.3 216.66.84.42
ifconfig gif0 inet6 2001:11:22:33::2 2001:11:22:33::1 prefixlen 128
route -n add -inet6 default 2001:11:22:33::1
ifconfig gif0 up


Ifconfig permet de vérifier que le tunnel a bien été créé :

# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 85.1.2.3 --> 216.66.84.42
        inet6 fe80::219:d1ff:fe7a:7437%gif0 prefixlen 64 scopeid 0x6
        inet6 2001:11:22:33::2 prefixlen 64
        options=1<ACCEPT_REV_ETHIP_VER>


Utilisez ensuite la commande ping6 pour vérifier que le tunnel fonctionne :

# ping6 -c 1 www.free.fr
PING6(56=40+8+8 bytes) 2001:11:22:33::2 --> 2a01:e0c:1:1599::1
16 bytes from 2a01:e0c:1:1599::1, icmp_seq=0 hlim=55 time=51.311 ms

--- http://www.free.fr ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 51.311/51.311/51.311/0.000 ms


Si cela ne fonctionne pas et que vous avez un firewall sur la passerelle, il se peut qu'il soit configuré pour bloquer le traffic tunnelé. Voici un exemple de configuration PF pour autoriser le traffic du tunnel :

# Tunnel IPv6
pass out on $nc_if inet proto 41 from any to 216.66.84.42 keep state
pass in on $nc_if inet proto 41 from 216.66.84.42 to any keep state


En supposant que cette partie fonctionne, nous allons maintenant voir comment étendre cette connectivité IPv6 au réseau local.

Routage d'un subnet

Retournez dans l'interface Tunnelbroker et demandez l'allocation du /48 routé ; nous allons utiliser un subnet /64 de ce /48 pour connecter notre réseau local. Dans cet exemple nous supposons que le /48 alloué est 2001:44:55::/48 et que le subnet /64 "LAN" est 2001:44:55:1::/64.

Vous allez configurer une IP du subnet LAN sur l'interface em0 :

ifconfig em0 inet6 2001:44:55:1::1 prefixlen 64


Pour activer le routage entre le subnet "LAN" et le subnet "WAN", il convient d'activer le forwarding IP :

sysctl -w net.inet6.ip6.forwarding=1


En configurant une machine du réseau local en IPv6 manuelle, 2001:44:55:1::2 par exemple, vous devriez pouvoir constater le bon fonctionnement de l'ensemble :

$ traceroute6 -n www.free.fr
traceroute6 to http://www.free.fr (2a01:e0c:1:1599::1) from 2001:44:55:1::2, 64 hops max, 12 byte packets
1 2001:44:55:1::1 0.366 ms 0.301 ms 0.285 ms
2 2001:11:22:33::1 33.619 ms 27.855 ms 29.953 ms
3 2001:470:0:7b::1 27.837 ms 29.885 ms 28.257 ms
...


Nous voyons ici l'IP de notre routeur (2001:44:55:1::1), puis l'IP de l'endpoint du tunnel (2001:11:22:33::1).

Filtrer le traffic IPv6 avec PF

A ce stade vous avez normalement un réseau IPv6 fonctionnel, mais non sécurisé dans la mesure où les IP sont publiques et le traffic n'est pas du tout filtré, juste routé. Nous allons utiliser PF pour filtrer le traffic directement au niveau du routeur. Ma configuration PF contient beaucoup de règles ; par soucis de lisibilité les règles ici ne concernent que le tunnel IPv6 :


ipv6_if = "gif0"
macmini_v6 = "2001:44:55:1::2"
macmini_web_ports = "{ 80, 443 }"
ext_server = "2a02:1:2:3::4"

# <IPv6>
# Block all by default
block on $ipv6_if all

# ICMP.
pass in on $ipv6_if proto icmp6 all keep state
pass out on $ipv6_if proto icmp6 all keep state

# Inward connections.
pass in on $ipv6_if proto tcp from any to $macmini_v6 \
                        port $macmini_web_ports flags S/SA keep state \
                        (max-src-conn-rate 100/5)
# SSH
pass in on $ipv6_if inet6 proto tcp from $ext_server to any port 22 keep state

# Outward connections.
pass out on $ipv6_if inet6 proto tcp all keep state
pass out on $ipv6_if inet6 proto udp all keep state
# </IPv6>


Cette configuration bloque tout le traffic entrant sauf ICMP, Web vers "macmini_v6" et ssh de "ext_server", et autorise ICMP, TCP et UDP sortant. Elle s'applique à toutes les machines en IPv6.

Autoconf

Une des fonctionnalités très pratiques de l'IPv6 est l'autoconf qui permet sans DHCP aux machines d'obtenir des IP statiques grâce à la MAC de la carte réseau. Sous FreeBSD, le router advertisement daemon ou rtadvd permet la fonctionnalité d'autoconf. Pour l'utiliser, il faut éditer rc.conf et rtadvd.conf :

/etc/rc.conf
rtadvd_enable="YES"
rtadvd_interfaces="em0"


/etc/rtadvd.conf
em0:\
    :addrs#1:addr="2001:44:55:1::": prefixlen#64:tc=ether:


Démarrez rtadvd pour profiter de l'autoconf IPv6.

Démarrage automatique des services

Pour finir, nous allons configurer l'auto démarrage des services dans rc.conf :

rc.conf
# Network
ifconfig_em0="inet 192.168.100.1 netmask 255.255.255.0"
cloned_interfaces="vlan0 vlan1"
ifconfig_vlan0="vlan 2 vlandev em0"
ifconfig_vlan1="DHCP vlan 4 vlandev em0"

# IPv6
ipv6_enable="YES"
ipv6_gateway_enable="YES"
ipv6_network_interfaces="lo0 em0 gif0"
gif_interfaces="gif0"
gifconfig_gif0="85.1.2.3 216.66.84.42"
ipv6_ifconfig_gif0="2001:11:22:33::2/64"
ipv6_ifconfig_em0="2001:44:55:1::1 prefixlen 64"
ipv6_defaultrouter="-interface gif0"
rtadvd_enable="YES"
rtadvd_interfaces="em0"

# PF
pf_enable="YES"                 # Enable PF (load module if required)
pf_rules="/etc/pf.conf"         # rules definition file for pf
pf_flags=""                     # additional flags for pfctl startup
pflog_enable="YES"             # start pflogd(8)
pflog_logfile="/var/log/pflog" # where pflogd should store the logfile
pflog_flags=""                 # additional flags for pflogd startup


Au prochain reboot de la machine, les services devraient monter automatiquement.

Conclusion

Avec un tunnelbroker, il est plutôt facile de déployer un réseau IPv6 de transition, en attendant un déploiement plus généralisé d'IPv6 native.

Historique

- 19 juin 2010 : version initiale

Posté le 19/06/10 à 12:37 - 0 Commentaires...

[NEWS]
Envoyé par unreal
Free propose plusieurs méthodes pour relier le boîtier ADSL et le boîtier TV HD : Wi-Fi, Freeplugs ou câble Ethernet directement. Dans cet article, nous allons voir comment transporter le flux TV sur un réseau Ethernet existant composé de plusieurs switchs.

Typologie

Le schéma suivant illustre le raccordement entre les différents éléments :

typologie.png


Fonctionnement

Les 4 ports du miniswitch + le port jaune "boîtier TV" forment un mini switch 5 ports ; nous pouvons donc utiliser un port du switch 4 ports pour recevoir le flux TV. Niveau réseau, Internet est accessible sans VLAN, alors que le contenu TV est transmis sur le VLAN 100, avec paquets taggés. Il nous suffit donc d'acheminer ce VLAN à travers le réseau.

Configuration

La configuration est assez simple en CLI habituel Cisco. Je suppose ici que la Freebox ADSL est relié sur le port 1, que l'uplink vers le switch non manageable se fait sur le port 3, que le VLAN "LAN" est 1 (vlan natif) et que le VLAN "internet" est 2.

c2960g.localdomain#conf t
Enter configuration commands, one per line. End with CNTL/Z.
c2960g.localdomain(config)#vlan 100
c2960g.localdomain(config-vlan)#name FreeBoxTV
c2960g.localdomain(config-vlan)#exit
c2960g.localdomain(config)#interface GigabitEthernet0/1
c2960g.localdomain(config-if)#description Freebox
c2960g.localdomain(config-if)#switchport trunk native vlan 2
c2960g.localdomain(config-if)#switchport trunk allowed vlan 2,100
c2960g.localdomain(config-if)#switchport mode trunk
c2960g.localdomain(config-if)#exit
c2960g.localdomain(config)#interface GigabitEthernet0/3
c2960g.localdomain(config-if)#description UplinkBureau
c2960g.localdomain(config-if)#switchport trunk allowed vlan 1,100
c2960g.localdomain(config-if)#switchport mode trunk
c2960g.localdomain(config-if)#exit
c2960g.localdomain(config)#exit
c2960g.localdomain#wr me


Démarrez maintenant le boîtier TV, qui devrait passer l'étape "Réseau" sans soucis.

Conclusion

Il est tout à fait possible de se passer des freeplugs !

Posté le 07/05/10 à 11:02 - Commentaires désactivés

[NEWS]
Envoyé par unreal
Pourquoi ?

Sécuriser un site par connexion SSL apporte deux choses :
- cela empêche qu'on puisse intercepter et décoder une transmission entre le navigateur et le serveur Web
- cela garantit que le site visité est bien celui qu'il prétend être

Par exemple, une injection DNS (DNS poisoning) pourrait amener le navigateur sur un serveur différent, mais cela provoquerait un avertissement au niveau du navigateur parce qu'il est impossible de connaître la clef privée du serveur authentique.

Fonctionnement de la persistance HTTP

Comme le HTTP est stateless, Netscape a inventé les cookies pour stocker des informations persistantes entre plusieurs accès successifs. Voici comment cela fonctionne :

- Le navigateur effectue une première requête HTTP (GET ou POST par exemple) sur le serveur Web
- Le serveur retourne un cookie dans les entêtes HTTP, qu'il sauvegarde localement
- Le navigateur sauvegarde également ce cookie
- Aux connexions suivantes, le navigateur transmet son cookie
- Le serveur reconnaît le cookie, permettant d'identifier le navigateur

Le serveur Web a la possibilité de stocker diverses informations dans le cookie, comme le nom d'utilisateur, la date de dernière visite, ainsi de suite. Les informations contenues dans la session sont sécurisées parce qu'elles sont conservées localement sur le serveur ; le navigateur ne peut modifier les informations du cookie de session. Par contre, si le cookie est intercepté pendant sa transmission, une personne malveillante pourrait se faire passer pour l'utilisateur légitime et modifier son mot de passe ou visualiser les informations de son compte, par exemple.

Les pièges à éviter

Le problème réside dans la possibilité de pouvoir accéder simultanément au serveur Web en HTTP normal et SSL. En effet, on peut identifier les deux cas suivants qui pourraient entraîner la perte du cookie de session :

- L'application délivre en HTTP non sécurisé le cookie de session initial

Le cookie restera valide même si la suite de la navigation se fait par une connexion sécurisée.

- Le navigateur accède en HTTP non sécurisé après une navigation sécurisée

Le navigateur va alors transmettre son cookie, précédemment protégé, en clair sur le réseau.

Que faire ?

Il convient de suivre les consignes suivantes pour sécuriser la transmission du cookie de session :

- Empêcher l'application d'émettre son cookie en HTTP non sécurisé

On peut utiliser mod_rewrite pour imposer une redirection http:// vers https:// au niveau du serveur Web. De cette manière, l'application hébergée n'a jamais la possibilité de transmettre son cookie de façon non sécurisée.

- Envoyer ses cookies avec le flag secure

Ce flag informe le navigateur qu'il ne doit jamais divulguer son cookie si la connexion n'est pas sécurisée.

En PHP, on peut procéder comme ceci :

ini_set('session.cookie_secure',true);
[...]
session_start();
[...]


Attention : il est important de respecter l'ordre des commandes dans l'exemple précédent ; la fonction ini_set() doit d'exécuter avant session_start().

Conclusion

Assez simple : il ne faut pas se contenter d'activer mod_ssl pour sécuriser un site Web !

Historique

- Version intiale : 25/12/2009

Posté le 25/12/09 à 00:16 - 0 Commentaires...

2 pages... [1-5][6-8]