Proxy HTTPs "decodeur"

Alain Montfranc wrote:

l'idéal serait qu'il re-chiffre la transaction
proxy=>cliet avec son propre certificat ou avec un certificat "bidon"
crée à la volée avec une CA locale qui pourrait etre deployée sur les
postes clients.

Humm, même si c'est possible, cela génèrera un certificat "bidon" de
manière systématique, ce qui n'est pas très bon: cela habitue les
utilisateurs à passer outre les alertes du type "attention, le
certificat n'a pas été signé par une autorité reconnue", ce qui risque
de les faire tomber dans n'importe quelle attaque type fishing à
l'avenir. Déja que la plupart des utilisateurs ne font pas attention à
ces alertes, accentuer ce problème de sécurité ne me parait pas en
valoir la chandelle.
Car, a la base, vous réalisiez une attaque type "man-in-the-middle" sur
votre propre proxy :p

Bon, la solution serait de génerer une pseudo-aurotité, de signer les
certificats avec, et d'injecter la signature de cette autorité sur tous
les postes clients. Un poil lourdingue à déployer amha.

Mettez des ACL type "deny all" avec exceptions, et une page "accès
refusé" permettant facilement d'ajouter des sites https, du genre "Si
vous pensez que ce site vaut le coup d'être autorisé, jettez-moi un
mail: <mailto:dupont@exemple.com>")

"Alain Montfranc" <alain-news.wanadoo.fr@montfranc.com> a écrit dans le
message de news:mn.2c4a7d561b1baaac.15643@montfranc.com...

Bonjour

Pour des raisons de sécurité(*), je desire supprimer l'acces aux sites
HTTPS sauf site reconnus d'utilité travaillesque. Cependant pour ne pas
tout couper brutalement, j'envisage la mise en place d'un proxy qui
réaliserait le décodage HTTPs en s'interposant en client HTTPs.
eventuellement, l'idéal serait qu'il re-chiffre la transaction
proxy=>cliet avec son propre certificat ou avec un certificat "bidon"
crée à la volée avec une CA locale qui pourrait etre deployée sur les
postes clients.

Cela existe t'il deja ? En particulier sur du squid ?

Je ne sais pas pour le rechiffrage, mais squid propose en standard
l'authentification (histoire de savoir qui fait quoi) mais aussi les
blacklist ou whiteliste à base de regexp.

Alain Montfranc wrote:

Cela existe t'il deja ? En particulier sur du squid ?

Pour répondre à la question (ma précédente réponse était un peu à côté
de la plaque - mais c'est pour tester l'équipe de modération :p), je ne
pense pas que ce soit possible avec Squid (en tout cas la version que
j'ai - 2.5.9), car clientProcessRequest() attaque direct en SSL sans
passer par autre chose (au hasard, un callback quelconque)

src/client_side.c:
..
if (r->method == METHOD_CONNECT) {
http->log_type = LOG_TCP_MISS;
sslStart(http, &http->out.size, &http->al.http.code);
...

D'un autre côté, si on doit faire les choses gorement, autant y aller
franchement, dans la mesure où un proxy additionnel (entre le vrai proxy
et les clients) n'est pas très complexe à écrire (parser la ligne
"CONNECT xxx:443 HTTP/1.1"). Enfin, le proxy lui même n'est pas
difficule, la partie génération de certificats un peu plus technique.

"Alain Montfranc" <alain-news.wanadoo.fr@montfranc.com> a écrit dans le
message de news: mn.2c4a7d561b1baaac.15643@montfranc.com...

Bonjour

Pour des raisons de sécurité(*), je desire supprimer l'acces aux sites
HTTPS sauf site reconnus d'utilité travaillesque. Cependant pour ne pas
tout couper brutalement, j'envisage la mise en place d'un proxy qui
réaliserait le décodage HTTPs en s'interposant en client HTTPs.
eventuellement, l'idéal serait qu'il re-chiffre la transaction
proxy=>cliet avec son propre certificat ou avec un certificat "bidon" crée
à la volée avec une CA locale qui pourrait etre deployée sur les postes
clients.

Cela existe t'il deja ? En particulier sur du squid ?

Bonjour,

cet outil semble répondre à ton besoin.
http://www.vroyer.org/sslstripper/index.html
Il est développé à la base pour faire du filtrage antivirus (entre autres)
sur les flux HTTPS.

Dans ce cas, juridiquement, est il nécessaire de préciser dans la charte
informatique que les communications chiffrées peuvent être déchiffrées et
analysées ?

Cela peut aussi engendrer une mauvaise réaction des utilisateurs qui ne
souhaitent peut être pas que le login/pass de leur compte en banque passe ou
soit stockés en clair sur un serveur de leur société. Mais bon, certains
répondront qu'ils n'ont pas à aller sur ces sites pendant leurs heures de
travail ;)

