Hanno Becker f9c6a4bea1 Add pointers to in/out CID fields to mbedtls_ssl_context ... mbedtls_ssl_context contains pointers in_buf, in_hdr, in_len, ... which point to various parts of the header of an incoming TLS or DTLS record; similarly, there are pointers out_buf, ... for outgoing records. This commit adds fields in_cid and out_cid which point to where the CID of incoming/outgoing records should reside, if present, namely prior to where the record length resides. Quoting https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-04: The DTLSInnerPlaintext value is then encrypted and the CID added to produce the final DTLSCiphertext. struct { ContentType special_type = tls12_cid; /* 25 */ ProtocolVersion version; uint16 epoch; uint48 sequence_number; opaque cid[cid_length]; // New field uint16 length; opaque enc_content[DTLSCiphertext.length]; } DTLSCiphertext; For outgoing records, out_cid is set in ssl_update_out_pointers() based on the settings in the current outgoing transform. For incoming records, ssl_update_in_pointers() sets in_cid as if no CID was present, and it is the responsibility of ssl_parse_record_header() to update the field (as well as in_len, in_msg and in_iv) when parsing records that do contain a CID. This will be done in a subsequent commit. Finally, the code around the invocations of ssl_decrypt_buf() and ssl_encrypt_buf() is adapted to transfer the CID from the input/output buffer to the CID field in the internal record structure (which is what ssl_{encrypt/decrypt}_buf() uses). Note that mbedtls_ssl_in_hdr_len() doesn't need change because it infers the header length as in_iv - in_hdr, which will account for the CID for records using such.		2019-06-03 16:07:50 +01:00
..
mbedtls	Add pointers to in/out CID fields to mbedtls_ssl_context	2019-06-03 16:07:50 +01:00
.gitignore
CMakeLists.txt	Fix some comments regarding what files are symlinked	2018-03-23 14:39:52 +01:00