The format of an encrypted record in TLS can depend on the protocol version and (part of) the ciphersuite selected.
Even a null-encryption suite (which only exists through 1.2) still does MAC for message integrity (aka data authentication); for your example this is HMAC-SHA1. See rfc5246 184.108.40.206 (this one is the same in earlier versions); the record consists of: record header 5 bytes specifying handshake, 'content', and MAC (for HMAC-SHA1 20 bytes), where 'content' consists of handshake header 4 bytes specifying finished and verify_data 12 bytes.
The same format is used for stream cipher, except that the content and MAC are (together) encrypted by the configured cipher. However the only stream cipher in TLS was RC4, which is prohibited by rfc 7465 since 2015, so you shouldn't see this format in use. (Some implementations still can support RC4, so you might be able to use it in a test environment.)
For block ciphers using CBC mode in TLS 1.2 and 1.1, see rfc5246 220.127.116.11; the record format is record header followed by an IV and then encryption of the contents (as above) plus HMAC plus padding.
In TLS 1.0 (and SSL3) this is different, see rfc2246 18.104.22.168; instead of the IV being chosen and sent with the message, the initial IV (for the first message) is created in the key derivation, and subsequent messages are chained: the last ciphertext block of one message is used as the IV for the next message. Since the prior message can be seen on the wire, this allows a chosen-plaintext attack originally identified by Rogaway in 2002 and popularized by the 'BEAST' attack in 2011, about which this and related Stacks have numerous Qs. Note the order used in standard TLS, MAC-then-encrypt, is less secure with CBC because it allows a padding oracle, which was very severe in SSL3 (POODLE) and is less so in TLS1.0-1.2 (Lucky13). There is a recent option for 1.2 to use Encrypt-then-MAC, see rfc7366 -- but the easier and more common solution in 1.2 (and the only one in 1.3) is to use AEAD instead.
For AEAD ciphers, new in 1.2, see rfc5246 sec 22.214.171.124; this has the record header, 'explicit' part of the nonce (which in turn depends on the ciphersuite), and the authenticated encryption of content. All currently defined authenticated encryption schemes consist of encrypting content with a stream cipher (AES-CTR or ChaCha20) and appending a MAC (GMAC, CMAC, or Poly1305).
TLS 1.3 changes things. It no longer has ciphersuites of the form you reference; instead the ciphersuite specifies only the data cipher, which is always an AEAD cipher, and the hash used in key-derivation (what earlier versions called PRF); the key-exchange and entity authentication methods are selected separately. Thus 1.3 never has Finished (or anything else after CCS) in a null-encrypted record, nor a stream cipher, nor a CBC cipher. See rfc8446 5.2; now we have record header 5 bytes always specifying 'application data' (23) even for an actual handshake record, followed by the authenticated encryption (as above) of content, the real aka 'inner' record type, and optional/variable padding. In 1.3 the nonce for the AEAD cipher is (always) the record sequence number masked by a value from the key derivation, and is not sent; this is described in 5.3. Also for Finished in particular, in 1.3 verify_data is now a single HMAC (instead of the PRF in 1.0-1.2) of a very similar transcript hash, but is no longer truncated to 12 bytes and now varies with the derivation hash.