Corso di Proge+azione di Re0 e Sistemi Informa0ci Apache web server: ConceI avanza0 (Lezione 2, Parte I) Emiliano Casalicchio emiliano.casalicchio@uniroma1.it
Agenda ConceI e pra0ca sul Virtual hos0ng Il supporto SSL/TLS in apache (h+ps) Caching Proxying
Virtual Host h+p://h+pd.apache.org/docs/2.2/vhosts/ The term Virtual Host refers to the prac0ce of running more than one web site (such as www.company1.com and www.company2.com) on a single machine. Virtual hosts can be "IP based", meaning that you have a different IP address for every web site, or "name based", meaning that you have mul0ple names running on each IP address. The fact that they are running on the same physical server is not apparent to the end user. Name based virtual host (h+p://h+pd.apache.org/docs/2.2/vhosts/name based.html) Consiglio: in fase di test per associare più nomi all indirizzo 127.0.0.1 u0lizzare il file / etc/hosts
IP based virtual host h+p://h+pd.apache.org/docs/2.2/vhosts/ip based.html As the term IP based indicates, the server must have a different IP address for each IP based virtual host. This can be achieved by the machine having several physical network connec0ons, or by use of virtual interfaces which are supported by most modern opera0ng systems (see system documenta0on for details, these are frequently called "ip aliases", and the "ifconfig" command is most commonly used to set them up). There are two ways of configuring apache to support mul0ple hosts. Either by running a separate h+pd daemon for each hostname, or by running a single daemon which supports all the virtual hosts. Use mul0ple daemons when: There are security par00oning issues You can afford the memory and file descriptor requirements of listening to every IP alias on the machine. Use a single daemon when: Sharing of the h+pd configura0on between virtual hosts is acceptable. The machine services a large number of requests, and so the performance loss in running separate daemons may be significant.
singolo demone h+pd
Esempi Virtual Hos0ng Running several name based web sites on a single IP address. Name based hosts on more than one IP address. Serving the same content on different IP addresses (such as an internal and external address). Running different sites on different ports. IP based virtual hos0ng Mixed port based and ip based virtual hosts Mixed name based and IP based vhosts http://httpd.apache.org/docs/2.2/vhosts/examples.html Crea0ng virtual host configura0ons on your Apache server does not magically cause DNS entries to be created for those host names. You must have the names in DNS, resolving to your IP address, or nobody else will be able to see your web site. You can put entries in your hosts file for local tes@ng, but that will work only from the machine with those hosts entries.
Esercizio Provare la configurazione di Name base virtual host associando piu si0 allo stesso indirizzo IP associando piu si0 a indirizzi IP e porte diverse. Facolta0vo, provare IP based virtual hosts associando piu IP alla stessa scheda di rete.
Agenda ConceI e pra0ca sul Virtual hos0ng Il supporto SSL/TLS in apache (h+ps) Introduzione Cifratura in Apache Auten0cazione client e controllo d accesso in apache Caching Regole di riscri+ura
Introduzione a SSL/TLS Secure Socket Layer / Transport Layer Security tecniche di cri+ografia Chiave simmetrica (o convenzionale) Chiave pubblica, Diggest, Digital signature Conce+o di cer0ficato Il protocollo SSL
Symmetric cryptography Alice Bank A,B are required to share a key: a secret piece of informa0on that may be used to encrypt or decrypt a message. As long as this key is kept secret, nobody other than the sender or recipient can read the message. The task of sharing a key between sender and recipient before communica0ng, while also keeping it secret from others, can be problema0c.
Public key cryptography Solves the key exchange problem by defining an algorithm which uses two keys, each of which may be used to encrypt a message. If one key is used to encrypt a message then the other must be used to decrypt it. This makes it possible to receive secure messages by simply publishing one key (the public key) and keeping the other secret (the private key). Alice Bank B publish PuK_B A crypt M by using PuK_B A send (M,PuK_B) to B B decrypt (M,PuK_B) by using Pr_B
Problems with Public Key cryptography Integrity viola0on: A M B M might modify her original message or subs0tute it with a different one One way of guaranteeing the integrity of A s message is for her to create a concise summary of her message and send this to the bank as well. Upon receipt of the message, the bank creates its own summary and compares it with the one Alice sent. If the summaries are the same then the message has been received intact. Message summary = Diggest How B can be sure the message M is from A? Digital Signature
Message Disgest, one way func0on or hash func0on A: H(M)=D, A send M,D to B, B: H(M)=D, D =D? Message digests are used to create a short, fixed length representa0on of a longer, variable length message. Digest algorithms are designed to produce a unique digest for each message. Message digests are designed to make it imprac0cally difficult to determine the message from the digest and (in theory) impossible to find two different messages which create the same digest thus elimina0ng the possibility of subs0tu0ng one message for another while maintaining the same digest. Another challenge that A faces is finding a way to send the digest to the bank securely; Only if the digest is sent securely can the integrity of the associated message be determined.
Digital Signature Digital signatures are created by encryp0ng a digest of the message and other informa0on (such as a sequence number) with the sender's private key. Though anyone can decrypt the signature using the public key, only the sender knows the private key. This means that only the sender can have signed the message. Including the digest in the signature means the signature is only good for that message; It also ensures the integrity of the message since no one can change the digest and s0ll sign it. To guard against intercep0on and reuse of the signature by an intruder at a later date, the signature contains a unique sequence number. This protects B from a fraudulent claim from A that she did not send the message only she could have signed it (non repudia0on).
Summarizing 1. A, PuK_A, PrK_A 2. B, PuK_B, PrK_B 3. A produce the dig.sig. of M S_M=f(PrK_A, (H(M),I,sn)) 4. A send f(puk_b, M), S_M to B A s0ll needs to be sure that she is really communica0ng with B. This means that A needs to be sure that the public key she is using is part of the B's key pair, and not an intruder's. B needs to verify that the message signature really was signed by the private key that belongs to A. If each party has a cer0ficate which validates the other's iden0ty, confirms the public key and is signed by a trusted agency, then both can be assured that they are communica0ng with whom they think they are. Such a trusted agency is called a Cer0ficate Authority and cer0ficates are used for authen0ca0on.
Introduzione a SSL/TLS Secure Socket Layer / Transport Layer Security tecniche di cri+ografia Chiave simmetrica (o convenzionale) Chiave pubblica, Diggest, Digital signature Conce+o di cer0ficato Il protocollo SSL
SSL The Secure Sockets Layer protocol is a protocol layer which may be placed between a reliable connec0on oriented network layer protocol (e.g. TCP/IP) and the applica0on protocol layer (e.g. HTTP). SSL provides for secure communica0on between client and server by allowing mutual authen0ca0on, the use of digital signatures for integrity and encryp0on for privacy.
SSL The protocol is designed to support a range of choices for specific algorithms used for cryptography, digests and signatures. This allows algorithm selec0on for specific servers to be made based on legal, export or other concerns and also enables the protocol to take advantage of new algorithms. Choices are nego0ated between client and server when establishing a protocol session.
Versions of SSL protocol
SSL handshake Once an SSL session has been established, it may be reused To do this, the server assigns each SSL session a unique session iden0fier which is cached in the server and which the client can use in future connec0ons to reduce the handshake 0me
SSL handshake The elements of the handshake sequence, as used by the client and server, are listed below: 1. Nego0ate the Cipher Suite to be used during data transfer Key Exchange Method Cipher for Data Transfer Message Digest for crea0ng the Message Authen0ca0on Code (MAC) 2. Establish and share a session key between client and server 3. Op0onally authen0cate the server to the client 4. Op0onally authen0cate the client to the server
SSL Record Protocol
Agenda ConceI e pra0ca sul Virtual hos0ng Il supporto SSL/TLS in apache (h+ps) Introduzione Cifratura in Apache Auten0cazione client e controllo d accesso in apache Caching Regole di riscri+ura
Apache mod_ssl: Cipher Suites and Enforcing Strong Security How can I create a real SSLv2 only server? http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html How can I create an SSL server which accepts strong encryp0on only? How can I create an SSL server which accepts all types of ciphers in general, but requires a strong cipher for access to a par0cular URL?
Apache mod_ssl: Client Authen0ca0on and Access Control http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html How can I force clients to authen0cate using cer0ficates? How can I force clients to authen0cate using cer0ficates for a par0cular URL, but s0ll allow arbitrary clients to access the rest of the server? How can I allow only clients who have cer0ficates to access a par0cular URL, but allow all clients to access the rest of the server? How can I require HTTPS with strong ciphers, and either basic authen0ca0on or client cer0ficates, for access to part of the Intranet website, for clients coming from the Internet?
How can I force clients to authen0cate using cer0ficates? When you know all of your users (eg, as is olen the case on a corporate Intranet), you can require plain cer0ficate authen0ca0on. All you need to do is to create client cer0ficates signed by your own CA cer0ficate (ca.crt) and then verify the clients against this cer0ficate. 1 means the client certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA's certificate is under SSLCACertificatePath) How to generate an SSL certificate: http://slacksite.com/apache/certificate.php http://www.tc.umn.edu/~brams006/selfsign.html
How can I force clients to authen0cate using cer0ficates for a par0cular URL, but s0ll allow arbitrary clients to access the rest of the server?
How can I allow only clients who have cer0ficates to access a par0cular URL, but allow all clients to access the rest of the server?
When your clients are all part of a common hierarchy, which is encoded into the DN, you can match them more easily using SSLRequire, as follows: