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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
