WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB

Transcription

1 WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB Installation et administration d un serveur web Module TP A5 (1/2 valeur) Chapitre 12 SSL et Apache

2 Le plus grand soin a été apporté à la réalisation de ce support pédagogique afin de vous fournir une information complète et fiable. Cependant, le Cnam Champagne-Ardenne n'assume de responsabilités, ni pour son utilisation, ni pour les contrefaçons de brevets ou atteintes aux droits de tierces personnes qui pourraient résulter de cette utilisation. Les exemples ou programmes présents dans cet ouvrage sont fournis pour illustrer les descriptions théoriques. Ils ne sont en aucun cas destinés à une utilisation commerciale ou professionnelle. Le Cnam ne pourra en aucun cas être tenu pour responsable des préjudices ou dommages de quelque nature que ce soit pouvant résulter de l'utilisation de ces exemples ou programmes. Tous les noms de produits ou autres marques cités dans ce support sont des marques déposées par leurs propriétaires respectifs. Ce support pédagogique a été rédigé par Michel Melcior, enseignant vacataire au Cnam Champagne-Ardenne. Copyright Centre d'enseignement A Distance du Cnam Champagne-Ardenne. Tous droits réservés. Toute reproduction, même partielle, par quelque procédé que ce soit, est interdite sans autorisation préalable du Cnam Champagne-Ardenne. Une copie par xérographie, photographie, film, support magnétique ou autre, constitue une contrefaçon passible des peines prévues par la loi, du 11 mars 1957 et du 3 juillet 1995, sur la protection des droits d'auteur.

3 SSL ET APACHE 1. OBJECTIFS En fin de séance, vous devriez être capable : De décrire les mécanismes de cryptage par paires de clefs et l'utilité des certificats. De créer une clef privée et un certificat de test et utiliser l'ensemble avec Apache. 2. INTRODUCTION Le protocole HTTP n'est pas conçu pour apporter une quelconque sécurité. Les échanges d'informations se font en clair dans les paquets qui circulent sur le réseau. Il suffit, par exemple, d'insérer un analyseur de réseau entre le client et le serveur pour reconstituer très facilement l'ensemble des informations échangées. Ce mode de fonctionnement n'est pas acceptable pour certains types d'échanges comme : Les transactions financières avec échange d'informations comme des numéros de carte bancaire ; D'une manière générale, dès que les informations échangées prennent un caractère confidentiel. La solution pour le traitement de ce type d'échange est le recours au chiffrement des transactions. Le module d'apache permettant d'obtenir ce résultat s'appelle mod_ssl. SSL signifie Secure Socket Layer. C'est un protocole de sécurisation des échanges, développé par Netscape. Il a été conçu pour assurer la sécurité des transactions sur Internet (notamment entre un client et un serveur), et il est intégré depuis 1994 dans les navigateurs. Il existe plusieurs versions: la version 2.0 développée par Netscape; la version 3.0 qui est actuellement la plus répandue, et la version 3.1 baptisée TLS (transport Layer Security, RFC 2246) et standardisée par l'ietf (Internet Engineering Task Force). SSL fonctionne de manière indépendante par rapport aux applications qui l'utilisent; il est obligatoirement audessus de la couche TCP et certains le considèrent comme un protocole de niveau 5 (couche session). Les données passées à TCP (couche 4, transport) vont être cryptées. Dans la pratique, l'accès à ce type de site se fera avec une URL commençant par https et non http. Exemple : Installation et administration d un serveur web 1

