ikev1: Add an option to accept unencrypted ID/HASH payloads
Even in Main Mode, some Sonicwall boxes seem to send ID/HASH payloads in unencrypted form, probably to allow PSK lookup based on the ID payloads. We by default reject that, but accept it if the charon.accept_unencrypted_mainmode_messages option is set in strongswan.conf. Initial patch courtesy of Paul Stewart.
This commit is contained in:
@@ -8,6 +8,21 @@ charon {}
|
||||
**charon-cmd** instead of **charon**). For many options defaults can be
|
||||
defined in the **libstrongswan** section.
|
||||
|
||||
charon.accept_unencrypted_mainmode_messages = no
|
||||
Accept unencrypted ID and HASH payloads in IKEv1 Main Mode.
|
||||
|
||||
Accept unencrypted ID and HASH payloads in IKEv1 Main Mode.
|
||||
|
||||
Some implementations send the third Main Mode message unencrypted, probably
|
||||
to find the PSKs for the specified ID for authentication. This is very
|
||||
similar to Aggressive Mode, and has the same security implications: A
|
||||
passive attacker can sniff the negotiated Identity, and start brute forcing
|
||||
the PSK using the HASH payload.
|
||||
|
||||
It is recommended to keep this option to no, unless you know exactly
|
||||
what the implications are and require compatibility to such devices (for
|
||||
example, some SonicWall boxes).
|
||||
|
||||
charon.block_threshold = 5
|
||||
Maximum number of half-open IKE_SAs for a single peer IP.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user