[ILUG] http/https

[Colm Buckley]

On 10/04/07, Timothy Murphy <tim at birdsnest.maths.tcd.ie> wrote:
>
> I don't really understand http/https.


HTTPS is exactly the same as HTTP (ie : the client and server send the same
requests/responses) except that HTTPS takes place over a SSL-encrypted
connection.  When the client connects to the server, the first thing which
happens is that they exchange certificates (the most common case has only
the server sending a certificate, and the client checking it against the
public database) and negotiate an encrypted session (SSL contains a protocol
for deciding on a cipher and key to use).  Once the crypto negotiation is
concluded, the HTTP request and response are sent as normal along the
encrypted channel; it is generally assumed that the HTTP conversation is
then proof against external snooping.  See
http://en.wikipedia.org/wiki/Https

Can one run both on the same IP address?


Yes.  Except they must run on different ports; the convention (and default)
is to have HTTP running on port 80 with HTTPS running on port 443.

If so, how exactly does one set up https on httpd (apache)?


See for example the following stanza from the httpd configuration on the
ILUG server morrigan:

<VirtualHost *:443>
        ServerName linux.ie
        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/linux_ie.pem
        SSLCertificateKeyFile /etc/ssl/private/linux_ie.pem
        DocumentRoot /home/ilug/www.linux.ie
        CustomLog /home/ilug/logs/www.linux.ie-access.log combined
        ErrorLog /home/ilug/logs/www.linux.ie-error.log
        ErrorDocument 404 /missing.php
        ServerAdmin webmaster at linux.ie
        DirectoryIndex index.php
</VirtualHost>

The <VirtualHost> directive instructs Apache to create a new virtual host -
a new http listener.  *:443 means "this server runs on port 443 on all IP
addresses" - Apache having previously been instructed to listen on port 443
using the Listen directive.  Most of the directives in that stanza
(everything from DocumentRoot onwards) are exactly as they would appear in a
non-HTTPS virtual host, but the SSL directives are where it gets
interesting:

   - "SSLEngine on" tells Apache to use HTTPS on this VirtualHost
   - "SSLCertificateFile" and "SSLCertificateKeyFile" tell it the
   location of the public certificate file and the private key file
   respectively

These certificate files are generated by a SSL utility set - usually
openssl.  The usual sequence is:

   - "openssl req" is called to create a private key and certificate
   request
      - This request will contain the name of the website (the
      hostname) you wish to publish
      - The certificate request is sent to a public certificate vendor
   - The vendor supplies a x509 certificate
   - The private key and x509 certificate are supplied to Apache using
   the directives above

Certificate vendors are in possession of one or more of the SSL "root
certificates" (http://en.wikipedia.org/wiki/Root_certificate) which are
distributed with most browsers and SSL utility sets.  They use these
certificates to cryptographically sign the certificate which they supply to
you, after taking steps to verify that you are the legitimate owner of the
website in question.  (Different vendors apply different levels of diligence
at this stage, which is in theory supposed to be a differentiator between
cert vendors.)  A client browser, upon receipt of your website's certificate
at the HTTPS negotiation stage, can verify that the certificate has been
signed by one of the trusted root certificates, and can thereby verify that
the site being connected to is "who it claims to be".

As an example, if you connect to https://linux.ie/ and double-click on the
padlock icon on the status bar (assuming you're using Firefox) - or select
"Page Info" or "Certificate Info" according to your browser's abilities, you
will be able to view the certificate supplied by the website.  In the case
of the linux.ie certificate, it was issued by Equifax, and has been signed
using the "Equifax Secure Global eBusiness CA-1" root certificate.  It
expires on August 27th; if I don't renew it before then, your browser would
generally give a warning that the certificate has expired and that you
shouldn't trust the website contents.  Certificates, depending on the
issuing authority and the diligence of their verification process, cost
between $60 and $300 per year.

If all you care about is encrypted communications, and not the public
verification of the website's owner, you can generate self-signed
certificates using openssl - ie: sign them yourself instead of submitting
them to a public certificate authority.  Such certificates are just as
secure as public certificates, but browsers will not accept them
automatically; they will bring up a warning when first connecting - however
you are usually given the option to accept the certificate permanently (the
browser will store it in its local certificate store).  You should however
take some steps to ensure that you have received the correct certificate
before doing this, to eliminate the possibility of a man-in-the-middle
attack.

Wikipedia and Google have lots more information.  I have no doubt that Rick
Moen's site will also have a useful document or three.

Hope this helps,

Colm

-- 
Colm Buckley / colm at tuatha.org / +353 87 2469146