4 3. LE CHIFFREMENT ASYMETRIQUE A DEUX CLEFS Tout repose sur l'existence d'algorithmes de cryptage à deux clefs. Une clef est simplement un fichier comportant une suite de bits. Voici un exemple de clef : -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,F23A96255F3F177A R7GcxbfXoBEprasrQY1kVk9a+LN+8roRVZjq0EJoY3t8dYHnv6yVQfi/lvLKuA0/ 5yoCN/kTv0KlqpHmv/8jIBuQSCCV9cRyt9VPypEBDot52mHseubA3oWbxF3M+Nat IP5Es11Xu6n9HtCnXf82fYAAsjAZHk5cRmYA1lOs8lekrk3jY1JpOxMzWYGPtwQw 46akos1WUeFMh6ngKehDdbRtykGcQoE+5XB1KU2btV6QaOpWLcskM8X65bIDvMvI LIw1yjLNNkigKkV96vqWWkAWuUmiRjyAHqejAsdTMzzQ/G8dD7HuVhlpSrp8PyAA xp8/u6vja9bulw9k51gmlgqqlaybwjhpzkklmwjw7yxggrtzequheld/facnocsl gqlnuszvl4xzb1r70vml6exh3s/uujyqatfywypelv7/j5bmcey9kk+cjehfubub ds+pqtfriyksfk6igqwpixfunt5xgrfb6vt6xwjzpyuwatynfkllikgpyj9kmtha t/uf+m8i+bxwiprywre/eocqev2gq+kq7vviy/3znnfri211cxdurqbamk0aedpk F+Cf7SmcmxmFsg6BoGeKYlxgVLIMmVcjTimq2JCLgeeQecYqmYbujd2ODjlhNDGS v3vwex7wfygktl+v97+7tx29fq6ca0csa4xzdkgvbxcbu1vys8zqem2id/5sizfl I4nAJiCRRy7OhF1Iy/37xp59V6qjyvp/R4+ruOtdpZ2J8makyCE2+HiZMbotXo/5 cqcvk5zz3vyiotutu6qc2dhg4ughe2cbtykmbcsnkbdl3jdize1utg== -----END RSA PRIVATE KEY----- Nous appellerons une de ces deux clefs, "clef A" et l'autre "clef B". Le principe est le suivant, un message en clair est crypté à l'aide de l'algorithme et d'une des deux clefs. Prenons l'exemple d'un cryptage à l'aide de la clef A. Message en clair : "Bonjour" Algorithme de cryptage Message codé : "AxdU5v" Clef A : "Oj5gtv49dExZa7" En possession de la clef A et du message codé avec cette clef A, il est impossible dans un temps raisonnable de revenir au message en clair d'origine. Le décodage du message ne peut se faire qu'avec la deuxième clef (ici, la clef B). SSL et Apache 2

5 Message codé : "AxdU5v" Algorithme de cryptage Message en clair : "Bonjour" Clef B : "Ph6sf34xwT8km" Ce processus fonctionne aussi dans l'autre sens. Si on code avec la clef B, on ne peut décoder qu'avec la clef A. Ce mécanisme nous donne une solution pour traiter les problèmes de confidentialité. Si un client se connnecte à un serveur web SSL, celui-ci lui renvoie une des deux clefs. Client 1. Envoi de la clef publique Serveur Clef publique Clef privée Poste en interception Cette clef, envoyée sur le réseau est appelée "clef publique" car n'importe quel poste placé en interception peut la lire. Le serveur web ne diffuse pas la deuxième clef. Pour cette raison, elle sera baptisée "clef privée". Pour la suite des échanges, le client utilise la clef publique pour crypter les données envoyées au serveur. Installation et administration d un serveur web 3

6 2. Le client envoie une réponse codée Client Message crypté Serveur Clef publique Clef privée Poste en interception Si une tierce partie intercepte un message envoyé par le client, il ne pourra pas le décrypter car seul le serveur dispose de la clef privée. Tout le système repose sur la très grande quantité de calculs nécessaires pour réussir à décrypter un message si l'on ne dispose que de la clef utilisée pour le crypter. Ce n'est pas impossible mais très long et fonction de la longueur de la clef utilisée. Plus votre clef comportera de bits, plus le degré de sécurité (le temps de calcul nécessaire pour "casser le code") sera élevé. Les clefs actuelles autorisées assurent un degré de protection élevé contre le piratage de nature délictuel mais, ne vous y trompez pas, les organismes gouvernementaux possèdent les moyens de calcul nécessaires pour casser ce genre de codage en temps réel. Le mécanisme décrit plus haut est généralement celui que vous utilisez pour accéder à des sites de paiement en ligne. Il est possible de le compléter en utilisant une paire de clefs également sur le client. Clef publique Client Message crypté Serveur Clef publique Clef privée Message crypté Clef privée Poste en interception ne peut décrypter dans aucun sens SSL et Apache 4

