[Swan] authenticated Opportunistic Encryption !

[Paul Wouters]

On Thu, 7 Dec 2017, Kesava Vunnava (kesriniv) wrote:

> Able to establish "authenticated OE" between peers using libreswan 3.20 .
> Looks like , flag "p"  for certificates created the mess. There were two flags "p" & "P" where former is to Prohibit ( explicitly distrust ) and later to Trust the peer.
> With the "P" for Certificates ., authenticated OE worked fine.

Great!

> 1] I was going through other thread about libreswan 3.22 & the check for subjectAltName in certificates. Is there any way (either through configuration/tweak) available to disable this check !?

No there is no such option, because it is inherently insecure. If you
have hostA and hostB and hostC in the same mesh, and hostA is
compromised, you don't want hostA to take hostB's IP and ID while
still using its own hostA certificate to pass verification. So it
is really important that you ensure your certificates are properly
issued and you use matching ID payloads.

> 2] As 3.20 worked for authenticated OE, do you still suggest >=3.22 to look for ? Would request to please point me to bug list (fixed) / enhancements added (in the context of OE) for 3.22 over 3.20 !?

We always recommend the latest release of course :)
3.21 and 3.22 added some OE features such as DNSSEC lookups and support
for the unbound DNS server ipsecmod plugin to do forward DNS based
Opportunistic IPsec.

> 3] Considering the FIPS mode - any inputs !?

It should work, except for the private-or-clear and clear-or-private
groups, since FIPS does not allow us to have a connection that is
"maybe sometimes encrypted". It's all or nothing. So negotiationshunt
and failureshunt cannot be set to soft-fail.

Paul