aboutsummaryrefslogtreecommitdiffstats
path: root/src/libcharon/encoding
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* ikev1: Accept SPI size of any length <= 16 in ISAKMP proposalTobias Brunner2014-03-311-4/+12
| | | | Fixes #533.
* ike: Support encoding of attribute certificates in CERT payloadsMartin Willi2014-03-311-1/+6
|
* Added IFOM_CAPABILITY notify message typeAndreas Steffen2013-11-012-6/+10
|
* iv_gen: Provide external sequence number (IKE, ESP)Tobias Brunner2013-10-113-5/+7
| | | | This prevents duplicate sequential IVs in case of a HA failover.
* ikev2: Use IV generator to encrypt encrypted payloadTobias Brunner2013-10-111-1/+9
|
* ikev1: Support parsing of AH+IPComp proposalsMartin Willi2013-10-111-9/+11
|
* ikev1: Accept more than two certificate payloadsMartin Willi2013-10-111-2/+2
|
* ikev1: Support en-/decoding of SA payloads with AH algorithmsMartin Willi2013-10-111-31/+99
|
* message: print type of configuration payloadMartin Willi2013-09-031-1/+21
|
* message: print attributes for IKEv1 configuration payloads as wellMartin Willi2013-09-031-1/+2
|
* Fix various API doc issues and typosTobias Brunner2013-07-181-5/+5
| | | | Partially based on an old patch by Adrian-Ken Rueegsegger.
* linked-list: Remove barely used has_more() methodTobias Brunner2013-07-171-83/+105
| | | | | | | | This required some refactoring when handling encrypted payloads. Also changed log messages so that "encrypted payload" is logged instead of "encryption payload" (even if we internally still call it that) as that's the name used in RFC 5996.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 02:14:51 +0000