Opened at 2022-03-28T15:49:58Z
Last modified at 2023-07-05T16:19:14Z
#3884 new task
Improved testing for HTTPS storage client logic: when server's private key doesn't match public key, and when cert is signed by well-known CA
Reported by: | itamarst | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | HTTP Storage Protocol v2 |
Component: | unknown | Version: | n/a |
Keywords: | Cc: | ||
Launchpad Bug: |
Description (last modified by 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?
Another possible test:
One other error case that came to mind is the case of a server using a CA-issued certificate. I think this mostly overlaps with "has wrong hash" which is tested but I guess it might be nice to test separately just to be sure OpenSSL isn't somehow deciding to jump over all of our logic because it sees a signature from a well-known CA.
Of course, how to get a CA-issued certificate to use in the tests is an interesting question.
Change History (4)
comment:1 Changed at 2022-04-14T15:53:52Z by itamarst
- Description modified (diff)
- Summary changed from Test what happens in HTTPS storage client logic when server's private key doesn't match public key to HTTPS storage client logic when server's private key doesn't match public key, and when cert is signed by well-known CA
comment:2 Changed at 2022-04-14T15:54:09Z by itamarst
- Summary changed from HTTPS storage client logic when server's private key doesn't match public key, and when cert is signed by well-known CA to Improved testing for HTTPS storage client logic: when server's private key doesn't match public key, and when cert is signed by well-known CA
comment:3 Changed at 2023-05-04T16:50:24Z by itamarst
comment:4 Changed at 2023-07-05T16:19:14Z by itamarst
- Milestone changed from HTTP Storage Protocol to HTTP Storage Protocol v2
Someone who understands TLS better might be able to say "no need to test, the protocol makes these edge cases impossible"...