Hmm. I think I agree with you that it isn't practical in HTTPS. I can see clearly why you can't do anything like this in TLS 1.3 because it has this nice simple ordering - the client and server do DH key agreement - we now both have encryption but no certainty of who we're talking to - then the server sends a certificate and uses the key from that certificate to sign their DH transcript, the client optionally also sends a certificate, they too use the key from that certificate to sign the transcript. Since I don't know Alice's Private Key I cannot sign transcripts while presenting the (Bob,A) certificate, and if I let Alice do the key exchange so that she'll sign, I'm cut out of the loop entirely. That's easy to follow.
But in TLS 1.2 and earlier it's murkier to me because there are cases with and without DH, and what gets signed, by who, and when varies. I think you're right, but I started doodling the possible cases out and I filled two A4 pages before I gave up. Certainly even if you're right as to how the protocol is designed it will not astonish me if somebody implements it wrong and doesn't check a signature somewhere given the many cases.
But in TLS 1.2 and earlier it's murkier to me because there are cases with and without DH, and what gets signed, by who, and when varies. I think you're right, but I started doodling the possible cases out and I filled two A4 pages before I gave up. Certainly even if you're right as to how the protocol is designed it will not astonish me if somebody implements it wrong and doesn't check a signature somewhere given the many cases.