What is the impact of a server not fully verifying the data in the Client Finished packet of a TLS connection? F5 BIG-IP devices suffer from a vulnerability in which not all bytes of the Finished packet in a TLS connection are validated. The sort-of technical description can be found here. F5 don't consider it a vulnerability, so they won't patch it, and it is currently causing me a headache right now for PCI compliance reasons. At the moment nobody seems to agree on whether there's a bug or not, and there's not really a clear explanation of the actual impact and attack requirements.

My understanding is that the Client and Server Finished packets in TLS are designed to post facto mutually authenticate the handshake messages, including the master secret key exchange. My thought process is that, if an attacker were to man-in-the-middle the TLS connection, they could leverage this vulnerability to downgrade the connection by spoofing the Client Finished packet, or possibly even compromise the master secret. I'm unsure as to how the process would go from there, with the validation of the Server Finished packet on the cient.

Assuming that some arbitrary number of bytes in the Finished packet are not properly validated, what's the real impact of this vulnerability? With this bug in play, does the security of the connection mostly rely on the client's validation of the Server Finished packet?
Suppose the server does not check the Client Finished value.  This means that the MITM could change some handshake messages and the server would not know this (e.g., downgrade, as you mentioned).  So, you could use this to fool a server that doesn't check the Client Finished value.  

If n bits are checked by the server, you have a 1/2^n chance of getting the Client Finished value right by random chance.  You might be able to predict the remaining client messages and then use brute force to try different random handshake modifications offline until one generates the correct finished bits in the n locations that the server will validate.  This will take about 2^n tries, which for small n is feasible.  By sending this handshake sequence you can fool the server into thinking the client sent the modified handshakes.

Now, the server sends back a Server Finished message, which includes a hash of all the messages the server has seen, including the Client Finished value.  Your modified handshakes will completely change the hash value for the Server Finished.  As a result, you're stuck having to brute-force all the bits that the client checks in addition to those the server checks.  If the client is lazy and only checks m bits, then overall you're looking at 2^(n+m) tries, which might be feasible.  However, if the client validates the full server finished, you'll have to break all 12 bytes, or 96 bits, which won't be easy to brute force before the connection times out.

Security (defined here as the number of brute force attempts to get the two Finished messages to validate) depends roughly on the total number of bits the client and server check, so if the server does not check any bits then the security relies, as you said, on the client's validation of the Server Finished message.  

You mentioned changing the master secret.  This could allow the MITM to create a valid connection to the server (e.g., if RSA key exchange is used).  However, the MITM does not know the master secret the client is using, since the server private key is required, so for the Server Finished message you have the problem of determining the encryption and MAC keys.  If you negotiate a weak cipher suite with the client, this might be easier than brute forcing the Server Finished message.

Other attacks may be possible based on the configuration of the client and server, so it's best if the server fully validates the Client Hello to mitigate them.