7 Mais ce schéma n'est pas souvent utilisé car il est rare de posséder une paire de clefs sur le client. 4. LES CERTIFICATS Nous venons de voir le principe des échanges cryptés à deux clefs. Ils assurent la confidentialité des transactions mais une question reste posée : Est on certain de l'identité et de la confiance que l'on doit attribuer au serveur web sécurisé par SSL? Le certificat est une réponse à cette question. Il est censé attester de l'identité de celui qui émet la clef publique. Un certificat doit donc être émis par un serveur qui souhaite être crédible. Un certificat contient principalement : La clef publique de l'émetteur. Des informations sur l'identité de l'émetteur. Une date de validité de début et de fin. Une signature électronique d'un tiers de confiance attestant l'authenticité des informations d'identité. La norme X509 est reconnue internationalement pour la création des certificats. En fait, par le principe de la signature d'un tiers, on reporte le problème de la confiance sur ce tiers. ou émetteurs de certificats (Certificate Authority, CA en anglais). Ce sont des organismes privés, comme ceux donnés en exemple, ci-dessous qui vont se charger (moyennant finances) d'apporter leur signature électronique aux certificats. Verisign Thawte Ces organismes publient des annuaires de certificats signés par leur soin. Les certificats X.509 en sont à la troisième version. (et depuis le quatrième version) Les certificats X509, version 3, sont utilisés dans diverses applications ou protocoles comme : SSL/TLS. IPSec. authentification... Pour procéder à la signature d'un certificat, l'organisme tiers effectue une condensation puis un cryptage des données avec une clef privée. Bien entendu, la clef publique de l'organisme est à la disposition de tous. En fait, les pré-réglages des explorateurs comme Internet Explorer incluent une liste d'organismes certificateurs. En voici un exemple : Installation et administration d un serveur web 5

8 SSL et Apache 6

9 La liste des organismes certificateurs déclarés est longue Pour résumer, si vous vous connectez sur un site SSL dont le certificat est signé par l'un des organismes déclaré sur votre explorateur, vous n'aurez pas d'alerte de sécurité car le site sera crédité d'un certain niveau de confiance. La première étape du schéma de base des échanges entre serveur SSL et client devient donc : Installation et administration d un serveur web 7

10 1. Envoi du certificat contenant la clef publique du serveur et crypté par la clef privée du certificateur Le client possède la clef publique de l'organisme de certification en pré-réglage Client Serveur Clef publique Clef publique Clef privée Certificateur Clef privée Si le certificat n'est pas signé par un organisme reconnu, vous aurez une alerte au moment de la connexion au serveur https comme ci-dessous : Ce sera à vous de décider si vous pouvez faire confiance ou non à ce site. L'effet est plutôt désastreux sur un client qui ne connaît pas le site et qui ne sait pas encore s'il doit lui accorder sa confiance. Il est donc fortement conseillé de se faire signer un certificat par un organisme réputé "sérieux". La procédure à suivre est la suivante : On génère la paire de clefs puis on s'adresse à l'organisme certificateur en lui envoyant une demande, la clef publique, les justificatifs demandés (inscription au registre du commerce, preuve de la possession du nom de domaine ), et le prix fixé (comptez 200$ par an au minimum). SSL et Apache 8

11 5. LA CONFIGURATION INSTALLEE PAR DEFAUT Vous avez installé une distribution RedHat ou Mandrake. OpenSSL est probablement déjà installé. Testez le fonctionnement avec un Examinez le certificat proposé. Les fichiers de configurations relatifs au fonctionnement de SSL et d'apache sont dans le répertoire /etc/httpd/conf/ssl. Les clefs et certificats sont dans le répertoire /etc/ssl/apache. L'activation de SSL est effectué avec la directive SSLengine on. Repérez cette directive. Cette directive peut s'utiliser dans un contexte serveur ou d'hôte virtuel. On peut forcer l'accès SSL à un répertoire avec la directive SSLrequireSSL admise dans des conteneurs Directory ou Location. 6. CREATION DE CLEFS ET D'UN CERTIFICAT DE TEST OpenSSL va vous servir à créer des clefs et des certificats non signés par un organisme officiel. Cela sera suffisant pour des tests ou dans le cadre d'un intranet. Nous allons commencer par créer une clef au standard rsa, privée, de 1024 bits. L'algorithme de cryptographie utilisé sera "des3" réputé résistant. Notez le nom (localhost) de votre serveur web. Ouvrez une console en tant que root et créez vous un dossier /etc/httpd/conf/clefs Installation et administration d un serveur web 9

12 Déplacez vous dans ce dossier et exécutez la commande : openssl genrsa des > localhost.key Un mot de passe vous sera demandé (toto). Nous allons créer maintenant le fichier requête pour une demande de certificat avec la commande : openssl req -new -key localhost.key -out localhost.csr Répondez aux questions posées ou simplement tapez "." si vous ne souhaitez pas compléter un champ. SSL et Apache 10

