[Linux-bruxelles] Apache2 SSL : Virtual Hosts, Certificats, etc

Lun 7 Jan 11:53:52 CET 2008

linux-bruxelles-bounces at lists.bxlug.be wrote on 07/01/2008 11:08:48:

> Didier Misson écrivait :
> 
> > J'ai 2 sites (pour le moment, pour debugguer, j'ai désactivé les 
autres)
> > 
> > - misson.net (ou www.misson.net) : qui doit être accessible aussi bien
> >   en HTTP qu'en HTTPS certificat signé par CAcert.org
> > 
> > - phpmyadmin.misson.net qui doit être accessible en HTTPS : le HTTP 
doit
> >   être redirigé vers https://phpmyadmin.misson.net certificat 
auto-signé
> 
> La cause du problème a déjà été citée par ailleurs, je vais expliquer
> le pourquoi du comment, et pointer deux pistes supplémentaires.
> 
> Dans des temps immémoriaux (quoique), 

le temps passe si vite niveau info et web ;-)

> le monde fonctionnait avec un
> site web par serveur, un serveur par adresse IP, et je demandais le
> site www.debian.org, l'adresse IP était résolue, le navigateur
> connectait cette adresse, sur le port 80, et recevait une page.

c'était simple oui.

> Petite simulation :
> 
>    $ host www.debian.org
>   www.debian.org          A       194.109.137.218
>    $ telnet 194.109.137.218 80
>   GET / HTTP/1.0
>      <-- là j'appuie une seconde fois sur enter
>   HTTP/1.1 200 OK
>   Date: Mon, 07 Jan 2008 09:37:23 GMT
>   Server: Apache/2.0.54 (Debian GNU/Linux)
>   Content-Type: text/html
> 
>   <html>
>     <head>
>       <title>Debian GNU/Linux</title>
>       ...
> 
> Le protocole HTTP 1.0 est défini dans la RFC 1945
>   http://www.ietf.org/rfc/rfc1945.txt
> Il fait suite à un HTTP 0.9 baptisé de ce numéro de version à titre
> posthume, mais c'est du détail insignifiant.
> 
> Mais voilà qu'arrive une multiplication de sites, et la réalisation
> que la nécessité d'une adresse IP par site, ça va pas tenir, alors
> vient le tour d'HTTP 1.1 (maintenant RFC 2616).
> 
>    $ host www.debian.org
>   www.debian.org          A       194.109.137.218
>    $ host www.plop.org
>   www.plop.org            A       194.109.137.218
> 
> Ah ah, il y a deux sites qui peuvent répondre à cette adresse.
> 
>    $ telnet 194.109.137.218 80
>   GET / HTTP/1.1
>   Host: www.debian.org   <-- j'ajoute un entête, Host
>      <-- là j'appuie une seconde fois sur enter
>   HTTP/1.1 200 OK
>   Date: Mon, 07 Jan 2008 09:37:23 GMT
>   Server: Apache/2.0.54 (Debian GNU/Linux)
>   Content-Type: text/html
> 
>   <html>
>     <head>
>       <title>Debian GNU/Linux</title>
>       ...
> 
> C'est dans cet entête Host: que se trouve la possibilité d'avoir un
> serveur web servant plusieurs sites depuis une seule adresse.  Cela
> correspond à la directive NameVirtualHost d'Apache, qui indique qu'un
> site sera servi en faisant gaffe à l'entête Host, il regardera alors
> les ServerName et ServerAlias pour trouver le site à envoyer.

jusque là, la solution multi-site est encore simple, ok.

> Et tout ça, c'est super, mais l'HTTPS...
> 
>    $ telnet 194.109.137.218 443
>   jazojda,x<w,xpozajuedoa"à&"!ésqmljdqmziueéoqsmkqùkfs
> 
> Je fais assez mal l'HTTPS, 

je suis d'accord avec toi  ;-)

> mais ce qui se passe là c'est qu'il va y
> avoir un petit échange, certificats tout ça, puis la demande sera
> déchiffrée et le serveur web recevra son GET / et cie.

ah... "PUIS la demande déchiffrée"...

