1
$\begingroup$

I want to sign all of the HTML and JavaScript from my site with the site's TLS private key.

(The hex signature will be preceded with a <!-- comment which is valid for both HTML and JavaScript, and attached to the end of the text files.)

This is so that end users can prove that malicious JavaScript came from us, and so gain confidence that we would never do so.

Are there any security problems when using this the same private key for both TLS encryption and application-level signing?

Improve this question
$\endgroup$
4
  • $\begingroup$ What kind of private key is it? Is it an ECDSA key? I hope so. ;) Or is it an RSA key? $\endgroup$
    – real-or-random
    Commented Mar 25, 2022 at 11:04
  • 1
    $\begingroup$ I think your usecase can be covered with subresource integrity don't you think? $\endgroup$
    – DannyNiu
    Commented Apr 22, 2022 at 11:08
  • 2
    $\begingroup$ If the server is compromised so that malicious code can be injected, the server's private key for SSL is likely compromised as well. $\endgroup$
    – Zac67
    Commented Apr 22, 2022 at 14:05
  • $\begingroup$ I'm wondering how the signature is going to be checked. How to handle the key management is the trick, and it is also where possible issues lie - especially you haven't indicated how the corresponding public key is going to be trusted. If the key management is handled properly then it could possibly add a bit of security. If the key is compromised then both the signature for TLS authentication and HTML signing will become compromised, but that's OK if they are used for about the same purpose. $\endgroup$
    – Maarten Bodewes ♦
    Commented Apr 22, 2022 at 18:22

2 Answers 2

Reset to default
2
$\begingroup$

You could sign the files using the server TLS private key for sure. Then on the client side, you could retrieve the TLS certificate used for the HTTPS link using some code e.g. with OpenSSL as I wrote here, and verify the signature.

But is it worth it? In security, reinventing the wheel is not very safe. The algorithm you would come with is likely to be broken.

Ensuring data is not tampered between the server and the client is already what TLS does - in an audited way. If some attacker is able to tamper your files on the server, it is also possible that he/she would be able to add its own certificate. So your whole signature process would become pointless.

I would stick to rely on TLS, and use a separate certificate if you really need to validate a file content. I would use the TLS private key only for TLS/HTTPS, not anything else.

Improve this answer
$\endgroup$
1
$\begingroup$

The term tls private key is ambiguous. The PRF generates from the negotiated premaster secret a whole bunch of different keys depending on the selected cipher suite. May be you mean the private key from the certificate used for the server authentication. In this case you must analyse whether the attacker can influence the content you respond and sign. In some scenarios this can empower him to generate the correct signature of the manipulated message without the knowledge of the private key.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.