Merci

De rien

Romain

OoO Pendant le repas du dimanche 05 juin 2005, vers 19:15, Xavier
Roche <xroche@free.fr.NOSPAM.invalid> disait:

Humm, même si c'est possible, cela génèrera un certificat "bidon" de
manière systématique, ce qui n'est pas très bon: cela habitue les
utilisateurs à passer outre les alertes du type "attention, le
certificat n'a pas été signé par une autorité reconnue", ce qui risque
de les faire tomber dans n'importe quelle attaque type fishing à
l'avenir. Déja que la plupart des utilisateurs ne font pas attention à
ces alertes, accentuer ce problème de sécurité ne me parait pas en
valoir la chandelle.
Car, a la base, vous réalisiez une attaque type "man-in-the-middle" sur
votre propre proxy :p

Bon, la solution serait de génerer une pseudo-aurotité, de signer les
certificats avec, et d'injecter la signature de cette autorité sur tous
les postes clients. Un poil lourdingue à déployer amha.

Tu aurais alors l'effet inverse que celui que tu décris : tous les
sites seront valides.
--
BOFH excuse #305:
IRQ-problems with the Un-Interruptable-Power-Supply

Il se trouve que Xavier Roche a formulé :

Alain Montfranc wrote:

l'idéal serait qu'il re-chiffre la transaction proxy=>cliet avec son propre
certificat ou avec un certificat "bidon" crée à la volée avec une CA locale
qui pourrait etre deployée sur les postes clients.

Bon, la solution serait de génerer une pseudo-aurotité, de signer les
certificats avec, et d'injecter la signature de cette autorité sur tous les
postes clients. Un poil lourdingue à déployer amha.

C'est exactement mon idée...

Mettez des ACL type "deny all" avec exceptions, et une page "accès refusé"
permettant facilement d'ajouter des sites https, du genre "Si vous pensez que
ce site vaut le coup d'être autorisé, jettez-moi un mail:
<mailto:dupont@exemple.com>")

