Voila j'ai une application Web accessible par https et mot de passe
(applicatif)
A cause d'un bug du code de l' application , elle ne comprend pas
l'authentification par certif SSL et mot de passe de compte Apache.
On ne peut changer le code de l'application.
Et donc , j'aimerais trouver une solution pour qu'au moins
l'authentification par certif SSL me soit demandee lorsque je me connecte en
https a cette appli Web , et ceci avant l'authentification par mot de passe
applicatif
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Razny
Le Sun, 24 Jul 2005 09:01:24 +0000, Yves a écrit :
Voila j'ai une application Web accessible par https et mot de passe (applicatif)
Deux choses distinctes donc.
A cause d'un bug du code de l' application
Si une appli est buggée dès le départ pour une chose aussi importante que du contrôle d'accès c'est poubelle... Mais bon, on va dire que dans ton cas et dans le monde réel il y a obligation d'employer ce bidule.
, elle ne comprend pas l'authentification par certif SSL et mot de passe de compte Apache.
Pardon? Qu'est-ce qu'un compte Apache? Je connais le compte sous lequel tourne Apache (plus précisement l'user et le group, pour le site concerné).
Il y a aussi potentiellement des comptes utilisateurs sur le serveur...
Ne confonds tu pas SSL (avec ou sans échange de certif utilisateur) et login sous ton appli?
On ne peut changer le code de l'application.
Deuxième observation sur l'appli : en supposant qu'elle soit buggée au point de mal gérer les logins (j'ai quand même plutôt un doute quand à ta façon de gérer Apache et l'appli) et que soit tu ne peux exiger un correctif, soit le créateur n'existe plus, tu mets ton système en danger en ne choississant pas une autre appli. Exposer une merde *applicative* sur le web ce n'est pas ce qu'on peut rêver de mieux en sécu.
Et donc , j'aimerais trouver une solution pour qu'au moins l'authentification par certif SSL me soit demandee lorsque je me connecte en https a cette appli Web , et ceci avant l'authentification par mot de passe applicatif
Dans ton cas un rtfm est, amha, parfaitement applicable :(
Et un coup de google-like doit te permettre de trouver un équivalent français ou au pire une traduction automatique approximative[1]
(j'espere que je ne vous embrouille pas :-)
J'ai bien peur que ce soit toi qui t'embrouille tout seul, faute d'avoir cherché un minimum les bases de l'échange de certif TLS/SSL :-/
Parce que SSL c'est bien, mais si on ne fait pas l'effort de s'impliquer un peu le gain en sécurité risque fort d'être théorique.
Accessoirement si tu génère des certifs user, as tu pensé, *avant de mettre le bouzin en place* à ce que tu dois faire si un certif est supposé compromis? (indice : crl, gestion applicative directe ...)
Comment faire ? merci de votre aide
En commençant par lire le lien avant de surfer un peu pour continuer?
Attention, ainsi que ça a déjà été plusieurs fois indiqué ici ou sur fr.misc.cryptologie la difficulté de mise en place d'une PKI ne tiens pas aux outils mais à la gestion du bidule.
Eric
[1] Vraiment parce qu'on est sur un groupe francophone, parce que les traductions approximatives c'est franchement à éviter en sécu! J'ai la flemme de cherche mais je pense que tu devrais trouver ton bonheur directement dans notre langue :)
Le Sun, 24 Jul 2005 09:01:24 +0000, Yves a écrit :
Voila j'ai une application Web accessible par https et mot de passe
(applicatif)
Deux choses distinctes donc.
A cause d'un bug du code de l' application
Si une appli est buggée dès le départ pour une chose aussi importante
que du contrôle d'accès c'est poubelle... Mais bon, on va dire que dans
ton cas et dans le monde réel il y a obligation d'employer ce bidule.
, elle ne comprend pas
l'authentification par certif SSL et mot de passe de compte Apache.
Pardon?
Qu'est-ce qu'un compte Apache?
Je connais le compte sous lequel tourne Apache (plus précisement l'user
et le group, pour le site concerné).
Il y a aussi potentiellement des comptes utilisateurs sur le serveur...
Ne confonds tu pas SSL (avec ou sans échange de certif utilisateur) et
login sous ton appli?
On ne peut changer le code de l'application.
Deuxième observation sur l'appli :
en supposant qu'elle soit buggée au point de mal gérer les logins (j'ai
quand même plutôt un doute quand à ta façon de gérer Apache et
l'appli) et que soit tu ne peux exiger un correctif, soit le créateur
n'existe plus, tu mets ton système en danger en ne choississant pas une
autre appli. Exposer une merde *applicative* sur le web ce n'est pas ce
qu'on peut rêver de mieux en sécu.
Et donc , j'aimerais trouver une solution pour qu'au moins
l'authentification par certif SSL me soit demandee lorsque je me connecte
en https a cette appli Web , et ceci avant l'authentification par mot de
passe applicatif
Dans ton cas un rtfm est, amha, parfaitement applicable :(
Et un coup de google-like doit te permettre de trouver un équivalent
français ou au pire une traduction automatique approximative[1]
(j'espere que je ne vous embrouille pas :-)
J'ai bien peur que ce soit toi qui t'embrouille tout seul, faute d'avoir
cherché un minimum les bases de l'échange de certif TLS/SSL :-/
Parce que SSL c'est bien, mais si on ne fait pas l'effort de s'impliquer
un peu le gain en sécurité risque fort d'être théorique.
Accessoirement si tu génère des certifs user, as tu pensé, *avant de
mettre le bouzin en place* à ce que tu dois faire si un certif est
supposé compromis? (indice : crl, gestion applicative directe ...)
Comment faire ? merci de votre aide
En commençant par lire le lien avant de surfer un peu pour continuer?
Attention, ainsi que ça a déjà été plusieurs fois indiqué ici ou sur
fr.misc.cryptologie la difficulté de mise en place d'une PKI ne tiens pas
aux outils mais à la gestion du bidule.
Eric
[1] Vraiment parce qu'on est sur un groupe francophone, parce que les
traductions approximatives c'est franchement à éviter en sécu! J'ai la
flemme de cherche mais je pense que tu devrais trouver ton bonheur
directement dans notre langue :)
Le Sun, 24 Jul 2005 09:01:24 +0000, Yves a écrit :
Voila j'ai une application Web accessible par https et mot de passe (applicatif)
Deux choses distinctes donc.
A cause d'un bug du code de l' application
Si une appli est buggée dès le départ pour une chose aussi importante que du contrôle d'accès c'est poubelle... Mais bon, on va dire que dans ton cas et dans le monde réel il y a obligation d'employer ce bidule.
, elle ne comprend pas l'authentification par certif SSL et mot de passe de compte Apache.
Pardon? Qu'est-ce qu'un compte Apache? Je connais le compte sous lequel tourne Apache (plus précisement l'user et le group, pour le site concerné).
Il y a aussi potentiellement des comptes utilisateurs sur le serveur...
Ne confonds tu pas SSL (avec ou sans échange de certif utilisateur) et login sous ton appli?
On ne peut changer le code de l'application.
Deuxième observation sur l'appli : en supposant qu'elle soit buggée au point de mal gérer les logins (j'ai quand même plutôt un doute quand à ta façon de gérer Apache et l'appli) et que soit tu ne peux exiger un correctif, soit le créateur n'existe plus, tu mets ton système en danger en ne choississant pas une autre appli. Exposer une merde *applicative* sur le web ce n'est pas ce qu'on peut rêver de mieux en sécu.
Et donc , j'aimerais trouver une solution pour qu'au moins l'authentification par certif SSL me soit demandee lorsque je me connecte en https a cette appli Web , et ceci avant l'authentification par mot de passe applicatif
Dans ton cas un rtfm est, amha, parfaitement applicable :(
Et un coup de google-like doit te permettre de trouver un équivalent français ou au pire une traduction automatique approximative[1]
(j'espere que je ne vous embrouille pas :-)
J'ai bien peur que ce soit toi qui t'embrouille tout seul, faute d'avoir cherché un minimum les bases de l'échange de certif TLS/SSL :-/
Parce que SSL c'est bien, mais si on ne fait pas l'effort de s'impliquer un peu le gain en sécurité risque fort d'être théorique.
Accessoirement si tu génère des certifs user, as tu pensé, *avant de mettre le bouzin en place* à ce que tu dois faire si un certif est supposé compromis? (indice : crl, gestion applicative directe ...)
Comment faire ? merci de votre aide
En commençant par lire le lien avant de surfer un peu pour continuer?
Attention, ainsi que ça a déjà été plusieurs fois indiqué ici ou sur fr.misc.cryptologie la difficulté de mise en place d'une PKI ne tiens pas aux outils mais à la gestion du bidule.
Eric
[1] Vraiment parce qu'on est sur un groupe francophone, parce que les traductions approximatives c'est franchement à éviter en sécu! J'ai la flemme de cherche mais je pense que tu devrais trouver ton bonheur directement dans notre langue :)
Dominique Blas
[...]
Comment faire ? merci de votre aide Rien compris.
Si c'est bien Apache qui écoute côté HTTPS c'est lui qui gère le certif et non l'appli. De même si c'est Apache qui gère l'accès à l'alias conduisant à l'application c'est Apache qui gère l'identification/authentification.
Rien n'empêche que l'application gère elle-même l'identification/authentification ainsi que la certification mais dans ce dernier cas Apache ne sert pas à grand chose et cela complique l'application inutilement. L'application est en principe orientée métier et elle a déjà suffisamment fort à faire (sans compter les noeuds de programmation) ainsi sans, en plus, s'occuper de la gestion du proto HTTPS !
Enfin, on veillera à ce moment là à ne pas encombrer le port 443 inutilement.
Ainsi soit nous avons à faire à une bien mauvaise architecture (bien au-delà d'un simple << bug >>) qui pose et posera bien davantage de soucis qu'elle n'est sensée en résoudre (et il vaut mieux l'abandonner) ou quelque chose m'échappe.
Quoi qu'il en soit, ce qui est devant (Apache) est toujours prioritaire sur ce qui est derrière (le serveur applicatif) et donc, si Apache est correctement configuré pour demander un certificat de client il le demandera avant de passer la main au serveur applicatif qui, à son tour, fera ce qu'il souhaite pour identifier/authentifier le client, etc, etc.
db
--
Courriel : usenet blas net
[...]
Comment faire ? merci de votre aide
Rien compris.
Si c'est bien Apache qui écoute côté HTTPS c'est lui qui gère le certif
et non l'appli.
De même si c'est Apache qui gère l'accès à l'alias conduisant à
l'application c'est Apache qui gère l'identification/authentification.
Rien n'empêche que l'application gère elle-même
l'identification/authentification ainsi que la certification mais dans
ce dernier cas Apache ne sert pas à grand chose et cela complique
l'application inutilement.
L'application est en principe orientée métier et elle a déjà
suffisamment fort à faire (sans compter les noeuds de programmation)
ainsi sans, en plus, s'occuper de la gestion du proto HTTPS !
Enfin, on veillera à ce moment là à ne pas encombrer le port 443
inutilement.
Ainsi soit nous avons à faire à une bien mauvaise architecture (bien
au-delà d'un simple << bug >>) qui pose et posera bien davantage de
soucis qu'elle n'est sensée en résoudre (et il vaut mieux l'abandonner)
ou quelque chose m'échappe.
Quoi qu'il en soit, ce qui est devant (Apache) est toujours prioritaire
sur ce qui est derrière (le serveur applicatif) et donc, si Apache est
correctement configuré pour demander un certificat de client il le
demandera avant de passer la main au serveur applicatif qui, à son tour,
fera ce qu'il souhaite pour identifier/authentifier le client, etc, etc.
Si c'est bien Apache qui écoute côté HTTPS c'est lui qui gère le certif et non l'appli. De même si c'est Apache qui gère l'accès à l'alias conduisant à l'application c'est Apache qui gère l'identification/authentification.
Rien n'empêche que l'application gère elle-même l'identification/authentification ainsi que la certification mais dans ce dernier cas Apache ne sert pas à grand chose et cela complique l'application inutilement. L'application est en principe orientée métier et elle a déjà suffisamment fort à faire (sans compter les noeuds de programmation) ainsi sans, en plus, s'occuper de la gestion du proto HTTPS !
Enfin, on veillera à ce moment là à ne pas encombrer le port 443 inutilement.
Ainsi soit nous avons à faire à une bien mauvaise architecture (bien au-delà d'un simple << bug >>) qui pose et posera bien davantage de soucis qu'elle n'est sensée en résoudre (et il vaut mieux l'abandonner) ou quelque chose m'échappe.
Quoi qu'il en soit, ce qui est devant (Apache) est toujours prioritaire sur ce qui est derrière (le serveur applicatif) et donc, si Apache est correctement configuré pour demander un certificat de client il le demandera avant de passer la main au serveur applicatif qui, à son tour, fera ce qu'il souhaite pour identifier/authentifier le client, etc, etc.
