Test what happens in HTTPS storage client logic when server's private key doesn't match public key

[itamarst]

In theory one could configure a TLS server where the private key doesn't match the certificate at all. This is hard to test because OpenSSL very sensibly prevents servers from doing this.

Per Jean-Paul, this is probably not an issue in practice, but a test might still be nice-to-have:

Hm. So, the way the TLS handshake goes is ... (a bunch of stuff) ... then the client sends a "ClientKeyExchange?" message which has a "PreMasterSecret?" in it, encrypted using the public key from the server's certificate. The server must decrypt this and do a cipher-specific operation to derive the "MasterSecret?". Later the server sends its "Finished" message encrypted using "MasterSecret?". The client decrypts it to extract a hash and a MAC of all of the handshake messages up until this point.

Without the private key corresponding to the certificate it presents, the server must compute the wrong "MasterSecret?" and when the client decrypts the "Finished" message with the correct "MasterSecret?" the hash and MAC will mismatch and the handshake will fail.

So ... a test for "the server is using the wrong private key" seems like it would mostly be a test for the underlying TLS implementation (which, at worst, would be able to deliver garbage data to the client instead of properly signaling a handshake failure).

However, I probably wouldn't mind seeing a test for this case if it were possible to write one since perhaps some TLS libraries offer some ways to choose ciphers so poorly that you somehow lose the above protection (I think this would have to be roughly a choice of the NULL cipher everywhere which would be a pretty bad mistake, but ...).

That said, I don't really know how we'd write this test, given OpenSSL's behavior. My only idea is ... find a different TLS implementation that lets you do something so obviously illegal?