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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
/*!
This crate presents a clean and simple interface to the HexPawb network.
If you wanted to, say, load `https://www.torproject.org/` through HexPawb,
you'd just need to:
```no_run
use hexpawb::Network;
// First you need to connect to the HexPawb network
let mut network = Network::connect().await
.expect("Failed to join network");
// Then you can create a circuit
let mut circuit = network.circuit().await
.expect("Failed to build circuit");
// Then you can connect to something over that circuit (this does DNS
// through the circuit, but to your system's configured DNS servers)
let mut connection = circuit.tcp("www.torproject.org:80").await
.expect("Failed to connect circuit");
// TCP connections work basically just like the stdlib's TcpStream,
// but async.
connection.send("GET / HTTP/1.1\r\nConnection: close\r\n\r\n").await
.expect("Failed to send request");
std::io::copy(circuit, std::io::stdout().lock()).await
.expect("Failed to receive body");
```
# Breaking privacy
***If and only if*** you know exactly what you're doing and you can state
in clear, uncertain terms precisely why you need to do it, you can enable
the lower-level API with feature `dangerous-low-level-bits`. If you don't
use it exactly right, you'll break your own anonymity irrecoverably. This
enables functionality like:
```ignore
use hexpawb::Network;
let mut network = Network::builder()
.authority(custom_authority)
.connect().await
.expect("Failed to join network");
let mut circuit = network.tcp("www.torproject.org:90")
.length(10)
.relay(specific_relay)
.connect().await
.expect("Failed to connect circuit");
circuit.send("GET / HTTP/1.1\r\nConnection: close\r\n\r\n").await
.expect("Failed to send request");
std::io::copy(circuit, std::io::stdout().lock()).await
.expect("Failed to receive body");
```
*/
use task;
use ;
use ;
pub type PawbResult<T> = ;
/**
Represents the current known state of the HexPawb network. Allows you to
build new circuits to arbitrary IPs, look up and connect to furtives, etc.
Unless you're in the dangerous mode, the only way to connect is with the
[`connect`](Network::connect) method.
Once you're connected to the network, you can establish a circuit with
[`circuit`](Network::circuit), which handles everything for you.
*/
/**
Builder-pattern struct for constructing custom networks. Construct one with
[`Network::builder`].
*/
/**
A directory authority on the HexPawb network. Used primarily to validate that
various items are properly authenticated.
*/
/**
A single path through the HexPawb network, which has been set up and is ready
to have traffic flow over it.
# Choosing Circuits
***This is important***. Please read it fully. I know it's a lot.
Deciding when to create a new circuit is difficult. You could make one, total,
and use that for everything; that leaves you bottlenecked at the bandwidth of
the circuit and vulnerable to traffic correlation. You could make one for each
new connection, but that means every single connection takes ages to start,
which just won't work if you're for example rendering a modern webpage.
As a rule of thumb, treat circuits like their own independent connections to
the internet, and use them to isolate things that should be isolated. Users
should be separated, individual actions should be separated, etc.
However, this decision is ultimately protocol-dependent and fundamentally not
easy. To make the best decision, you'll want to keep in mind:
- What data can an attacker in the middle discover?
- TLS can expose hostnames
- The computer's DNS server may be identifiable to varying degrees
- The protocol you're sending might not even be encrypted
- If an attacker sees all that coming from one IP, what do they learn?
- If the same accounts are always accesssed from the same IP, even if that
address is a HexPawb exit they can still be correlated
- What's the best way to spread out the traffic source to avoid that?
It may help to get out a notebook -- digital or physical -- and spend a day or
two hunting all this information down.
*/