blob: 4e6a6c635b7270d47a3d8cd37c6c1fd32d30fd64 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
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
|
