Adding a signature even over HTTPS

Question

HTTPS already has sufficient signing to prevent accidental modifications.

A straight message digest with no secrets provides no protection against deliberate tampering. An active man-in-the-middle attacker could easily replace the digest with their own value, recalculated to match any alterations they made.

For a signature to have value against tampering it must have been created using a secret key on the sender, and the signature must be verifiable on the receiver, which means you must have a way to pre-exchange keys between parties before use.

For the case where the client is a general purpose web browser there is no channel to do that, other than transferring it over HTTPS at which point that interaction is just as vulnerable to man-in-the-middle attacks and you gain nothing. This is a bootstrap problem.

For the case where you have a custom application client you have distributed to your users through a channel more trusted than HTTPS (eg you physically handing them copies of the code), then yes, adding a server-to-client signature based on public key crypto could theoretically provide some value. But rolling your own crypto is prone to implementation errors and best avoided.

What's the attack you're trying to counter here, that HTTPS together with the commercial CA infrastructure doesn't address well enough?

If your concern is that the PKI of commercial CAs is historically prone to occasional fraudulently-issued certificates and state-level spying, then a much simpler way of defending against that would be to run your own private CA for application use, and have your client accept only certs issued by that CA (and not the certificates built into the system like Verisign et al).

Whether through running a CA, or ad hoc signature checking, running your own PKI securely and effectively is a bunch of ongoing overhead. Be sure the public commercial PKI really can't meet your needs before going that route.