[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3884: HTTPS storage client logic when server's private key doesn't match public key, and when cert is signed by well-known CA (was: Test what happens in HTTPS storage client logic when server's private key doesn't match public key)

[Tahoe-LAFS]

#3884: HTTPS storage client logic when server's private key doesn't match public
key, and when cert is signed by well-known CA
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:
         Type:  task      |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------
Description changed by itamarst:

Old description:

> 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?

New description:

 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.

--

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