> Il recevra aussi son Host: mais c'est là qu'est le problème, le petit
> échange de négociation, il se fait avant de déchiffrer la demande, il
> est même nécessaire à déchiffrer la demande, il n'est donc pas
> possible au site de connaitre l'Host: avant d'envoyer le certificat,
> et donc pas moyen d'envoyer un certificat différent suivant l'Host:.

aie
oui, je vois...
Je pensais qu'il "identifiait" le host avant de chiffrer...

> Cela explique tout, mais j'annonçais deux pistes.
> 
> La première n'est pas d'une grande finesse, elle consiste à utiliser
> un certificat qui sera bon pour plusieurs domaines, genre *.misson.net

ok d'accord
mais il parait que tous les navigateurs n'acceptent pas
les certificats du genre *.misson.net

Mais ok, c'est une solution pour mon serveur @ home
mais pas pour le serveur hébergé à l'extérieur
(qui mélange des sites très différents)

> La seconde est cent fois plus classe, elle vient en deux temps,
> d'abord TLS, le "successeur" de SSL, Pour info, la RFC 2818 décrit
> comment faire de l'HTTP sur du TLS.

oui, exact, la norme officielle est TLS et plus SSL
(qui était un protocole Netscape)

> TLS, il y a de grandes chances que vous l'utilisez déjà pour les
> services SMTP, TLS permet à une connexion de passer d'un état clair à
> un état chiffré, exemple SMTP:
> 
>    $ telnet smtp.example.com 25
>   Trying 127.0.0.1...
>   Connected to smtp.example.com.
>   Escape character is '^]'.
>   220 smtp.example.com ESMTP Exim 4.63 Mon, 07 Jan 2008 10:57:50 +0100
>   EHLO plop
>   250-smtp.example.com Hello plop [212.71.10.27]
>   250-SIZE 52428800
>   250-PIPELINING
>   250-STARTTLS
>   250 HELP
>   STARTTLS
>   220 TLS go ahead

> Et à partir de là, communication chiffrée.

ok

> Le second temps vient de la RFC 3546, c'est SNI, Server Name
> Indication, qui s'ajoute à TLS, et dont la description est
> cristalline :
> 
>    [TLS] does not provide a mechanism for a client to tell a server the
>    name of the server it is contacting.  It may be desirable for clients
>    to provide this information to facilitate secure connections to
>    servers that host multiple 'virtual' servers at a single underlying
>    network address.
> 
> Avec SNI, il est donc possible lors de la négociation de signifier le
> nom du site qu'on voudrait contacter, le certificat sera reçu après,
> et donc il y aura moyen d'avoir des certificats différents.
> 
> 
> C'est bon, vous rêvez de nouveaux horizons ?

c'est exactement la solution je crois !
enfin... en théorie
à voir en pratique...

> Retour sur terre.
> 
> Il n'y a pas moyen de faire d'SNI avec mod_ssl, mais il existe
> mod_gnutls, c'est expérimental, pas packagé.  Mais si jamais, voici un
> HOWTO pour sa mise en place :
> 
>   http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-
> virtual-hosts-with-mod_gnutls/
> 
> L'autre point noir, c'est au niveau des navigateurs, particulièrement
> Microsoft Internet Explorer, dont la version 7 serait ok, mais
> uniquement quand exécutée sous Vista.

hum hum

par curiosité, j'essayerais bien...
mais clair que sur le serveur de prod, ça la fout mal si une des 
conditions
est d'avoir Ms IE7 + Vista pour s'y connecter :p)

(et Firefox est compatible je suppose ? Y compris sans Vista ?) 

> C'était le long message de début de semaine, j'espère que je n'ai
> injurié personne, même par quelques raccourcis que j'ai pu prendre,
> à la prochaine !
> 
> 
>         Frédéric

non ça va ;-)

Là au moins, j'ai compris la limitation de la config SSL utilisée.

Et je suis d'accord avec Yannick !
Ton explication est très claire et ce serait bien de la conserver sur le 
site.

Merci Frédéric et bonne journée.

-- 
Didier
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/linux-bruxelles/attachments/20080107/168fe333/attachment-0002.html>