aboutsummaryrefslogtreecommitdiffstats
path: root/src/libcharon/encoding
Commit message (Collapse)AuthorAgeFilesLines
* Use standard unsigned integer typesAndreas Steffen2016-03-2448-415/+415
|
* payloads: Verify P-CSCF configuration attributes like others carrying IP ↵Tobias Brunner2016-03-101-0/+2
| | | | addresses
* ikev1: Send NAT-D payloads after vendor ID payloads in Aggressive Mode messagesTobias Brunner2016-03-071-6/+6
| | | | | | | Some implementations might otherwise not recognize the NAT-D payload type. Also moves SIG and HASH payloads last in these messages. Fixes #1239.
* ikev1: Send and verify IPv6 addresses correctlyTobias Brunner2016-03-031-0/+7
| | | | | | | | According to the mode-config draft there is no prefix sent for IPv6 addresses in IKEv1. We still accept 17 bytes long addresses for backwards compatibility with older strongSwan releases. Fixes #1304.
* ikev1: Assume a default key length of 128-bit for AES-CBCTobias Brunner2015-08-171-0/+11
| | | | | | | | | | Some implementations don't send a Key Length attribute for AES-128. This was allowed for IKE in early drafts of RFC 3602, however, some implementations also seem to do it for ESP, where it never was allowed. And the final version of RFC 3602 demands a Key Length attribute for both phases so they shouldn't do it anymore anyway. Fixes #1064.
* Fixed some typosTobias Brunner2015-08-131-1/+1
|
* message: Log message if unknown/disallowed payload receivedTobias Brunner2015-06-011-3/+10
|
* message: Log original message type of unknown payloadsTobias Brunner2015-06-011-0/+13
|
* unknown-payload: Use a new private payload type and make original type availableTobias Brunner2015-06-015-2/+25
| | | | | | | | | This fixes a DoS and potential remote code execution vulnerability that was caused because the original payload type that was returned previously was used to cast such payload objects to payloads of the indicated type (e.g. when logging notify payloads with a payload type for the wrong IKE version). Fixes CVE-2015-3991.
* ikev2: Include fragment number into message ID passed to IV genMartin Willi2015-06-011-0/+5
| | | | | | When using a cipher with sequential IVs, we never must pass an identical IV to the IV generator. To avoid it when using IKEv2 fragmentation, use the lower bits of the 64-bit message ID as the fragment number.
* message: Show the fragmentation numbers in message stringificationMartin Willi2015-06-011-0/+36
|
* utils: Use chunk_equals_const() for all cryptographic purposesMartin Willi2015-04-141-1/+1
|
* encoding: Remove DH public value verification from KE payloadMartin Willi2015-03-231-73/+0
| | | | | | | | This commit reverts 84738b1a and 2ed5f569. As we have no DH group available in the KE payload for IKEv1, the verification can't work in that stage. Instead, we now verify DH groups in the DH backends, which works for any IKE version or any other purpose.
* diffie-hellman: Add a bool return value to get_my_public_value()Martin Willi2015-03-231-2/+8
|
* encoding: Allow ke_payload_create_from_diffie_hellman() to failMartin Willi2015-03-231-1/+1
|
* encoding: Add getter for IKE SPIs in IKEv1 DELETE payloadsTobias Brunner2015-03-232-0/+25
|
* encoding: Don't verify length of IKEv1 KE payloadsTobias Brunner2015-03-201-0/+6
| | | | | | The verification introduced with 84738b1aed95 ("encoding: Verify the length of KE payload data for known groups") can't be done for IKEv1 as the KE payload does not contain the DH group.
* encoding: Verify the length of KE payload data for known groupsMartin Willi2015-03-181-0/+67
| | | | | | | IKE is very strict in the length of KE payloads, and it should be safe to strictly verify their length. Not doing so is no direct threat, but allows DDoS amplification by sending short KE payloads for large groups using the target as the source address.
* ikev2: Add SIGNATURE_HASH_ALGORITHMS notify payloadTobias Brunner2015-03-042-6/+18
|
* ike: Allow creation of internally used payloadsTobias Brunner2014-12-121-1/+1
| | | | | | | Since 42e0a317c64b ("ike: Only parse payloads valid for the current IKE version") payload types are checked before creating objects. This check failed for internally used payload types (e.g. proposal substructures), which have a type >= 256, i.e. outside the IKE payload type range.
* ikev1: Use same map for AH and ESP authentication algorithmsTobias Brunner2014-12-091-152/+120
| | | | | | The transform identifier used in AH transforms is not the same as the authentication algorithm identifier used in the transform attributes in AH (and ESP) transforms.
* ikev1: Accept IPComp proposals with 4 octet long CPI valuesTobias Brunner2014-12-051-2/+2
| | | | | While they SHOULD be sent as 16-bit values according to RFC 3173 a responder MUST be able to accept CPI values encoded in four bytes.
* ike: Only parse payloads valid for the current IKE versionTobias Brunner2014-12-054-3/+33
|
* ike: Make check for known payloads depend on IKE versionTobias Brunner2014-12-053-25/+40
|
* id-payload: Enable multiple calls to get_ts() for subnet traffic selectorsTobias Brunner2014-12-051-2/+5
| | | | The second call resulted in a /32 subnet previously.
* message: Include encrypted fragment payload in payload (order) rulesTobias Brunner2014-10-291-0/+12
| | | | | | | | | Otherwise fragmented CREATE_CHILD_SA exchanges won't get accepted because they don't contain an SA payload. It also prevents a warning when ordering payloads. Fixes #752.
* message: Limit maximum number of IKEv2 fragmentsTobias Brunner2014-10-101-1/+11
| | | | | | | | The maximum for IKEv1 is already 255 due to the 8-bit fragment number. With an overhead of 17 bytes (x64) per fragment and a default maximum of 10000 bytes per packet the maximum memory required is 14 kB for a fragmented message.
* packet: Define a global default maximum size for IKE packetsTobias Brunner2014-10-101-6/+1
|
* message: Ensure a minimum fragment lengthTobias Brunner2014-10-101-8/+18
|
* message: Fragment and reassemble IKEv2 messagesTobias Brunner2014-10-102-133/+366
|
* message: Handle encrypted fragment payload similar to the encrypted payloadTobias Brunner2014-10-101-16/+91
|
* ikev2: Add encrypted fragment payloadTobias Brunner2014-10-104-12/+454
|
* encrypted_payload: Encrypted payload can be constructed from plaintextTobias Brunner2014-10-102-0/+38
|
* encrypted_payload: Expose generate() to generate the plaintextTobias Brunner2014-10-102-1/+17
|
* encrypted_payload: Extract some utility functionsTobias Brunner2014-10-101-74/+110
|
* message: Split generate() in multiple functionsTobias Brunner2014-10-101-67/+122
|
* ikev2: Add notify for IKEv2 fragmentationTobias Brunner2014-10-102-7/+15
|
* ikev1: Move defragmentation to message_tTobias Brunner2014-10-102-2/+224
|
* message: fragment() generates message and fragments and caches themTobias Brunner2014-10-102-27/+98
|
* message: Make packet argument optional in generate()Tobias Brunner2014-10-101-1/+4
|
* ikev1: Move fragment generation to message_tTobias Brunner2014-10-102-2/+125
|
* ike: Rename encryption_payload to encrypted_payloadTobias Brunner2014-10-107-99/+95
|
* encoding: Accept all exchange types for non IKEv1/IKEv2 major versionsMartin Willi2014-09-221-5/+11
|
* ikev1: Don't cache last block of INFORMATIONAL messages as IVTobias Brunner2014-09-121-2/+2
| | | | | | | | | We don't expect a response with the same MID, but apparently some devices (e.g. FRITZ!Box) do that for DPDs, while still treating the response as a new exchange. By storing the last message block as IV we can't decrypt the first block of such a response. Fixes #661.
* ikev1: Log IV when encrypting messagesTobias Brunner2014-09-121-0/+1
|
* ikev1: Skip unusable IPComp proposalsTobias Brunner2014-09-121-1/+1
| | | | Fixes #661.
* ikev1: Properly handle different proposal numbering schemesTobias Brunner2014-09-121-5/+10
| | | | | | | | | | | | | | | | | | While the examples in RFC 2408 show proposal numbers starting at 1 and increasing by one for each subsequent proposal this is not mandatory. Actually, IKEv1 proposals may start at any number, the only requirement is that the proposal numbers increase monotonically they don't have to do so consecutively. Most implementations follow the examples and start numbering at 1 (charon, racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the implementations that started with 0 and there might be others out there. The previous assumption that implementations always start numbering proposals at 0 caused problems with clients that start numbering with 1 and whose first proposal consists of multiple protocols (e.g. ESP+IPComp). Fixes #661.
* encoding: Don't explicitly include <arpa/inet.h>Martin Willi2014-06-042-2/+0
|
* payload: Use common prefixes for all payload type identifiersMartin Willi2014-06-0443-681/+681
| | | | | The old identifiers did not use a proper namespace and often clashed with other defines.
* ikev1: Add an option to accept unencrypted ID/HASH payloadsMartin Willi2014-04-171-1/+20
| | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 15:03:11 +0000