Le Dictionnaire en ligne de
l'Académie Française, quoique difficilement utilisable (il faut
apparemment un logiciel spécifique, non libre, pour le lire),
Le Dictionnaire en ligne de
l'Académie Française, quoique difficilement utilisable (il faut
apparemment un logiciel spécifique, non libre, pour le lire),
Le Dictionnaire en ligne de
l'Académie Française, quoique difficilement utilisable (il faut
apparemment un logiciel spécifique, non libre, pour le lire),
un logiciel spécifique? Je ne savais pas que Firefox était spécifique et non
libre...
un logiciel spécifique? Je ne savais pas que Firefox était spécifique et non
libre...
un logiciel spécifique? Je ne savais pas que Firefox était spécifique et non
libre...
On Wed, Dec 03, 2008 at 10:48:53PM +0100,
Gaëtan PERRIER wrote
a message of 20 lines which said:
> un logiciel spécifique? Je ne savais pas que Firefox était
> spécifique et non libre...
Justement, j'utilise Firefox et il me dit que "Additional
plugins are required to display all the media on this
page" (et la page ne contient pas grand'chose).
On Wed, Dec 03, 2008 at 10:48:53PM +0100,
Gaëtan PERRIER <gaetan.perrier@free.fr> wrote
a message of 20 lines which said:
> un logiciel spécifique? Je ne savais pas que Firefox était
> spécifique et non libre...
Justement, j'utilise Firefox et il me dit que "Additional
plugins are required to display all the media on this
page" (et la page ne contient pas grand'chose).
On Wed, Dec 03, 2008 at 10:48:53PM +0100,
Gaëtan PERRIER wrote
a message of 20 lines which said:
> un logiciel spécifique? Je ne savais pas que Firefox était
> spécifique et non libre...
Justement, j'utilise Firefox et il me dit que "Additional
plugins are required to display all the media on this
page" (et la page ne contient pas grand'chose).
> Et ça par contre, c'est pas possible, on ne peut pas utiliser https
> avec des virtual hosts, c'est pas possible.
Il existe pourtant au moins trois solutions :
1) la commande HTTP STARTTLS (RFC 2817)
http://signal.eu.org/blog/2007/09/07/http-et-tls-la-rfc-meconnue/
3) L'extension X.509 Server Name Indication
http://signal.eu.org/blog/2008/11/25/adieu-rfc-2817-bonjour-rfc-3546/
> Et ça par contre, c'est pas possible, on ne peut pas utiliser https
> avec des virtual hosts, c'est pas possible.
Il existe pourtant au moins trois solutions :
1) la commande HTTP STARTTLS (RFC 2817)
http://signal.eu.org/blog/2007/09/07/http-et-tls-la-rfc-meconnue/
3) L'extension X.509 Server Name Indication
http://signal.eu.org/blog/2008/11/25/adieu-rfc-2817-bonjour-rfc-3546/
> Et ça par contre, c'est pas possible, on ne peut pas utiliser https
> avec des virtual hosts, c'est pas possible.
Il existe pourtant au moins trois solutions :
1) la commande HTTP STARTTLS (RFC 2817)
http://signal.eu.org/blog/2007/09/07/http-et-tls-la-rfc-meconnue/
3) L'extension X.509 Server Name Indication
http://signal.eu.org/blog/2008/11/25/adieu-rfc-2817-bonjour-rfc-3546/
Aha, une nouvelle réponse, et qu'elle est belle. Je vais
regarder ça de plus près, et ça sera sans doute ma réponse
la prochaine fois que quelqu'un demande comment faire.
Aha, une nouvelle réponse, et qu'elle est belle. Je vais
regarder ça de plus près, et ça sera sans doute ma réponse
la prochaine fois que quelqu'un demande comment faire.
Aha, une nouvelle réponse, et qu'elle est belle. Je vais
regarder ça de plus près, et ça sera sans doute ma réponse
la prochaine fois que quelqu'un demande comment faire.
Si si, c'est faisable. Je sais plus où j'avais vu de la doc
là-dessus,
Si si, c'est faisable. Je sais plus où j'avais vu de la doc
là-dessus,
Si si, c'est faisable. Je sais plus où j'avais vu de la doc
là-dessus,
On Wed, Dec 03, 2008 at 06:16:38PM +0100,
François TOURDE wrote
a message of 26 lines which said:
> Si si, c'est faisable. Je sais plus où j'avais vu de la doc
> là-dessus,
Ici :-)
Authentifier des serveurs Internet avec X.509 lorsqu'ils ont la même
adresse IP
http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html
Première rédaction de cet article le 4 Décembre 2008
----------------------------
On lit souvent qu'il n'est pas possible d'avoir plusieurs serveurs
Internet sur la même adresse IP lorsqu'ils sont authentifiés par un
certificat X.509. Il faudrait donc donner une adresse IP à chacun.
Cette affirmation a des origines réalistes mais est sans doute trop
stricte aujourd'hui.
Dans un protocole comme HTTPS, le nom du serveur est transmis une fois
la session TLS établie. Il est donc a priori trop tard à ce moment po ur
choisir un autre certificat. D'où le mème « Un seul certificat par
adresse IP ». En fait, il est possible d'avoir une seule adresse IP et
néanmoins un certificat différent par "Virtual Host" Apache, même s i
les méthodes existantes ont quelques limites.
Il existe trois méthodes pour HTTPS (toutes ne sont pas forcément
applicables aux autres protocoles) :
* La commande HTTP STARTTLS (RFC 2817) qui permet de transmettre le nom
du serveur avant la négociation TLS.
* L'extension X.509 "Subject Alternative Name" (RFC 2459) qui permet de
mettre plusieurs noms dans un certificat. Le client sera alors content
si un des noms correspond.
* L'extension X.509 "Server Name Indication" (SNI) (RFC 4366) qui
permet au client d'indiquer le nom du serveur dans la négociation TLS.
Chacune a ses forces et ses faiblesses et des domaines où elle est
meilleure que les autres.
La première, STARTTLS, normalisée dans le RFC 2817, est bien décrit e
par Pierre Beyssac dans « HTTP et TLS, la RFC méconnue...
(http://signal.eu.org/blog/2007/09/07/http-et-tls-la-rfc-meconnue/) ».
Très répandue avec des protocoles comme IMAP ou SMTP, elle a un gros
inconvénient pour HTTP : il n'est pas possible d'indiquer dans l'URL
que TLS est obligatoire. Un attaquant sur le chemin, ou bien un serveur
mal configuré, et on retombe sur du HTTP non protégé.
Mise en œuvre dans Apache depuis la version 2.2, elle n'est présen t
dans aucun grand navigateur, pour les raisons expliquées par Mozilla
dans la bogue #276813
(https://bugzilla.mozilla.org/show_bug.cgi?id'6813).
Une deuxième méthode est le certificat contenant plusieurs noms. Elle
est possible grâce à l'extension X.509 "Subject Alternative Name",
normalisée dans le RFC 2459. Elle est décrite en détail dans mon
article « Plusieurs noms dans un certificat X.509
(http://www.bortzmeyer.org/plusieurs-noms-dans-certificat.html) » ou
bien dans celui de Franck Davy, « Apache : Hôtes virtuels et SSL
(mod_ssl)
(http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html.fr) ». En
anglais, on peut lire « "Information about setting up the ApacheServer
to serve multiple HTTPS sites using one IP address
(http://wiki.cacert.org/wiki/CSRGenerator?action=show&redirect=Vhosts Apa
che)" ».
Elle fonctionne avec openssl (aussi bien pour générer le certificat q ue
pour le vérifier) mais il faut que la CA qui signe l'accepte et
j'ignore si les grosses CA ayant pignon sur rue le font ou pas. C'est
la méthode qui semble la plus déployée et donc celle qui apporte le
moins de surprises (CAcert a fait des tests détailles
d'interopérabilité
(http://wiki.cacert.org/wiki/VhostTaskForce#InteroperabilityTest) sur
les variants de cette méthode).
La troisième méthode repose sur une extension du protocole TLS et non
pas du format X.509. Cette extension, "Server Name Indication" (SNI),
est l'une de celles décrites dans le RFC 4366. Elle envoie le nom du
serveur lors de la négociation TLS. Elle est bien expliquée dans
l'article de Pierre Beyssac « Adieu RFC 2817, bonjour RFC 3546
(http://signal.eu.org/blog/2008/11/25/adieu-rfc-2817-bonjour-rfc-3546/)
».
SNI ("Server Name Indication") ne marche pas avec le module Apache
mod_ssl, il faut utiliser mod_gnutls. Il y a un certificat par "Virtual
Host" et elle ne gère donc pas le cas où un "Virtual Host" a plusieur s
noms, avec la directive ServerAlias.
Les serveurs HTTP gérés par le département de recherche & dévelop pement
de l'AFNIC sont un exemple de déploiement de deux de ces techniques. Le
serveur, un Apache, utilise mod_gnutls, avec un certificat par "Virtual
Host", et peut donc tirer profit de la troisième méthode, SNI. Au cas
où le client ne gère pas l'extension SNI, le certificat par défaut
(celui qui est utilisé dans la directive <VirtualHost _default_:443>)
est un certificat avec plusieurs noms.
Merci à Pierre Beyssac, Mario Victor-Oscar et Yves Rutschle pour des
informations stimulantes et utiles.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
On Wed, Dec 03, 2008 at 06:16:38PM +0100,
François TOURDE <fra-duf-no-spam@tourde.org> wrote
a message of 26 lines which said:
> Si si, c'est faisable. Je sais plus où j'avais vu de la doc
> là-dessus,
Ici :-)
Authentifier des serveurs Internet avec X.509 lorsqu'ils ont la même
adresse IP
http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html
Première rédaction de cet article le 4 Décembre 2008
----------------------------
On lit souvent qu'il n'est pas possible d'avoir plusieurs serveurs
Internet sur la même adresse IP lorsqu'ils sont authentifiés par un
certificat X.509. Il faudrait donc donner une adresse IP à chacun.
Cette affirmation a des origines réalistes mais est sans doute trop
stricte aujourd'hui.
Dans un protocole comme HTTPS, le nom du serveur est transmis une fois
la session TLS établie. Il est donc a priori trop tard à ce moment po ur
choisir un autre certificat. D'où le mème « Un seul certificat par
adresse IP ». En fait, il est possible d'avoir une seule adresse IP et
néanmoins un certificat différent par "Virtual Host" Apache, même s i
les méthodes existantes ont quelques limites.
Il existe trois méthodes pour HTTPS (toutes ne sont pas forcément
applicables aux autres protocoles) :
* La commande HTTP STARTTLS (RFC 2817) qui permet de transmettre le nom
du serveur avant la négociation TLS.
* L'extension X.509 "Subject Alternative Name" (RFC 2459) qui permet de
mettre plusieurs noms dans un certificat. Le client sera alors content
si un des noms correspond.
* L'extension X.509 "Server Name Indication" (SNI) (RFC 4366) qui
permet au client d'indiquer le nom du serveur dans la négociation TLS.
Chacune a ses forces et ses faiblesses et des domaines où elle est
meilleure que les autres.
La première, STARTTLS, normalisée dans le RFC 2817, est bien décrit e
par Pierre Beyssac dans « HTTP et TLS, la RFC méconnue...
(http://signal.eu.org/blog/2007/09/07/http-et-tls-la-rfc-meconnue/) ».
Très répandue avec des protocoles comme IMAP ou SMTP, elle a un gros
inconvénient pour HTTP : il n'est pas possible d'indiquer dans l'URL
que TLS est obligatoire. Un attaquant sur le chemin, ou bien un serveur
mal configuré, et on retombe sur du HTTP non protégé.
Mise en œuvre dans Apache depuis la version 2.2, elle n'est présen t
dans aucun grand navigateur, pour les raisons expliquées par Mozilla
dans la bogue #276813
(https://bugzilla.mozilla.org/show_bug.cgi?id=276813).
Une deuxième méthode est le certificat contenant plusieurs noms. Elle
est possible grâce à l'extension X.509 "Subject Alternative Name",
normalisée dans le RFC 2459. Elle est décrite en détail dans mon
article « Plusieurs noms dans un certificat X.509
(http://www.bortzmeyer.org/plusieurs-noms-dans-certificat.html) » ou
bien dans celui de Franck Davy, « Apache : Hôtes virtuels et SSL
(mod_ssl)
(http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html.fr) ». En
anglais, on peut lire « "Information about setting up the ApacheServer
to serve multiple HTTPS sites using one IP address
(http://wiki.cacert.org/wiki/CSRGenerator?action=show&redirect=Vhosts Apa
che)" ».
Elle fonctionne avec openssl (aussi bien pour générer le certificat q ue
pour le vérifier) mais il faut que la CA qui signe l'accepte et
j'ignore si les grosses CA ayant pignon sur rue le font ou pas. C'est
la méthode qui semble la plus déployée et donc celle qui apporte le
moins de surprises (CAcert a fait des tests détailles
d'interopérabilité
(http://wiki.cacert.org/wiki/VhostTaskForce#InteroperabilityTest) sur
les variants de cette méthode).
La troisième méthode repose sur une extension du protocole TLS et non
pas du format X.509. Cette extension, "Server Name Indication" (SNI),
est l'une de celles décrites dans le RFC 4366. Elle envoie le nom du
serveur lors de la négociation TLS. Elle est bien expliquée dans
l'article de Pierre Beyssac « Adieu RFC 2817, bonjour RFC 3546
(http://signal.eu.org/blog/2008/11/25/adieu-rfc-2817-bonjour-rfc-3546/)
».
SNI ("Server Name Indication") ne marche pas avec le module Apache
mod_ssl, il faut utiliser mod_gnutls. Il y a un certificat par "Virtual
Host" et elle ne gère donc pas le cas où un "Virtual Host" a plusieur s
noms, avec la directive ServerAlias.
Les serveurs HTTP gérés par le département de recherche & dévelop pement
de l'AFNIC sont un exemple de déploiement de deux de ces techniques. Le
serveur, un Apache, utilise mod_gnutls, avec un certificat par "Virtual
Host", et peut donc tirer profit de la troisième méthode, SNI. Au cas
où le client ne gère pas l'extension SNI, le certificat par défaut
(celui qui est utilisé dans la directive <VirtualHost _default_:443>)
est un certificat avec plusieurs noms.
Merci à Pierre Beyssac, Mario Victor-Oscar et Yves Rutschle pour des
informations stimulantes et utiles.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
On Wed, Dec 03, 2008 at 06:16:38PM +0100,
François TOURDE wrote
a message of 26 lines which said:
> Si si, c'est faisable. Je sais plus où j'avais vu de la doc
> là-dessus,
Ici :-)
Authentifier des serveurs Internet avec X.509 lorsqu'ils ont la même
adresse IP
http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html
Première rédaction de cet article le 4 Décembre 2008
----------------------------
On lit souvent qu'il n'est pas possible d'avoir plusieurs serveurs
Internet sur la même adresse IP lorsqu'ils sont authentifiés par un
certificat X.509. Il faudrait donc donner une adresse IP à chacun.
Cette affirmation a des origines réalistes mais est sans doute trop
stricte aujourd'hui.
Dans un protocole comme HTTPS, le nom du serveur est transmis une fois
la session TLS établie. Il est donc a priori trop tard à ce moment po ur
choisir un autre certificat. D'où le mème « Un seul certificat par
adresse IP ». En fait, il est possible d'avoir une seule adresse IP et
néanmoins un certificat différent par "Virtual Host" Apache, même s i
les méthodes existantes ont quelques limites.
Il existe trois méthodes pour HTTPS (toutes ne sont pas forcément
applicables aux autres protocoles) :
* La commande HTTP STARTTLS (RFC 2817) qui permet de transmettre le nom
du serveur avant la négociation TLS.
* L'extension X.509 "Subject Alternative Name" (RFC 2459) qui permet de
mettre plusieurs noms dans un certificat. Le client sera alors content
si un des noms correspond.
* L'extension X.509 "Server Name Indication" (SNI) (RFC 4366) qui
permet au client d'indiquer le nom du serveur dans la négociation TLS.
Chacune a ses forces et ses faiblesses et des domaines où elle est
meilleure que les autres.
La première, STARTTLS, normalisée dans le RFC 2817, est bien décrit e
par Pierre Beyssac dans « HTTP et TLS, la RFC méconnue...
(http://signal.eu.org/blog/2007/09/07/http-et-tls-la-rfc-meconnue/) ».
Très répandue avec des protocoles comme IMAP ou SMTP, elle a un gros
inconvénient pour HTTP : il n'est pas possible d'indiquer dans l'URL
que TLS est obligatoire. Un attaquant sur le chemin, ou bien un serveur
mal configuré, et on retombe sur du HTTP non protégé.
Mise en œuvre dans Apache depuis la version 2.2, elle n'est présen t
dans aucun grand navigateur, pour les raisons expliquées par Mozilla
dans la bogue #276813
(https://bugzilla.mozilla.org/show_bug.cgi?id'6813).
Une deuxième méthode est le certificat contenant plusieurs noms. Elle
est possible grâce à l'extension X.509 "Subject Alternative Name",
normalisée dans le RFC 2459. Elle est décrite en détail dans mon
article « Plusieurs noms dans un certificat X.509
(http://www.bortzmeyer.org/plusieurs-noms-dans-certificat.html) » ou
bien dans celui de Franck Davy, « Apache : Hôtes virtuels et SSL
(mod_ssl)
(http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html.fr) ». En
anglais, on peut lire « "Information about setting up the ApacheServer
to serve multiple HTTPS sites using one IP address
(http://wiki.cacert.org/wiki/CSRGenerator?action=show&redirect=Vhosts Apa
che)" ».
Elle fonctionne avec openssl (aussi bien pour générer le certificat q ue
pour le vérifier) mais il faut que la CA qui signe l'accepte et
j'ignore si les grosses CA ayant pignon sur rue le font ou pas. C'est
la méthode qui semble la plus déployée et donc celle qui apporte le
moins de surprises (CAcert a fait des tests détailles
d'interopérabilité
(http://wiki.cacert.org/wiki/VhostTaskForce#InteroperabilityTest) sur
les variants de cette méthode).
La troisième méthode repose sur une extension du protocole TLS et non
pas du format X.509. Cette extension, "Server Name Indication" (SNI),
est l'une de celles décrites dans le RFC 4366. Elle envoie le nom du
serveur lors de la négociation TLS. Elle est bien expliquée dans
l'article de Pierre Beyssac « Adieu RFC 2817, bonjour RFC 3546
(http://signal.eu.org/blog/2008/11/25/adieu-rfc-2817-bonjour-rfc-3546/)
».
SNI ("Server Name Indication") ne marche pas avec le module Apache
mod_ssl, il faut utiliser mod_gnutls. Il y a un certificat par "Virtual
Host" et elle ne gère donc pas le cas où un "Virtual Host" a plusieur s
noms, avec la directive ServerAlias.
Les serveurs HTTP gérés par le département de recherche & dévelop pement
de l'AFNIC sont un exemple de déploiement de deux de ces techniques. Le
serveur, un Apache, utilise mod_gnutls, avec un certificat par "Virtual
Host", et peut donc tirer profit de la troisième méthode, SNI. Au cas
où le client ne gère pas l'extension SNI, le certificat par défaut
(celui qui est utilisé dans la directive <VirtualHost _default_:443>)
est un certificat avec plusieurs noms.
Merci à Pierre Beyssac, Mario Victor-Oscar et Yves Rutschle pour des
informations stimulantes et utiles.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Authentifier des serveurs Internet avec X.509 lorsqu'ils ont la même adresse IP
http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html
[...] "Subject Alternative Name" [...]
Elle fonctionne avec openssl (aussi bien pour générer le certificat que
pour le vérifier) mais il faut que la CA qui signe l'accepte et
j'ignore si les grosses CA ayant pignon sur rue le font ou pas.
SNI ("Server Name Indication") ne marche pas avec le module Apache
mod_ssl, il faut utiliser mod_gnutls. Il y a un certificat par "Virtual
Host" et elle ne gère donc pas le cas où un "Virtual Host" a plusieurs
noms, avec la directive ServerAlias.
Authentifier des serveurs Internet avec X.509 lorsqu'ils ont la même adresse IP
http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html
[...] "Subject Alternative Name" [...]
Elle fonctionne avec openssl (aussi bien pour générer le certificat que
pour le vérifier) mais il faut que la CA qui signe l'accepte et
j'ignore si les grosses CA ayant pignon sur rue le font ou pas.
SNI ("Server Name Indication") ne marche pas avec le module Apache
mod_ssl, il faut utiliser mod_gnutls. Il y a un certificat par "Virtual
Host" et elle ne gère donc pas le cas où un "Virtual Host" a plusieurs
noms, avec la directive ServerAlias.
Authentifier des serveurs Internet avec X.509 lorsqu'ils ont la même adresse IP
http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html
[...] "Subject Alternative Name" [...]
Elle fonctionne avec openssl (aussi bien pour générer le certificat que
pour le vérifier) mais il faut que la CA qui signe l'accepte et
j'ignore si les grosses CA ayant pignon sur rue le font ou pas.
SNI ("Server Name Indication") ne marche pas avec le module Apache
mod_ssl, il faut utiliser mod_gnutls. Il y a un certificat par "Virtual
Host" et elle ne gère donc pas le cas où un "Virtual Host" a plusieurs
noms, avec la directive ServerAlias.
Un autre gros problème de cette méthode est qu'elle n'est
pas vraiment applicable au cas (courant?) de virtual hosting
de sites indépendants sur serveur mutualisé: par exemple
plusieurs boutiques, dont certains sont peut-être des
escrocs, hébergés par le même hébergeur.
Cette méthode ne permet finalement que d'authentifier
l'hébergeur.
Un autre gros problème de cette méthode est qu'elle n'est
pas vraiment applicable au cas (courant?) de virtual hosting
de sites indépendants sur serveur mutualisé: par exemple
plusieurs boutiques, dont certains sont peut-être des
escrocs, hébergés par le même hébergeur.
Cette méthode ne permet finalement que d'authentifier
l'hébergeur.
Un autre gros problème de cette méthode est qu'elle n'est
pas vraiment applicable au cas (courant?) de virtual hosting
de sites indépendants sur serveur mutualisé: par exemple
plusieurs boutiques, dont certains sont peut-être des
escrocs, hébergés par le même hébergeur.
Cette méthode ne permet finalement que d'authentifier
l'hébergeur.
Question pertinante pour revenir dans le sujet: mod_gnutls
n'est pas actuellement packagé par Debian, ou c'est moi qui
suis handicapé de l'apt-cache search?
Question pertinante pour revenir dans le sujet: mod_gnutls
n'est pas actuellement packagé par Debian, ou c'est moi qui
suis handicapé de l'apt-cache search?
Question pertinante pour revenir dans le sujet: mod_gnutls
n'est pas actuellement packagé par Debian, ou c'est moi qui
suis handicapé de l'apt-cache search?