Redirect a client from http://domain/uri to https://domain/uri without
transmitting a single byte of the clients request over the network
(except the HTTP method). URI, Cookies, User-Agent, Host, ... are not
transmitted, if a user accidentally visits your website over
unsecured HTTP.

Approach:
The server's receive window is set to 4 byte during TCP handshake and
no data (beyond the handshake) is ever acknowledged. Before the client
tries to send its request the server already unconditionally pushes a
redirecting response. To implement this deviation in the handshake,
the server is implemented using packet sockets and SOCK_RAW.

Redirection:
Three schemes are supported. 1 and 2 are used in combination.
1. If the client allows Javascript, replace ^http with https in
   location.href
2. Use refresh-after meta tag to load https://newdomain/forcessl_nojs
   and use referrer analysis (if possible) to detect from which URI
   the user came
3. Use a HTTP 301 redirect to https://newdomain/forcessl_nojs

In case 2 and 3 newdomain is either a command line specified domain or
the IP address of the server.

Usage:
You have to prevent your machine to answer on port 80 using iptables
as sslforce operates outside the linux TCP/IP stack:
iptables -A INPUT -p tcp --dport 80 -j DROP

Then you can start forcessl, e.g.
forcessl -i eth0 -h yourdomain.com

Full command line spec:
forcessl -i interface [-3|-j] [-p port] [-h target-host]
        -i interface to listen on
        -3 use HTTP 301 reponses for redirection
        -j use Javascript with Meta-Refresh as fallback for redirection (default)
        -p port to listen (default: 80)
        -h hostname of the redirection target; if unspecified the request destination IP is used


Caveats:
- only method 3 (redirection via 301) works with non-standard HTTP
  clients (e.g. spiders)
- violates HTTP protocol by sending unconditional status codes
  (especially when the user submitted something different than a plain
  get)
- right now allows DoS multiplication due to a lack of randomness in
  the initial sequence number (easily fixable)
- relies on the client to not check that all of its request have left
  the client OS buffers (otherwise the client stalls)
- needs root-access even for non-privileged ports
- replies to all HTTP requests of the network, if the interface is in
  promiscuous mode

TODO:
- set up/remove iptable DROP rule on startup/termination
- implement example landing page
- prevent abuse of the server as DoS bandwidth multiplication