13 Nous allons enfin créer le certificat provisoire avec la commande (sur une ligne) : openssl req x509 -key localhost.key -in localhost.csr -out localhost.crt Il ne reste qu'à déclarer les fichiers localhost.key et localhost.crt à la place de ceux utilisés dans le fichier /etc/httpd/conf/ssl/ssl.default-vhosts.conf Le seul problème est qu'il faudra entrer le mot de passe au prochain démarrage d'apache. Il va falloir passer automatiquement votre mot de passe au démarrage en changeant la valeur de la directive SSLPassPhraseDialog (actuellement à builtin) du fichier mod_ssl.conf. Créez un fichier /etc/httpd/conf/clefs/sslpasswd, éditez-le et, si votre mot de passe est "toto" entrez : #!/bin/sh echo toto Rendez ce fichier exécutable puis modifiez la ligne SSLPassPhraseDialog du fichier mod_ssl.conf comme suit : SSLPassPhraseDialog exec:/etc/httpd/conf/clefs/sslpasswd Vous pouvez redémarrer Apache et tester l'accès au site sécurisé avec un navigateur. Installation et administration d un serveur web 11

14 7. ANNEXE LE FICHIER MOD_SSL.CONF <IfModule mod_ssl.c> ## ## Add additional SSL configuration directives which provide a ## robust default configuration: virtual server on port 443 ## which speaks SSL. ## ## ## SSL Support ## ## When we also provide SSL we have to listen to the ## standard HTTP port (see above) and to the HTTPS port ## Listen 443 ## ## SSL Global Context ## ## All SSL configuration in this context applies both to ## the main server and all SSL-enabled virtual hosts. ## # # Some MIME-types for downloading Certificates and CRLs # AddType application/x-x509-ca-cert.crt AddType application/x-pkcs7-crl.crl # Pass Phrase Dialog: # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout. SSLPassPhraseDialog builtin # Inter-Process Session Cache: # Configure the SSL Session Cache: First either `none' # or `dbm:/path/to/file' for the mechanism to use and # second the expiring timeout (in seconds). #SSLSessionCache none #SSLSessionCache dbm:logs/ssl_scache SSLSessionCache shm:logs/ssl_scache(512000) SSLSessionCacheTimeout 300 # Semaphore: # Configure the path to the mutual explusion semaphore the # SSL engine uses internally for inter-process synchronization. SSLMutex sem # Pseudo Random Number Generator (PRNG): # Configure one or more sources to seed the PRNG of the # SSL library. The seed data should be of good random quality. SSL et Apache 12

15 SSLRandomSeed startup builtin SSLRandomSeed connect builtin #SSLRandomSeed startup file:/dev/random 512 #SSLRandomSeed startup file:/dev/urandom 512 #SSLRandomSeed connect file:/dev/random 512 #SSLRandomSeed connect file:/dev/urandom 512 # Logging: # The home of the dedicated SSL protocol logfile. Errors are # additionally duplicated in the general error log file. Put # this somewhere where it cannot be used for symlink attacks on # a real server (i.e. somewhere where only root can write). # Log levels are (ascending order: higher ones include lower ones): # none, error, warn, info, trace, debug. SSLLog logs/ssl_engine_log SSLLogLevel info </IfModule> 7.2. LE FICHIER SSL.DEFAULT-VHOST.CONF <IfModule mod_ssl.c> ## ## SSL Virtual Host Context ## <VirtualHost _default_:443> # General setup for the virtual host DocumentRoot /var/www/html #ServerName new.host.name #ServerAdmin you@your.address ErrorLog logs/ssl-error_log TransferLog logs/ssl-access_log # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A test # certificate can be generated with `make certificate' under # built time. SSLCertificateFile /etc/ssl/apache/server.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Installation et administration d un serveur web 13

16 SSLCertificateKeyFile /etc/ssl/apache/server.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details. #<Location /> #SSLRequire ( %{SSL_CIPHER}!~ m/^(exp NULL)-/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ #</Location> # SSL Engine Options: # Set various options for the SSL engine. # FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that SSL et Apache 14

17 # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31zmtzzkva'. # ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # CompatEnvVars: # This exports obsolete environment variables for backward compatibility # to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this # to provide compatibility to existing CGI scripts. # StrictRequire: # This denies access when "SSLRequireSSL" or "SSLRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown # Per-Server Logging: # The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis. CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" RewriteEngine On RewriteOptions inherit </VirtualHost> </IfModule> Installation et administration d un serveur web 15