1 |
Pre-Script: I'm probably in a bad mental state to reply, but I want to |
2 |
answer some valid questions before others reply. Please take what I say |
3 |
and how I say it with a grain of salt. I don't mean anything personally. |
4 |
|
5 |
I /do/ appreciate the constructive and thought provoking responses that |
6 |
I'm getting. |
7 |
|
8 |
On 4/6/21 1:07 PM, Sid Spry wrote: |
9 |
> Can you clarify why you need to use IPsec? |
10 |
|
11 |
I don't have a /need/ in any normal sense. But I do /want/ to mess / |
12 |
play with and learn about /IPsec/. -- I have used many other VPNs; |
13 |
OpenVPN and WireGuard. But I'm finding my understanding of IPsec |
14 |
lacking, hence my desire to learn about /IPsec/, specifically |
15 |
/transport/ mode. |
16 |
|
17 |
> If it is to support a commercial client you may be better off |
18 |
> handing them a system based around BSD. |
19 |
|
20 |
*blink* |
21 |
|
22 |
Nothing against any of the BSDs, or any other Unix for that matter. But |
23 |
... I think this is a /Linux/ mailing list. ;-) So ... suggesting |
24 |
something other than Linux seems counterproductive. |
25 |
|
26 |
> More flexibility will be had from Linux, but pfSense/OPNsense gives |
27 |
> you a point and click web terminal which is easier to train in house |
28 |
> IT on due to the documentation available. |
29 |
|
30 |
I'd like to add IPFire to that list. Especially considering that it's |
31 |
Linux based. ;-) |
32 |
|
33 |
> The modes are also usually sufficient -- site to site tunnel (like |
34 |
> the appliances you're used to using), intranet protection, and routing |
35 |
> options for the same. |
36 |
|
37 |
"Usually" being the operative word. "Sufficient" being in the eye of |
38 |
the beholder. |
39 |
|
40 |
*I* /personally/ _frequently_ fall outside of "usually". Being the |
41 |
person that I am, what is "sufficient" for the vast majority of people |
42 |
leaves me wanting. |
43 |
|
44 |
> If you control everything you can use wireguard or OpenVPN. |
45 |
|
46 |
If it wasn't for the fact that I'm wanting to play with / learn about |
47 |
IPsec, I would completely agree with you. However, my desire to learn |
48 |
about /IPsec/ is in direct conflict with your otherwise reasonable |
49 |
suggestion. |
50 |
|
51 |
> To answer some of your later questions in summary: |
52 |
> 1. Of the projects libreswan seems to best maintained, though openswan |
53 |
> still releases regularly. I would start with libreswan. For racoon, |
54 |
> see https://www.netbsd.org/docs/network/ipsec/rasvpn.html. |
55 |
> 2. Yes, see |
56 |
> https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2. |
57 |
> Don't worry about embedding key material in your scripts (unless |
58 |
> you expect someone has bugged your monitor). The key material has |
59 |
> to be on disk in some form anyway. |
60 |
|
61 |
Please allow me to elaborate. |
62 |
|
63 |
I view -- what I understand to be the quintessential mode of operation |
64 |
for -- Pre Shared Keys to have a security weakness ~> flaw in that both |
65 |
ends must know the PSKs used for each direction. Thus compromising |
66 |
either end completely compromises the security of the connection. |
67 |
|
68 |
Further, if we assume that a per-system key is used for {en,de}cryption |
69 |
(pick one, I don't think it matters which), then we can probably further |
70 |
assume that the same per-system key is used for {en,de}cryption with |
71 |
other additional systems. As such, compromising the PSK(s) on one |
72 |
system likely compromises at least one of the PSK(s) for other systems. |
73 |
|
74 |
Whats' more is that PSKs tend to be static. -- Maybe there are ways |
75 |
with IKE to use PFS to ensure minimize damage done by knowing PSK(s). |
76 |
|
77 |
I feel like most, if not all, of this is avoided by not having PSK(s) or |
78 |
other keying material in scripts and on systems. |
79 |
|
80 |
We are probably all familiar with having a TLS certificate key pair on |
81 |
systems these days. So if we can leverage and re-use those key pairs, |
82 |
that would be Really Nice™. |
83 |
|
84 |
> Typical usage has the tunnel creation commands referencing key |
85 |
> material. |
86 |
|
87 |
There is a difference in referencing a PSK and referencing a key pair. |
88 |
Especially when looking at the output of ps. |
89 |
|
90 |
> Bash disables history in noninteractive shells by default. |
91 |
|
92 |
I feel like relying on a default, which can be changed, is not a good |
93 |
basis for security. }:-) |
94 |
|
95 |
> 3. Drop opportunistic encryption. It's best if you or the user knows |
96 |
> if the network is secure or not. |
97 |
|
98 |
Agreed. |
99 |
|
100 |
The O.E. is more to allow other systems to be able to communicate with |
101 |
my system /more/ securely if they want to. |
102 |
|
103 |
There are also ways to have IPTables allow IPsec protected traffic while |
104 |
blocking unprotected traffic. Thus providing the hard pass / fail that |
105 |
I think you're alluding to. |
106 |
|
107 |
> 4. The authentication header (AH) does not provide |
108 |
> "security." |
109 |
|
110 |
What does "security" mean? |
111 |
|
112 |
I agree that AH does not provide /confidentiality/. |
113 |
|
114 |
> Encapsulating security payload (ESP) provides confidentiality and, |
115 |
> if selected, authentication. Check the docs -- usually you want |
116 |
> authentication and confidentiality, merely confidentiality allows |
117 |
> some classes of attacks. |
118 |
|
119 |
I will check out the authentication option for ESP. |
120 |
|
121 |
Though, I suspect it's going to be quite a bit more difficult to pull |
122 |
off a MitM with ESP that's only providing confidentiality assuming that |
123 |
proper authentication has recently happened in conjunction with |
124 |
establishing the SAs being used by ESP, a la. IKE. |
125 |
|
126 |
> 5. Transport mode may be most appropriate, however you could have |
127 |
> tunnels between all servers |
128 |
|
129 |
The addition of tunnels very likely means the addition of additional |
130 |
interfaces and IPs. Which means that now systems inherently become |
131 |
multi-homed, which is it's own set of problems. |
132 |
|
133 |
> for redundancy. |
134 |
Please elaborate on what you mean by "for redundancy" here. |
135 |
|
136 |
I see it as the tunnel likely won't function if the main connection is |
137 |
down. It's not like an OoB backup connection. |
138 |
|
139 |
> 6. Setting up the public key infrastructure will be most of the |
140 |
> headache. |
141 |
|
142 |
I'm really hoping that there is a way to leverage / utilize something |
143 |
like Let's Encrypt's (et al.) /existing/ PKI and re-use the existing certs. |
144 |
|
145 |
> Doesn't seem manual if you've got a script for it. A lot of people |
146 |
> stop here. |
147 |
|
148 |
It's manual in that it currently requires human intervention and that |
149 |
there isn't automatic re-keying. |
150 |
|
151 |
> If you need consulting time I can offer it, but reading the linked |
152 |
> pages should get you far enough along. I won't mind answering things |
153 |
> in public but do wonder about your interest in IPsec. |
154 |
|
155 |
Hopefully I've answered some of your questions and have explained where |
156 |
I'm coming from and why I'm looking at /IPsec/ *specifically*. |
157 |
|
158 |
|
159 |
|
160 |
-- |
161 |
Grant. . . . |
162 |
unix || die |