3 ## 10.9 VPN over IPsec
\r
5 ***Written by Nik Clayton. ***
\r
7 Creating a VPN between two networks, separated by the Internet, using DragonFly gateways.
\r
9 ### 10.9.1 Understanding IPsec
\r
11 ***Written by Hiten M. Pandya. ***
\r
13 This section will guide you through the process of setting up IPsec, and to use it in an environment which consists of DragonFly and **Microsoft® Windows® 2000/XP** machines, to make them communicate securely. In order to set up IPsec, it is necessary that you are familiar with the concepts of building a custom kernel (see [kernelconfig.html Chapter 9]).
\r
15 ***IPsec*** is a protocol which sits on top of the Internet Protocol (IP) layer. It allows two or more hosts to communicate in a secure manner (hence the name). The DragonFly IPsec ***network stack*** is based on the [KAME](http://www.kame.net/) implementation, which has support for both protocol families, IPv4 and IPv6.
\r
17 IPsec consists of two sub-protocols:
\r
20 * ***Encapsulated Security Payload (ESP)***, protects the IP packet data from third party interference, by encrypting the contents using symmetric cryptography algorithms (like Blowfish, 3DES).
\r
22 * ***Authentication Header (AH)***, protects the IP packet header from third party interference and spoofing, by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated.
\r
24 ESP and AH can either be used together or separately, depending on the environment.
\r
26 IPsec can either be used to directly encrypt the traffic between two hosts (known as ***Transport Mode***); or to build ***virtual tunnels*** between two subnets, which could be used for secure communication between two corporate networks (known as ***Tunnel Mode***). The latter is more commonly known as a ***Virtual Private Network (VPN)***. The [ipsec(4)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipsec§ion4) manual page should be consulted for detailed information on the IPsec subsystem in DragonFly.
\r
28 To add IPsec support to your kernel, add the following options to your kernel configuration file:
\r
31 options IPSEC #IP security
\r
32 options IPSEC_ESP #IP security (crypto; define w/ IPSEC)
\r
36 If IPsec debugging support is desired, the following kernel option should also be added:
\r
39 options IPSEC_DEBUG #debug for IP security
\r
43 ### 10.9.2 The Problem
\r
45 There's no standard for what constitutes a VPN. VPNs can be implemented using a number of different technologies, each of which have their own strengths and weaknesses. This article presents a number of scenarios, and strategies for implementing a VPN for each scenario.
\r
47 ### 10.9.3 Scenario #1: Two networks, connected to the Internet, to behave as one
\r
49 This is the scenario that caused me to first investigating VPNs. The premise is as follows:
\r
52 * You have at least two sites
\r
54 * Both sites are using IP internally
\r
56 * Both sites are connected to the Internet, through a gateway that is running DragonFly.
\r
58 * The gateway on each network has at least one public IP address.
\r
60 * The internal addresses of the two networks can be public or private IP addresses, it doesn't matter. You can be running NAT on the gateway machine if necessary.
\r
62 * The internal IP addresses of the two networks ***do not collide***. While I expect it is theoretically possible to use a combination of VPN technology and NAT to get this to work, I expect it to be a configuration nightmare.
\r
64 If you find that you are trying to connect two networks, both of which, internally, use the same private IP address range (e.g., both of them use `192.168.1.x`), then one of the networks will have to be renumbered.
\r
66 The network topology might look something like this:
\r
68 security/ipsec-network.png
\r
70 Notice the two public IP addresses. I'll use the letters to refer to them in the rest of this article. Anywhere you see those letters in this article, replace them with your own public IP addresses. Note also that internally, the two gateway machines have .1 IP addresses, and that the two networks have different private IP addresses (`192.168.1.x` and `192.168.2.x` respectively). All the machines on the private networks have been configured to use the `.1` machine as their default gateway.
\r
72 The intention is that, from a network point of view, each network should view the machines on the other network as though they were directly attached the same router -- albeit a slightly slow router with an occasional tendency to drop packets.
\r
74 This means that (for example), machine `192.168.1.20` should be able to run
\r
80 and have it work, transparently. Windows machines should be able to see the machines on the other network, browse file shares, and so on, in exactly the same way that they can browse machines on the local network.
\r
82 And the whole thing has to be secure. This means that traffic between the two networks has to be encrypted.
\r
84 Creating a VPN between these two networks is a multi-step process. The stages are as follows:
\r
86 1. Create a ***virtual*** network link between the two networks, across the Internet. Test it, using tools like [ping(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ping§ion8), to make sure it works.
\r
87 1. Apply security policies to ensure that traffic between the two networks is transparently encrypted and decrypted as necessary. Test this, using tools like [tcpdump(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#tcpdump§ion1), to ensure that traffic is encrypted.
\r
88 1. Configure additional software on the DragonFly gateways, to allow Windows machines to see one another across the VPN.
\r
90 #### 10.9.3.1 Step 1: Creating and testing a ***virtual*** network link
\r
92 Suppose that you were logged in to the gateway machine on network #1 (with public IP address `A.B.C.D`, private IP address `192.168.1.1`), and you ran `ping 192.168.2.1`, which is the private address of the machine with IP address `W.X.Y.Z`. What needs to happen in order for this to work?
\r
94 1. The gateway machine needs to know how to reach `192.168.2.1`. In other words, it needs to have a route to `192.168.2.1`.
\r
95 1. Private IP addresses, such as those in the `192.168.x` range are not supposed to appear on the Internet at large. Instead, each packet you send to `192.168.2.1` will need to be wrapped up inside another packet. This packet will need to appear to be from `A.B.C.D`, and it will have to be sent to `W.X.Y.Z`. This process is called ***encapsulation***.
\r
96 1. Once this packet arrives at `W.X.Y.Z` it will need to ***unencapsulated***, and delivered to `192.168.2.1`.
\r
98 You can think of this as requiring a ***tunnel*** between the two networks. The two ***tunnel mouths*** are the IP addresses `A.B.C.D` and `W.X.Y.Z`, and the tunnel must be told the addresses of the private IP addresses that will be allowed to pass through it. The tunnel is used to transfer traffic with private IP addresses across the public Internet.
\r
100 This tunnel is created by using the generic interface, or `gif` devices on DragonFly. As you can imagine, the `gif` interface on each gateway host must be configured with four IP addresses; two for the public IP addresses, and two for the private IP addresses.
\r
102 Support for the gif device must be compiled in to the DragonFly kernel on both machines. You can do this by adding the line:
\r
108 to the kernel configuration files on both machines, and then compile, install, and reboot as normal.
\r
110 Configuring the tunnel is a two step process. First the tunnel must be told what the outside (or public) IP addresses are, using [gifconfig(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#gifconfig§ion8). Then the private IP addresses must be configured using [ifconfig(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=ifconfig§ion=8).
\r
112 On the gateway machine on network #1 you would run the following two commands to configure the tunnel.
\r
115 gifconfig gif0 A.B.C.D W.X.Y.Z
\r
116 ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff
\r
120 On the other gateway machine you run the same commands, but with the order of the IP addresses reversed.
\r
123 gifconfig gif0 W.X.Y.Z A.B.C.D
\r
124 ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff
\r
134 to see the configuration. For example, on the network #1 gateway, you would see this:
\r
138 gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
\r
139 inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
\r
140 physical address inet A.B.C.D --> W.X.Y.Z
\r
144 As you can see, a tunnel has been created between the physical addresses `A.B.C.D` and `W.X.Y.Z`, and the traffic allowed through the tunnel is that between `192.168.1.1` and `192.168.2.1`.
\r
146 This will also have added an entry to the routing table on both machines, which you can examine with the command `netstat -rn`. This output is from the gateway host on network #1.
\r
153 Destination Gateway Flags Refs Use Netif Expire
\r
155 192.168.2.1 192.168.1.1 UH 0 0 gif0
\r
160 As the ***Flags*** value indicates, this is a host route, which means that each gateway knows how to reach the other gateway, but they do not know how to reach the rest of their respective networks. That problem will be fixed shortly.
\r
162 It is likely that you are running a firewall on both machines. This will need to be circumvented for your VPN traffic. You might want to allow all traffic between both networks, or you might want to include firewall rules that protect both ends of the VPN from one another.
\r
164 It greatly simplifies testing if you configure the firewall to allow all traffic through the VPN. You can always tighten things up later. If you are using [ipfw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipfw§ion8) on the gateway machines then a command like
\r
167 ipfw add 1 allow ip from any to any via gif0
\r
170 will allow all traffic between the two end points of the VPN, without affecting your other firewall rules. Obviously you will need to run this command on both gateway hosts.
\r
172 This is sufficient to allow each gateway machine to ping the other. On `192.168.1.1`, you should be able to run
\r
178 and get a response, and you should be able to do the same thing on the other gateway machine.
\r
180 However, you will not be able to reach internal machines on either network yet. This is because of the routing -- although the gateway machines know how to reach one another, they do not know how to reach the network behind each one.
\r
182 To solve this problem you must add a static route on each gateway machine. The command to do this on the first gateway would be:
\r
185 route add 192.168.2.0 192.168.2.1 netmask 0xffffff00
\r
189 This says ***In order to reach the hosts on the network `192.168.2.0`, send the packets to the host `192.168.2.1`***. You will need to run a similar command on the other gateway, but with the `192.168.1.x` addresses instead.
\r
191 IP traffic from hosts on one network will now be able to reach hosts on the other network.
\r
193 That has now created two thirds of a VPN between the two networks, in as much as it is ***virtual*** and it is a ***network***. It is not private yet. You can test this using [ping(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ping§ion8) and [tcpdump(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=tcpdump§ion=1). Log in to the gateway host and run
\r
196 tcpdump dst host 192.168.2.1
\r
199 In another log in session on the same host run
\r
205 You will see output that looks something like this:
\r
208 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
\r
209 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
\r
210 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
\r
211 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
\r
212 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
\r
213 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply
\r
217 As you can see, the ICMP messages are going back and forth unencrypted. If you had used the `-s` parameter to [tcpdump(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#tcpdump§ion1) to grab more bytes of data from the packets you would see more information.
\r
219 Obviously this is unacceptable. The next section will discuss securing the link between the two networks so that it all traffic is automatically encrypted.
\r
224 * Configure both kernels with ***pseudo-device gif***.
\r
226 * Edit `/etc/rc.conf` on gateway host #1 and add the following lines (replacing IP addresses as necessary).
\r
228 gifconfig_gif0="A.B.C.D W.X.Y.Z"
\r
229 ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
\r
230 static_routes="vpn"
\r
231 route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"
\r
234 * Edit your firewall script (`/etc/rc.firewall`, or similar) on both hosts, and add
\r
236 ipfw add 1 allow ip from any to any via gif0
\r
239 * Make similar changes to `/etc/rc.conf` on gateway host #2, reversing the order of IP addresses.
\r
241 #### 10.9.3.2 Step 2: Securing the link
\r
243 To secure the link we will be using IPsec. IPsec provides a mechanism for two hosts to agree on an encryption key, and to then use this key in order to encrypt data between the two hosts.
\r
245 The are two areas of configuration to be considered here.
\r
247 1. There must be a mechanism for two hosts to agree on the encryption mechanism to use. Once two hosts have agreed on this mechanism there is said to be a ***security association*** between them.
\r
248 1. There must be a mechanism for specifying which traffic should be encrypted. Obviously, you don't want to encrypt all your outgoing traffic -- you only want to encrypt the traffic that is part of the VPN. The rules that you put in place to determine what traffic will be encrypted are called ***security policies***.
\r
250 Security associations and security policies are both maintained by the kernel, and can be modified by userland programs. However, before you can do this you must configure the kernel to support IPsec and the Encapsulated Security Payload (ESP) protocol. This is done by configuring a kernel with:
\r
258 and recompiling, reinstalling, and rebooting. As before you will need to do this to the kernels on both of the gateway hosts.
\r
260 You have two choices when it comes to setting up security associations. You can configure them by hand between two hosts, which entails choosing the encryption algorithm, encryption keys, and so forth, or you can use daemons that implement the Internet Key Exchange protocol (IKE) to do this for you.
\r
262 I recommend the latter. Apart from anything else, it is easier to set up.
\r
264 Editing and displaying security policies is carried out using [setkey(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#setkey§ion8). By analogy, `setkey` is to the kernel's security policy tables as [route(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=route§ion=8) is to the kernel's routing tables. `setkey` can also display the current security associations, and to continue the analogy further, is akin to `netstat -r` in that respect.
\r
266 There are a number of choices for daemons to manage security associations with DragonFly. This article will describe how to use one of these, racoon. racoon is in the FreeBSD ports collection, in the security/ category, and is installed in the usual way.
\r
268 racoon must be run on both gateway hosts. On each host it is configured with the IP address of the other end of the VPN, and a secret key (which you choose, and must be the same on both gateways).
\r
270 The two daemons then contact one another, confirm that they are who they say they are (by using the secret key that you configured). The daemons then generate a new secret key, and use this to encrypt the traffic over the VPN. They periodically change this secret, so that even if an attacker were to crack one of the keys (which is as theoretically close to unfeasible as it gets) it won't do them much good -- by the time they've cracked the key the two daemons have chosen another one.
\r
272 racoon's configuration is stored in `${PREFIX}/etc/racoon`. You should find a configuration file there, which should not need to be changed too much. The other component of racoon's configuration, which you will need to change, is the ***pre-shared key***.
\r
274 The default racoon configuration expects to find this in the file `${PREFIX}/etc/racoon/psk.txt`. It is important to note that the pre-shared key is ***not*** the key that will be used to encrypt your traffic across the VPN link, it is simply a token that allows the key management daemons to trust one another.
\r
276 `psk.txt` contains a line for each remote site you are dealing with. In this example, where there are two sites, each `psk.txt` file will contain one line (because each end of the VPN is only dealing with one other end).
\r
278 On gateway host #1 this line should look like this:
\r
284 That is, the ***public*** IP address of the remote end, whitespace, and a text string that provides the secret. Obviously, you shouldn't use ***secret*** as your key -- the normal rules for choosing a password apply.
\r
286 On gateway host #2 the line would look like this
\r
292 That is, the public IP address of the remote end, and the same secret key. `psk.txt` must be mode `0600` (i.e., only read/write to `root`) before racoon will run.
\r
294 You must run racoon on both gateway machines. You will also need to add some firewall rules to allow the IKE traffic, which is carried over UDP to the ISAKMP (Internet Security Association Key Management Protocol) port. Again, this should be fairly early in your firewall ruleset.
\r
297 ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
\r
298 ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
\r
302 Once racoon is running you can try pinging one gateway host from the other. The connection is still not encrypted, but racoon will then set up the security associations between the two hosts -- this might take a moment, and you may see this as a short delay before the ping commands start responding.
\r
304 Once the security association has been set up you can view it using [setkey(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#setkey§ion8). Run
\r
310 on either host to view the security association information.
\r
312 That's one half of the problem. They other half is setting your security policies.
\r
314 To create a sensible security policy, let's review what's been set up so far. This discussions hold for both ends of the link.
\r
316 Each IP packet that you send out has a header that contains data about the packet. The header includes the IP addresses of both the source and destination. As we already know, private IP addresses, such as the `192.168.x.y` range are not supposed to appear on the public Internet. Instead, they must first be encapsulated inside another packet. This packet must have the public source and destination IP addresses substituted for the private addresses.
\r
318 So if your outgoing packet started looking like this:
\r
320 security/ipsec-out-pkt.png
\r
322 Then it will be encapsulated inside another packet, looking something like this:
\r
324 security/ipsec-encap-pkt.png
\r
326 This encapsulation is carried out by the `gif` device. As you can see, the packet now has real IP addresses on the outside, and our original packet has been wrapped up as data inside the packet that will be put out on the Internet.
\r
328 Obviously, we want all traffic between the VPNs to be encrypted. You might try putting this in to words, as:
\r
330 ***If a packet leaves from `A.B.C.D`, and it is destined for `W.X.Y.Z`, then encrypt it, using the necessary security associations.***
\r
332 ***If a packet arrives from `W.X.Y.Z`, and it is destined for `A.B.C.D`, then decrypt it, using the necessary security associations.***
\r
334 That's close, but not quite right. If you did this, all traffic to and from `W.X.Y.Z`, even traffic that was not part of the VPN, would be encrypted. That's not quite what you want. The correct policy is as follows
\r
336 ***If a packet leaves from `A.B.C.D`, and that packet is encapsulating another packet, and it is destined for `W.X.Y.Z`, then encrypt it, using the necessary security associations.***
\r
338 ***If a packet arrives from `W.X.Y.Z`, and that packet is encapsulating another packet, and it is destined for `A.B.C.D`, then encrypt it, using the necessary security associations.***
\r
340 A subtle change, but a necessary one.
\r
342 Security policies are also set using [setkey(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#setkey§ion8). [setkey(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=setkey§ion=8) features a configuration language for defining the policy. You can either enter configuration instructions via stdin, or you can use the `-f` option to specify a filename that contains configuration instructions.
\r
344 The configuration on gateway host #1 (which has the public IP address `A.B.C.D`) to force all outbound traffic to `W.X.Y.Z` to be encrypted is:
\r
347 spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
\r
351 Put these commands in a file (e.g., `/etc/ipsec.conf`) and then run
\r
354 # setkey -f /etc/ipsec.conf
\r
357 `spdadd` tells [setkey(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#setkey§ion8) that we want to add a rule to the secure policy database. The rest of this line specifies which packets will match this policy. `A.B.C.D/32` and `W.X.Y.Z/32` are the IP addresses and netmasks that identify the network or hosts that this policy will apply to. In this case, we want it to apply to traffic between these two hosts. `ipencap` tells the kernel that this policy should only apply to packets that encapsulate other packets. `-P out` says that this policy applies to outgoing packets, and `ipsec` says that the packet will be secured.
\r
359 The second line specifies how this packet will be encrypted. `esp` is the protocol that will be used, while `tunnel` indicates that the packet will be further encapsulated in an IPsec packet. The repeated use of `A.B.C.D` and `W.X.Y.Z` is used to select the security association to use, and the final `require` mandates that packets must be encrypted if they match this rule.
\r
361 This rule only matches outgoing packets. You will need a similar rule to match incoming packets.
\r
364 spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
\r
367 Note the `in` instead of `out` in this case, and the necessary reversal of the IP addresses.
\r
369 The other gateway host (which has the public IP address `W.X.Y.Z`) will need similar rules.
\r
372 spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
\r
373 spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
\r
376 Finally, you need to add firewall rules to allow ESP and IPENCAP packets back and forth. These rules will need to be added to both hosts.
\r
379 ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
\r
380 ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
\r
381 ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
\r
382 ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
\r
386 Because the rules are symmetric you can use the same rules on each gateway host.
\r
388 Outgoing packets will now look something like this:
\r
390 security/ipsec-crypt-pkt.png
\r
392 When they are received by the far end of the VPN they will first be decrypted (using the security associations that have been negotiated by racoon). Then they will enter the `gif` interface, which will unwrap the second layer, until you are left with the innermost packet, which can then travel in to the inner network.
\r
394 You can check the security using the same [ping(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ping§ion8) test from earlier. First, log in to the `A.B.C.D` gateway machine, and run:
\r
397 tcpdump dst host 192.168.2.1
\r
400 In another log in session on the same host run
\r
406 This time you should see output like the following:
\r
412 Now, as you can see, [tcpdump(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#tcpdump§ion1) shows the ESP packets. If you try to examine them with the `-s` option you will see (apparently) gibberish, because of the encryption.
\r
414 Congratulations. You have just set up a VPN between two remote sites.
\r
419 * Configure both kernels with:
\r
425 * Install [`security/racoon`](http://pkgsrc.se/security/racoon). Edit `${PREFIX}/etc/racoon/psk.txt` on both gateway hosts, adding an entry for the remote host's IP address and a secret key that they both know. Make sure this file is mode 0600.
\r
427 * Add the following lines to `/etc/rc.conf` on each host:
\r
430 ipsec_file="/etc/ipsec.conf"
\r
433 * Create an `/etc/ipsec.conf` on each host that contains the necessary spdadd lines. On gateway host #1 this would be:
\r
435 spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
\r
436 esp/tunnel/A.B.C.D-W.X.Y.Z/require;
\r
437 spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
\r
438 esp/tunnel/W.X.Y.Z-A.B.C.D/require;
\r
440 On gateway host #2 this would be:
\r
442 spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
\r
443 esp/tunnel/W.X.Y.Z-A.B.C.D/require;
\r
444 spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
\r
445 esp/tunnel/A.B.C.D-W.X.Y.Z/require;
\r
448 * Add firewall rules to allow IKE, ESP, and IPENCAP traffic to both hosts:
\r
450 ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
\r
451 ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
\r
452 ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
\r
453 ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
\r
454 ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
\r
455 ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
\r
458 The previous two steps should suffice to get the VPN up and running. Machines on each network will be able to refer to one another using IP addresses, and all traffic across the link will be automatically and securely encrypted.
\r
463 CategoryHandbook-security
\r
projects / ikiwiki.git / blob