tahoe-lafs/trac-2024-07-25

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 #3884

New issue

Open

opened 2022-03-28 15:49:58 +00:00 by itamarst · 1 comment

itamarst commented

2022-03-28 15:49:58 +00:00

Owner

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.

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.

tahoe-lafs added the

labels 2022-03-28 15:49:58 +00:00

tahoe-lafs added this to the HTTP Storage Protocol milestone 2022-03-28 15:49:58 +00:00

tahoe-lafs changed title 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

2022-04-14 15:53:52 +00:00

tahoe-lafs changed title 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

2022-04-14 15:54:09 +00:00

itamarst commented

2023-05-04 16:50:24 +00:00

Author

Owner

Someone who understands TLS better might be able to say "no need to test, the protocol makes these edge cases impossible"...

tahoe-lafs modified the milestone from HTTP Storage Protocol to HTTP Storage Protocol v2

2023-07-05 16:19:14 +00:00