Virtual Machine: HTTP Server

Intro/overview

How about making a web server?

Creating and configuring a “child image”

See: creating and configuring a “child image”.

Locate/Plan content

If there isn't a pre-created set of content to be used, then content can be rapidly created as needed. (The key reason that this can be done so rapidly is that a simple text file, containing visible (non-“white space”) text, can work as sample web content. So, creating content does not need to be a lengthy process.) Some details about creating proper HTML are provided by section decribing HTML.

If there is some pre-created content that is available, find out where it is. People who are part of a formal class may wish to check for instructions on accessing the content. Common methods might be:

  • Downloading a compressed archive
  • The content could be on another server, accessed using a “remote filesystem”. (Having the content be remotely loaded on demand might be an idea which is disasterous from a “speed”/“performance” perspetive, but might be rather simple and easy to set up. At least in theory, caching (using a “cache”) could tremendously help with speed issues.)
Choose the web server software

You could actually have multiple web servers, even operating on the same host at the same time. However, only one is going to be listening to TCP port 80, and only one is going to be listening to TCP port 443.

  • This guide currently focuses most on using OpenBSD's httpd (introduced with OpenBSD 5.6).
  • Other alternatives may include nginx (pronounced “nginx”) or Apache. This guide might soon use the OpenBSD-enhanced variation of Apache (www/apache-httpd-openbsd based on Apache 1.3, not www/apache-httpd based on Apache 2).
Install web server

Many operating systems will have a “web server” pre-installed. If not, determine the name of the package, and install it.

Further details may be available at:

Configuring web server
OpenBSD httpd configuration
See: OpenBSD httpd configuration.
Placing content

Presumably, by the time the web server's configuration file is made, there is a good understanding of where the content will be loaded from.

  • Make any directory that is needed
  • Place content

The instructions are available: accessing shares (directory listing), e.g. using Sharity-Light.)

Handling firewalls for internal traffic
On the web server
OpenBSD PF
cpytobak /etc/pf.conf
echo \# Permit TCP traffic that WWW typically uses| sudo -n tee -a /etc/pf.conf
echo pass in quick proto tcp to self port { http https } modulate state| sudo -n tee -a /etc/pf.conf
echo ${VISUAL}
sudoedit /etc/pf.conf

Make sure to customize the IP addresses. If all looks well, proceed.

sudo pfctl -nf /etc/pf.conf
echo ${?}
sudo pfctl -nf /etc/pf.conf&&sudo pfctl -ef /etc/pf.conf
On the “firewall” “virtual machine”
OpenBSD PF
cpytobak /etc/pf.conf
echo| sudo -n tee -a /etc/pf.conf
echo \# Permit TCP range that WWW may use| sudo -n tee -a /etc/pf.conf
echo pass in quick proto tcp to { 2001:db8:1::81 198.51.100.81 self } \\| sudo -n tee -a /etc/pf.conf
echo \\tport { http https } keep state| sudo -n tee -a /etc/pf.conf
echo pass out quick on \$vmSvrs_if proto tcp \\| sudo -n tee -a /etc/pf.conf
echo \\tto { 2001:db8:1::81 198.51.100.81 }\\| sudo -n tee -a /etc/pf.conf
echo \\tport { http https } keep state| sudo -n tee -a /etc/pf.conf
echo| sudo -n tee -a /etc/pf.conf
echo \# redirect WWW traffic| sudo -n tee -a /etc/pf.conf
echo pass in quick inet6 proto tcp to self port { http https } \\| sudo -n tee -a /etc/pf.conf
echo \\trdr-to 2001:db8:1::81| sudo -n tee -a /etc/pf.conf
echo pass in quick inet  proto tcp to self port { http https } rdr-to 198.51.100.81| sudo -n tee -a /etc/pf.conf
echo ${VISUAL}
sudoedit /etc/pf.conf

Make sure to customize the IP addresses. If all looks well, proceed.

sudo pfctl -nf /etc/pf.conf
echo ${?}
sudo pfctl -nf /etc/pf.conf&&sudo pfctl -ef /etc/pf.conf
Starting the web server
Starting OpenBSD httpd
See: Starting OpenBSD httpd.
Adjusting start-up
Starting web server
OpenBSD
Newer versions
cpytobak /etc/rc.conf.local
echo httpd_flags=\"\"|sudo -n tee -a /etc/rc.conf.local

If you dare to restart the server:

$ sudo /etc/rc.d/httpd restart
httpd(ok)
httpd(ok)
$

instead of:

$ sudo /etc/rc.d/httpd restart
httpd(ok)
/etc/rc.d/httpd: need -f to force start since httpd_flags=NO
$
Older versions

Older versions did have some differences, being bundled with nginx or Apache. The startup procedure might have been similar or identical... (The author of this text is not currently making a statement, here, about how to do this with such old OpenBSD versions.)

Mounting content

