{"id":3699,"date":"2012-12-04T20:47:20","date_gmt":"2012-12-04T12:47:20","guid":{"rendered":"https:\/\/www.icocean.com\/wp\/?p=3699"},"modified":"2012-12-04T22:06:37","modified_gmt":"2012-12-04T14:06:37","slug":"open","status":"publish","type":"post","link":"https:\/\/www.icocean.com\/blog\/?p=3699","title":{"rendered":"OpenVPN Security Overview"},"content":{"rendered":"

OpenVPN cryptographic layer<\/strong>
\nThis is a technical overview of OpenVPN’s cryptographic layer, and assumes a prior understanding of modern cryptographic concepts. For additional discussion on OpenVPN security, see this FAQ item.
\nOpenVPN has two authentication modes:<\/p>\n

  • Static Key<\/strong> — Use a pre-shared static key<\/li>\n
  • TLS<\/strong> — Use SSL\/TLS + certificates for authentication and key exchange<\/li>\n

    In static key mode, a pre-shared key is generated and shared between both OpenVPN peers before the tunnel is started.
    \n
    \nThis static key contains 4 independent keys: HMAC send, HMAC receive, encrypt, and decrypt. By default in static key mode, both hosts will use the same HMAC key and the same encrypt\/decrypt key. However, using the direction parameter to –secret<\/strong>, it is possible to use all 4 keys independently.<\/p>\n

    In SSL\/TLS mode, an SSL session is established with bidirectional authentication (i.e. each side of the connection must present its own certificate). If the SSL\/TLS authentication succeeds, encryption\/decryption and HMAC key source material is then randomly generated by OpenSSL’s RAND_bytes function and exchanged over the SSL\/TLS connection. Both sides of the connection contribute random source material. This mode never uses any key bidirectionally, so each peer has a distinct send HMAC, receive HMAC, packet encrypt, and packet decrypt key. If –key-method 2<\/strong> is used, the actual keys are generated from the random source material using the TLS PRF function. If –key-method 1<\/strong> is used, the keys are generated directly from the OpenSSL RAND_bytes function. –key-method 2<\/strong> was introduced with OpenVPN 1.5.0 and will be made the default in OpenVPN 2.0.<\/p>\n

    During SSL\/TLS rekeying, there is a transition-window parameter that permits overlap between old and new key usage, so there is no time pressure or latency bottleneck during SSL\/TLS renegotiations.<\/p>\n

    Because SSL\/TLS is designed to operate over a reliable transport, OpenVPN provides a reliable transport layer on top of UDP (see diagram below).<\/p>\n

    Once each peer has its set of keys, the tunnel forwarding operation commences.
    \nThe encrypted packet is formatted as follows:<\/p>\n

  • HMAC(explicit IV, encrypted envelope)<\/li>\n
  • Explicit IV<\/li>\n
  • Encrypted Envelope<\/li>\n

    The plaintext of the encrypted envelope is formatted as follows:<\/p>\n

  • 64 bit sequence number<\/li>\n
  • payload data, i.e. IP packet or Ethernet frame<\/li>\n

    The HMAC and explicit IV are outside of the encrypted envelope.<\/p>\n

    The per-packet IV is randomized using a nonce-based PRNG that is initially seeded from the OpenSSL RAND_bytes function.<\/p>\n

    HMAC, encryption, and decryption functions are provided by the OpenSSL EVP interface and allows the user to select an arbitrary cipher, key size, and message digest for HMAC. BlowFish is the default cipher and SHA1 is the default message digest. The OpenSSL EVP interface handles padding to an even multiple of block size using PKCS#5 padding. CBC-mode cipher usage is encouraged but not required.<\/p>\n

    One notable security improvement that OpenVPN provides over vanilla TLS is that it gives the user the opportunity to use a pre-shared passphrase (or static key) in conjunction with the –tls-auth directive to generate an HMAC key to authenticate the packets that are themselves part of the TLS handshake sequence. This protects against buffer overflows in the OpenSSL TLS implementation, because an attacker cannot even initiate a TLS handshake without being able to generate packets with the currect HMAC signature.<\/p>\n

    OpenVPN multiplexes the SSL\/TLS session used for authentication and key exchange with the actual encrypted tunnel data stream. OpenVPN provides the SSL\/TLS connection with a reliable transport layer (as it is designed to operate over). The actual IP packets, after being encrypted and signed with an HMAC, are tunnelled over UDP without any reliability layer. So if –proto udp<\/strong> is used, no IP packets are tunneled over a reliable transport, eliminating the problem of reliability-layer collisions — Of course, if you are tunneling a TCP session over OpenVPN running in UDP mode, the TCP protocol itself will provide the reliability layer.
    \n\"\"<\/p>\n

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