/* * OpenVPN Protocol, taken from ssl.h in OpenVPN source code. * * TCP/UDP Packet: This represents the top-level encapsulation. * * TCP/UDP packet format: * * Packet length (16 bits, unsigned) -- TCP only, always sent as * plaintext. Since TCP is a stream protocol, the packet * length words define the packetization of the stream. * * Packet opcode/key_id (8 bits) -- TLS only, not used in * pre-shared secret mode. * packet message type, a P_* constant (high 5 bits) * key_id (low 3 bits, see key_id in struct tls_session * below for comment). The key_id refers to an * already negotiated TLS session. OpenVPN seamlessly * renegotiates the TLS session by using a new key_id * for the new session. Overlap (controlled by * user definable parameters) between old and new TLS * sessions is allowed, providing a seamless transition * during tunnel operation. * * Payload (n bytes), which may be a P_CONTROL, P_ACK, or P_DATA * message. * * Message types: * * P_CONTROL_HARD_RESET_CLIENT_V1 -- Key method 1, initial key from * client, forget previous state. * * P_CONTROL_HARD_RESET_SERVER_V1 -- Key method 1, initial key * from server, forget previous state. * * P_CONTROL_SOFT_RESET_V1 -- New key, with a graceful transition * from old to new key in the sense that a transition window * exists where both the old or new key_id can be used. OpenVPN * uses two different forms of key_id. The first form is 64 bits * and is used for all P_CONTROL messages. P_DATA messages on the * other hand use a shortened key_id of 3 bits for efficiency * reasons since the vast majority of OpenVPN packets in an * active tunnel will be P_DATA messages. The 64 bit form * is referred to as a session_id, while the 3 bit form is * referred to as a key_id. * * P_CONTROL_V1 -- Control channel packet (usually TLS ciphertext). * * P_ACK_V1 -- Acknowledgement for P_CONTROL packets received. * * P_DATA_V1 -- Data channel packet containing actual tunnel data * ciphertext. * * P_CONTROL_HARD_RESET_CLIENT_V2 -- Key method 2, initial key from * client, forget previous state. * * P_CONTROL_HARD_RESET_SERVER_V2 -- Key method 2, initial key from * server, forget previous state. * * P_CONTROL* and P_ACK Payload: The P_CONTROL message type * indicates a TLS ciphertext packet which has been encapsulated * inside of a reliability layer. The reliability layer is * implemented as a straightforward ACK and retransmit model. * * P_CONTROL message format: * * local session_id (random 64 bit value to identify TLS session). * HMAC signature of entire encapsulation header for integrity * check if --tls-auth is specified (usually 16 or 20 bytes). * packet-id for replay protection (4 or 8 bytes, includes * sequence number and optional time_t timestamp). * P_ACK packet_id array length (1 byte). * P_ACK packet-id array (if length > 0). * P_ACK remote session_id (if length > 0). * message packet-id (4 bytes). * TLS payload ciphertext (n bytes) (only for P_CONTROL). * * Once the TLS session has been initialized and authenticated, * the TLS channel is used to exchange random key material for * bidirectional cipher and HMAC keys which will be * used to secure actual tunnel packets. OpenVPN currently * implements two key methods. Key method 1 directly * derives keys using random bits obtained from the RAND_bytes * OpenSSL function. Key method 2 mixes random key material * from both sides of the connection using the TLS PRF mixing * function. Key method 2 is the preferred method and is the default * for OpenVPN 2.0. * * TLS plaintext content: * * TLS plaintext packet (if key_method == 1): * * Cipher key length in bytes (1 byte). * Cipher key (n bytes). * HMAC key length in bytes (1 byte). * HMAC key (n bytes). * Options string (n bytes, null terminated, client/server options * string should match). * * TLS plaintext packet (if key_method == 2): * * Literal 0 (4 bytes). * key_method type (1 byte). * key_source structure (pre_master only defined for client -> * server). * options_string_length, including null (2 bytes). * Options string (n bytes, null terminated, client/server options * string must match). * [The username/password data below is optional, record can end * at this point.] * username_string_length, including null (2 bytes). * Username string (n bytes, null terminated). * password_string_length, including null (2 bytes). * Password string (n bytes, null terminated). * * The P_DATA payload represents encrypted, encapsulated tunnel * packets which tend to be either IP packets or Ethernet frames. * This is essentially the "payload" of the VPN. * * P_DATA message content: * HMAC of ciphertext IV + ciphertext (if not disabled by * --auth none). * Ciphertext IV (size is cipher-dependent, if not disabled by * --no-iv). * Tunnel packet ciphertext. * * P_DATA plaintext * packet_id (4 or 8 bytes, if not disabled by --no-replay). * In SSL/TLS mode, 4 bytes are used because the implementation * can force a TLS renegotation before 2^32 packets are sent. * In pre-shared key mode, 8 bytes are used (sequence number * and time_t value) to allow long-term key usage without * packet_id collisions. * User plaintext (n bytes). * * Notes: * (1) ACK messages can be encoded in either the dedicated * P_ACK record or they can be prepended to a P_CONTROL message. * (2) P_DATA and P_CONTROL/P_ACK use independent packet-id * sequences because P_DATA is an unreliable channel while * P_CONTROL/P_ACK is a reliable channel. Each use their * own independent HMAC keys. * (3) Note that when --tls-auth is used, all message types are * protected with an HMAC signature, even the initial packets * of the TLS handshake. This makes it easy for OpenVPN to * throw away bogus packets quickly, without wasting resources * on attempting a TLS handshake which will ultimately fail.