If some of the web content is on a remote machine, make sure that becomes accessible. For example, if content is on an SMB share, then access that share. Ideally, this should occur before the web server responds, so that the results are either an unresponsive web server or a successful web delivery. (If the web server is started first, the web server might be unable to find the content. The worst part of this is that such bad results might be cached (perhaps an experience related to using Sharity-Light?), so the web server might continue to give bad results for some time afterwards. Another really bad part is that web server may provide a clear statement informing visitors that a file does not exist at that address. (This would be a “404” error.) Such a response may discourage visitors, including automated web spiders, from thinking that the address typically goes to a valid resource.

Here is a list of reference(s) that may be helpful:

Supporting CGI

If CGI is desirable (and this is recommended for people who are performing this process for educational purposes), see: using CGI.

Using HTTPS

Choose a provider of certificates. Options include:

Self-generated

Technically, this is an option, although generally clients will complain. The solution is to have clients trust the certificate. That may be fine if you can automatically deploy certificates, which may be feasible if people only connect using devices that IT administrators have. This option may also be fine if you don't mind having people install certificates.

Perhaps a better option is to use on of the free “public” certificate providers.

Further details are not available here at this time.

Free public certificates

For a long time, there was basically just one provider that was widely supported by many browsers. That was StartSSL. The key reason that more providers didn't crop up over the years is that many people did not find a certificate provider to be useful unless the certificate provider was already supported, by default, in popular web browsers, and the creators of the popular web browsers were rather reluctant to support new certificate providers.

After the activities of the United States of America's National Security Agency (USA's NSA) became more unpopular, people successfully started a movement to have a second provider, which is called “Let's Encrypt”.

StartSSL

StartSSL offers some certificates for free. Details are at: StartSSL Certificates (intended for HTTPS).

“Let's Encrypt”

Further details have been placed on the page about using Let's Encrypt.

At the time of this writing (November 24, 2015), “Let's Encrypt” has not yet entered “the first public beta” (as phrased on Wikipedia's article on “Let's Encrypt”: “History and schedule” section). However, that is scheduled to start on December 3 (about a week and a half after this was written), so by the time you're reading this, “Let's Encrypt” may have started to be an option.

This guide will probably not provide more information extremely soon after the start of the public beta, and perhaps not even until after the “public beta” has completed.

Note: This guide may be currently rather incomplete... It may assume a freely-creatable account already exists. More details about creating that account will be added as a good opportunity arises.)

Commercial certificates which cost

These are rather commonly supported.

Whether providers matter

At least in theory, pricier providers may provide some superior benefits, such as certifictes created with stronger encryption keys and servers that can verify certificates more quickly. For organizations with large budgets, the costs of pricier certificates may be negligible, and so such organizations may tend to lean towards using certain providers despite the higher costs. For many years, Verisign has been the most well-known name for being a “root” certificate authority.

In practice, most end users who are seeking low-budget solutions may notice little to no difference between different providers. One of the reasons for this might be the heavy market concentration, which has caused even low-cost providers to be owned by larger organizations.

HTTPS Market Concentration

Security Collapse in the HTTPS Market discusses some findings from studies where “projects systematically scanned the entire IPv4 address space, looking for publicly facing HTTPS servers. They retrieved the SSL certificates presented by these servers and later parsed” to determine some details about the certificates.

One finding notes “a major risk for the HTTPS ecosystem: if one of the large CAs is compromised, its root status cannot be revoked by browser vendors without massive collateral damage. One particular CA of GoDaddy had signed 26 percent of all valid HTTPS certificates in March 2013. That means if it were compromised, 26 percent of all Web sites that rely on HTTPS would need to be immediately issued new certificates.”

Earlier, the same paragraph notes: “around 75 percent of SSL certificates in use on the public Web have been issued by just three companies: Symantec, GoDaddy, and Comodo. Symantec, the largest commercial CA, owns multiple brands, including Verisign, GeoTrust, Thawte, RapidSSL, and TC TrustCenter. The distribution is heavily skewed, with smaller CAs having little or no presence on the public Internet.”

Tim Brigham's answer to Luke Sheppard's InfoSec (Security.StackExchange.com) question on cheap SSL certificates, and related comments, indicate that one of the reasons that some organizations pay for pricier certificates is to reduce the chance of relying on a provider that is small enough to fail, which could cause inconvenience for the certificate purchaser if the certificate authority had problems.

There may be some differences between the certificates, such as “Extended Validation” (“EV”) certificates being trusted more than “Domain Validated” (“DV”) or “Organization Validated” (“OV”) certifictes. (For instance, web browsers may show a different color for the background of the address bar.) Security Collapse in the HTTPS Market notes, “certificates themselves are perfect substitutes (within each validation category).”

If the main goal is simply getting HTTPS to function easily for end users, there is very little reason to worry about one provider compared to another, as long as major web browsers support the certificate. Why your certificate authority rarely matters, and expensive certificates are not safer refers to “any of the 377 CAs” that Firefox trusted. (The article was written in February of 2014.)

Some known providers
StartSSL
Altruism

This company has been unique in supporting low-budget projects, by freely providing limited SSL certificates that are useful for HTTPS. Although these certificates do have some lilmits, they are much more useful than other certificate authorities which have not offered usable SSL certificates for free.

StartSSL FAQ: Can I make a donation says, “Thank you for your interest, but we prefer to see your support through the purchase of one of our products.” They're basically declining donations, but do like purchases.

Projects that do have the budget for a more expensive certification may help by showing appreciation to this helpful organization.

Password-protecting content

Note that passwords can be easily sniffed whenever somebody logs in, so no passwords should be sent over untrusted communications. For this reason, password-protected content should generally only be sent over HTTPS and not HTTP.

Older/Misc notes/HTML code:

Configure
OpenBSD httpd
have web content be mounted somewhere under the chroot location, which defaults to /var/www/
nginx

Some older (and possibly a bit incomplete/less-tested) details may be available at: nginx page.

Apache

Some older (and possibly a bit incomplete/less-tested) details may be available at: apache page which probablya ssumed that it was pre-installed.

Misc note(s):
https://github.com/reyk/httpd/wiki/Running-ownCloud-with-httpd-on-OpenBSD