Project

General

Profile

Issue #2424

Default proposal no longer uses PFS, breaking anyone upgrading from 5.5.3 to 5.6.0

Added by Paul Wouters about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
ikev1
Affected version:
5.6.0
Resolution:

Description

It seems a change in 5.6.0 was made to no longer default to PFS when using IKEv1.

This breaks existing configurations with no ike= line and those with an ike= line specifying only encr-integ, eg ike=aes-sha1

this can be seen in most ikev1 interop test cases on http://testing.libreswan.org/ from around the date this bug was filed.
(we are currently working around this bug by specifying IKE lines.

History

#1 Updated by Paul Wouters about 3 years ago

Actually, this is also a problem for IKEv2 (but I cannot seem to update the bug title)

Any configuration that uses something like: ike=aes-sha1 will fail after an upgrade

#2 Updated by Tobias Brunner about 3 years ago

  • Subject changed from Default IKEv1 proposal no longer uses PFS, breaking anyone upgrading from 5.5.3 to 5.6.0 to Default proposal no longer uses PFS, breaking anyone upgrading from 5.5.3 to 5.6.0
  • Status changed from New to Feedback

This breaks existing configurations with no ike= line and those with an ike= line specifying only encr-integ, eg ike=aes-sha1

Since IKE proposals without DH groups are invalid these configs are now rejected (see #2347, filed by yourself).

Not sure how this relates to the default proposal (as indicated by the title), though, which is added to whatever you configure in ike (unless ! is used) and definitely should include DH groups.

#3 Updated by Paul Wouters about 3 years ago

Tobias Brunner wrote:

This breaks existing configurations with no ike= line and those with an ike= line specifying only encr-integ, eg ike=aes-sha1

Since IKE proposals without DH groups are invalid these configs are now rejected (see #2347, filed by yourself).

Not sure how this relates to the default proposal (as indicated by the title), though, which is added to whatever you configure in ike (unless ! is used) and definitely should include DH groups.

Configurations that had an ike= line with encr+integ worked before with valid DH (libreswan rejects invalid IKE proposals without DH)

Configurations that did not specify an ike= line also broke.

Most (none?) of our ike= lines contained a "!", so the default proposals that had valid DH groups seemed to have not gotten added.

All interop test case configurations are available on testing.libreswan.org. Since we are not doing functional testing of strongswan we changed the strongswan configurations to let our tests work.

This report was a merely courtesy to strongswan to notify of what is a serious impact on strongswan deployments. You may close it if you deem that is the right method to resolve this issue.

#4 Updated by Tobias Brunner about 3 years ago

Configurations that had an ike= line with encr+integ worked before with valid DH (libreswan rejects invalid IKE proposals without DH)

The behavior probably depends on the version. Before 5.5.1 (or #2051) an invalid first proposal might have been sent (followed by the default proposals). Then before 5.6.0 the invalid proposal probably was silently ignored and you ended up with just the default proposals (non-AEAD/AEAD). Now such proposals are rejected and the configs not loaded.

Configurations that did not specify an ike= line also broke.

How so? Could you point me to a specific scenario that failed that way? (By the way, the charon log files appear to be empty in your test results - at least in the two scenarios I picked randomly.)

Most (none?) of our ike= lines contained a "!", so the default proposals that had valid DH groups seemed to have not gotten added.

The default proposals get added after the configured proposals are parsed and verified. And the configured proposals are not modified (except for adding PRFs), the default proposals just get added after them to the proposal list.

This report was a merely courtesy to strongswan to notify of what is a serious impact on strongswan deployments.

Appreciated, but this is only an issue because the configured proposals were invalid in the first place.

#5 Updated by Paul Wouters about 3 years ago

Tobias Brunner wrote:

How so? Could you point me to a specific scenario that failed that way? (By the way, the charon log files appear to be empty in your test results - at least in the two scenarios I picked randomly.)

It might have been the AH cases. You can see the changes I needed to do to work around failures at:

https://github.com/libreswan/libreswan/commit/bba21673d5c9280eab20935d9ccdbe52ad763fee
https://github.com/libreswan/libreswan/commit/211b279c99db4752770e34da477999489d5e3e92

The strongswan logs were missing because those test VMs had SElinux enabled and it prevented charon from writing in our custom /tmp/charon.log file. This was addressed with this commit so future tests will always produce charon logs:

https://github.com/libreswan/libreswan/commit/5a883b952053ffa5d30d7b1eef6f41a5c2df9861

Most (none?) of our ike= lines contained a "!", so the default proposals that had valid DH groups seemed to have not gotten added.

The default proposals get added after the configured proposals are parsed and verified. And the configured proposals are not modified (except for adding PRFs), the default proposals just get added after them to the proposal list.

This report was a merely courtesy to strongswan to notify of what is a serious impact on strongswan deployments.

Appreciated, but this is only an issue because the configured proposals were invalid in the first place.

#6 Updated by Tobias Brunner about 3 years ago

How so? Could you point me to a specific scenario that failed that way? (By the way, the charon log files appear to be empty in your test results - at least in the two scenarios I picked randomly.)

It might have been the AH cases. You can see the changes I needed to do to work around failures at:

I don't see an error during Phase 1 here (before ike was added). But during Quick Mode an unknown (to strongSwan) notify is returned (BAD-PROPOSAL-SYNTAX), which is apparently caused because of this:

"westnet-eastnet-ikev1" #2: AUTH_ALGORITHM_HMAC_SHA2_256 attribute inappropriate in AH_AES_XCBC_MAC Transform

However, this continues to be an issue in later test runs, i.e. even after you added the ike option to the config (would be surprising if that changed anything in regards to QM, as we don't e.g. reuse DH groups from Phase 1). But that's to be expected as the log shows 5.5.2 is actually used and that bug was not fixed until 5.6.0 (you reported it in #2347).

#7 Updated by Tobias Brunner over 2 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner

Closing old issues. If this is still a problem, please reopen.

Also available in: Atom PDF