c'est justement ce que je voudrais eviter... C'est deja super lourd
avec des exclusions, alors avec un deny all par défaut :-(

Le Sun, 05 Jun 2005 16:29:41 +0000, Alain Montfranc a écrit :

Pour des raisons de sécurité(*), je desire supprimer l'acces aux sites
HTTPS sauf site reconnus d'utilité travaillesque. Cependant pour ne pas
tout couper brutalement, j'envisage la mise en place d'un proxy qui
réaliserait le décodage HTTPs en s'interposant en client HTTPs.
eventuellement

Il y a un soucis plus fonctionnel sur lequel il faudra sérieusement se
pencher, à savoir la validation des certificats, aussi bien côté client
que serveur, puisque ton proxy est entre les deux.

Personnellement, ça me chiffonnerait un peu de savoir que c'est une
machine qui contrôle les certificats serveur à ma place...


--
printk("HPFS: Grrrr... Kernel memory corrupted ... going on, but
it'll crash very soon :-(n");
2.4.3 linux/fs/hpfs/super.c

Cedric Blancher a pensé très fort :

Pour des raisons de sécurité(*), je desire supprimer l'acces aux sites
HTTPS sauf site reconnus d'utilité travaillesque. Cependant pour ne pas
tout couper brutalement, j'envisage la mise en place d'un proxy qui
réaliserait le décodage HTTPs en s'interposant en client HTTPs.
eventuellement

Il y a un soucis plus fonctionnel sur lequel il faudra sérieusement se
pencher, à savoir la validation des certificats, aussi bien côté client
que serveur, puisque ton proxy est entre les deux.

Je vois les cas suivants coté serveurs :
- certificat expiré : on en recré un avec les mêmes dates => mêmes
symptomes
- CA non reconnu, on fait un certificat avec une CA locale non déployée
=> memes symptomes
- certificat ne correspondant pas au nom du site : on recrée pareil =>
memes symptomes

j'en ai loupé ?

Coté client, je vois moins.

Personnellement, ça me chiffonnerait un peu de savoir que c'est une
machine qui contrôle les certificats serveur à ma place...

Il y aurait deux types de sites :
- ceux officielement autorisés pour lequel la transaction serait HTTPs
de bout en bout sans interruption
- les site "tolérés" que personne n'est obligé de consulter depuis le
bureau...

;-)

Le Mon, 06 Jun 2005 16:38:52 +0000, Alain Montfranc a écrit :

Je vois les cas suivants coté serveurs :
- certificat expiré : on en recré un avec les mêmes dates => mêmes
symptomes

Non, parce que le certificat que tu présentes au client est celui de ton
proxy, et qu'il a ses propres dates de validités. Si tu ne changes rien,
tu passes d'un certificat expiré (celui du serveur) a un certificat en
cours de validité (le tien).
Tu dois donc détecté l'erreur et la retourner au client, typiquement
sous la forme d'une page HTML.

- CA non reconnu, on fait un certificat avec une CA locale non
déployée => memes symptomes

Tu te compliques la vie pour rien... Pourquoi continuer la connexion si tu
fais tout pour ne pas la faire aboutir derrière ? Je renverrai une page
HTML faisant état de l'erreur SSL.

- certificat ne correspondant pas au nom du site : on recrée pareil =>
memes symptomes

Exact.

j'en ai loupé ?

La signature du certificat par l'AC présentée n'est pas valide (c'est un
fake grossier).

Coté client, je vois moins.

Authentification au site par certificat client, qui ne marchera pas
puisque c'est ton proxy qui va présenter son certificat client.

Il y aurait deux types de sites :
- ceux officielement autorisés pour lequel la transaction serait HTTPs
de bout en bout sans interruption

Pour ceux-ci, tu peux t'assurer qu'ils sont bien supportés correctement
par ton système.

- les site "tolérés" que personne n'est obligé de consulter depuis le
bureau...

Pour cela (et ceux au-dessous au cas où), tu as besoin d'avoir un
mécanisme pour pousser les erreurs SSL au client, et, selon la politique
que tu mettras en place, les laisser éventuellement les outrepasser.
Genre en page HTML qui dit "y'a eu une erreur SSL, la voici, ça peut
vouloir dire ça", et éventuellement après "voulez-vous vous faire
pirater quand même [<h1><b>NON</b></h1>|<h6>oui</h6>]".


--
Quand tu utilise Windaube, y'a marqué 'ceci peut prendre quelques
minutes' et parfois ca prend 4/5 heures, cela demontre bien une théorie
d'Enchtein : "tout est relatif" :)
-+- RL sur debian-french : "connaître relativement peu Einstein" -+-

Cedric Blancher a émis l'idée suivante :

Je vois les cas suivants coté serveurs :
- certificat expiré : on en recré un avec les mêmes dates => mêmes
symptomes

Non, parce que le certificat que tu présentes au client est celui de ton
proxy, et qu'il a ses propres dates de validités. Si tu ne changes rien,
tu passes d'un certificat expiré (celui du serveur) a un certificat en
cours de validité (le tien).

L'idée était de recréer un certificat présentant les mêmes
caractéristiques que celui du site original, mais avec une CA
différente -locale)

Tu dois donc détecté l'erreur et la retourner au client, typiquement
sous la forme d'une page HTML.

- CA non reconnu, on fait un certificat avec une CA locale non
déployée => memes symptomes

Tu te compliques la vie pour rien... Pourquoi continuer la connexion si tu
fais tout pour ne pas la faire aboutir derrière ? Je renverrai une page
HTML faisant état de l'erreur SSL.

pourquoi ? Une CA n'ayant pas payé Microsoft peut tout de même être
justifiée (exemple : sites de test, page de back office, etc...)

- certificat ne correspondant pas au nom du site : on recrée pareil =>
memes symptomes

Exact.

j'en ai loupé ?

La signature du certificat par l'AC présentée n'est pas valide (c'est un
fake grossier).

;-)