Changes between Initial Version and Version 1 of SecurityOverview


Ignore:
Timestamp:
07/24/14 12:11:31 (10 years ago)
Author:
Samuli Seppänen
Comment:

Migrated content from http://openvpn.net/index.php/open-source/documentation/security-overview.html

Legend:

Unmodified
Added
Removed
Modified
  • SecurityOverview

    v1 v1  
     1= OpenVPN cryptographic layer =
     2
     3This 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 [wiki:295-are-there-any-known-security-vulnerabilities-with-openvpn this FAQ item].
     4
     5OpenVPN has two authentication modes:
     6
     7 * Static Key -- Use a pre-shared static key
     8 * TLS -- Use SSL/TLS + certificates for authentication and key exchange
     9
     10In static key mode, a pre-shared key is generated and shared between both OpenVPN peers before the tunnel is started. This 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, it is possible to use all 4 keys independently.
     11
     12In 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 is used, the actual keys are generated from the random source material using the TLS PRF function. If --key-method 1 is used, the keys are generated directly from the OpenSSL RAND_bytes function. --key-method 2 was introduced with OpenVPN 1.5.0 and will be made the default in OpenVPN 2.0.
     13
     14During 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.
     15
     16Because SSL/TLS is designed to operate over a reliable transport, OpenVPN provides a reliable transport layer on top of UDP (see diagram below).
     17
     18Once each peer has its set of keys, the tunnel forwarding operation commences.
     19
     20The encrypted packet is formatted as follows:
     21{{{
     22HMAC(explicit IV, encrypted envelope)
     23Explicit IV
     24Encrypted Envelope
     25}}}
     26The plaintext of the encrypted envelope is formatted as follows:
     27{{{
     2864 bit sequence number
     29payload data, i.e. IP packet or Ethernet frame
     30}}}
     31The HMAC and explicit IV are outside of the encrypted envelope.
     32
     33The per-packet IV is randomized using a nonce-based PRNG that is initially seeded from the OpenSSL RAND_bytes function.
     34
     35HMAC, 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.
     36
     37One 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.
     38
     39OpenVPN 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 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.
     40
     41{{{
     42SSL/TLS -> Reliability Layer -> \
     43           --tls-auth HMAC       \
     44                                  \
     45                                   > Multiplexer ----> UDP
     46                                  /                    Transport
     47IP        Encrypt and HMAC       /
     48Tunnel -> using OpenSSL EVP --> /
     49Packets   interface.
     50}}}
     51This 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.
     52
     53= OpenVPN Protocol =
     54
     55{{{
     56/*
     57 * OpenVPN Protocol, taken from ssl.h in OpenVPN source code.
     58 *
     59 * TCP/UDP Packet:  This represents the top-level encapsulation.
     60 *
     61 * TCP/UDP packet format:
     62 *
     63 *   Packet length (16 bits, unsigned) -- TCP only, always sent as
     64 *       plaintext.  Since TCP is a stream protocol, the packet
     65 *       length words define the packetization of the stream.
     66 *
     67 *   Packet opcode/key_id (8 bits) -- TLS only, not used in
     68 *       pre-shared secret mode.
     69 *            packet message type, a P_* constant (high 5 bits)
     70 *            key_id (low 3 bits, see key_id in struct tls_session
     71 *              below for comment).  The key_id refers to an
     72 *              already negotiated TLS session.  OpenVPN seamlessly
     73 *              renegotiates the TLS session by using a new key_id
     74 *              for the new session.  Overlap (controlled by
     75 *              user definable parameters) between old and new TLS
     76 *              sessions is allowed, providing a seamless transition
     77 *              during tunnel operation.
     78 *
     79 *   Payload (n bytes), which may be a P_CONTROL, P_ACK, or P_DATA
     80 *       message.
     81 *
     82 * Message types:
     83 *
     84 *  P_CONTROL_HARD_RESET_CLIENT_V1 -- Key method 1, initial key from
     85 *    client, forget previous state.
     86 *
     87 *  P_CONTROL_HARD_RESET_SERVER_V1 -- Key method 1, initial key
     88 *    from server, forget previous state.
     89 *
     90 *  P_CONTROL_SOFT_RESET_V1 -- New key, with a graceful transition
     91 *    from old to new key in the sense that a transition window
     92 *    exists where both the old or new key_id can be used.  OpenVPN
     93 *    uses two different forms of key_id.  The first form is 64 bits
     94 *    and is used for all P_CONTROL messages.  P_DATA messages on the
     95 *    other hand use a shortened key_id of 3 bits for efficiency
     96 *    reasons since the vast majority of OpenVPN packets in an
     97 *    active tunnel will be P_DATA messages.  The 64 bit form
     98 *    is referred to as a session_id, while the 3 bit form is
     99 *    referred to as a key_id.
     100 *
     101 *  P_CONTROL_V1 -- Control channel packet (usually TLS ciphertext).
     102 *
     103 *  P_ACK_V1 -- Acknowledgement for P_CONTROL packets received.
     104 *
     105 *  P_DATA_V1 -- Data channel packet containing actual tunnel data
     106 *    ciphertext.
     107 *
     108 *  P_CONTROL_HARD_RESET_CLIENT_V2 -- Key method 2, initial key from
     109 *   client, forget previous state.
     110 *
     111 *  P_CONTROL_HARD_RESET_SERVER_V2 -- Key method 2, initial key from
     112 *   server, forget previous state.
     113 *
     114 * P_CONTROL* and P_ACK Payload:  The P_CONTROL message type
     115 * indicates a TLS ciphertext packet which has been encapsulated
     116 * inside of a reliability layer.  The reliability layer is
     117 * implemented as a straightforward ACK and retransmit model.
     118 *
     119 * P_CONTROL message format:
     120 *
     121 *   local session_id (random 64 bit value to identify TLS session).
     122 *   HMAC signature of entire encapsulation header for integrity
     123 *       check if --tls-auth is specified (usually 16 or 20 bytes).
     124 *   packet-id for replay protection (4 or 8 bytes, includes
     125 *       sequence number and optional time_t timestamp).
     126 *   P_ACK packet_id array length (1 byte).
     127 *   P_ACK packet-id array (if length > 0).
     128 *   P_ACK remote session_id (if length > 0).
     129 *   message packet-id (4 bytes).
     130 *   TLS payload ciphertext (n bytes) (only for P_CONTROL).
     131 *
     132 * Once the TLS session has been initialized and authenticated,
     133 * the TLS channel is used to exchange random key material for
     134 * bidirectional cipher and HMAC keys which will be
     135 * used to secure actual tunnel packets.  OpenVPN currently
     136 * implements two key methods.  Key method 1 directly
     137 * derives keys using random bits obtained from the RAND_bytes
     138 * OpenSSL function.  Key method 2 mixes random key material
     139 * from both sides of the connection using the TLS PRF mixing
     140 * function.  Key method 2 is the preferred method and is the default
     141 * for OpenVPN 2.0.
     142 *
     143 * TLS plaintext content:
     144 *
     145 * TLS plaintext packet (if key_method == 1):
     146 *
     147 *   Cipher key length in bytes (1 byte).
     148 *   Cipher key (n bytes).
     149 *   HMAC key length in bytes (1 byte).
     150 *   HMAC key (n bytes).
     151 *   Options string (n bytes, null terminated, client/server options
     152 *       string should match).
     153 *
     154 * TLS plaintext packet (if key_method == 2):
     155 *
     156 *   Literal 0 (4 bytes).
     157 *   key_method type (1 byte).
     158 *   key_source structure (pre_master only defined for client ->
     159 *       server).
     160 *   options_string_length, including null (2 bytes).
     161 *   Options string (n bytes, null terminated, client/server options
     162 *       string must match).
     163 *   [The username/password data below is optional, record can end
     164 *       at this point.]
     165 *   username_string_length, including null (2 bytes).
     166 *   Username string (n bytes, null terminated).
     167 *   password_string_length, including null (2 bytes).
     168 *   Password string (n bytes, null terminated).
     169 *
     170 * The P_DATA payload represents encrypted, encapsulated tunnel
     171 * packets which tend to be either IP packets or Ethernet frames.
     172 * This is essentially the "payload" of the VPN.
     173 *
     174 * P_DATA message content:
     175 *   HMAC of ciphertext IV + ciphertext (if not disabled by
     176 *       --auth none).
     177 *   Ciphertext IV (size is cipher-dependent, if not disabled by
     178 *       --no-iv).
     179 *   Tunnel packet ciphertext.
     180 *
     181 * P_DATA plaintext
     182 *   packet_id (4 or 8 bytes, if not disabled by --no-replay).
     183 *       In SSL/TLS mode, 4 bytes are used because the implementation
     184 *       can force a TLS renegotation before 2^32 packets are sent.
     185 *       In pre-shared key mode, 8 bytes are used (sequence number
     186 *       and time_t value) to allow long-term key usage without
     187 *       packet_id collisions.
     188 *   User plaintext (n bytes).
     189 *
     190 * Notes:
     191 *   (1) ACK messages can be encoded in either the dedicated
     192 *       P_ACK record or they can be prepended to a P_CONTROL message.
     193 *   (2) P_DATA and P_CONTROL/P_ACK use independent packet-id
     194 *       sequences because P_DATA is an unreliable channel while
     195 *       P_CONTROL/P_ACK is a reliable channel.  Each use their
     196 *       own independent HMAC keys.
     197 *   (3) Note that when --tls-auth is used, all message types are
     198 *       protected with an HMAC signature, even the initial packets
     199 *       of the TLS handshake.  This makes it easy for OpenVPN to
     200 *       throw away bogus packets quickly, without wasting resources
     201 *       on attempting a TLS handshake which will ultimately fail.
     202 */
     203}}}