[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3884: Test what happens in HTTPS storage client logic when server's private key doesn't match public key

[Tahoe-LAFS]

#3884: Test what happens in HTTPS storage client logic when server's private key
doesn't match public key
----------------------+---------------------------------------
 Reporter:  itamarst  |          Owner:
     Type:  task      |         Status:  new
 Priority:  normal    |      Milestone:  HTTP Storage Protocol
Component:  unknown   |        Version:  n/a
 Keywords:            |  Launchpad Bug:
----------------------+---------------------------------------
 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?

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3884>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage