Trust-Signal: A New HTTP Header for Verifying Server Authenticity through Cryptographic Signatures

[kkshitish9]

Proposal for HTTP Trust-Signal Header

Title:

Trust-Signal: A New HTTP Header for Verifying Server Authenticity through Cryptographic Signatures

---

Abstract:

The Trust-Signal HTTP header introduces a mechanism for verifying server authenticity by allowing web servers to sign their responses with a cryptographic signature. This header is designed to provide an additional layer of security, ensuring that responses come from trusted sources, and mitigating risks of man-in-the-middle attacks, phishing, and server impersonation. It provides a verifiable way for clients to confirm the integrity and origin of the data they receive.

---

Problem Statement:

Web security mechanisms, such as HTTPS (TLS/SSL) and certificates, are widely deployed but do not provide fine-grained verification for every response from the server. In some scenarios, users or applications need to verify the authenticity of the data they receive on a per-response basis, beyond the generic connection encryption and server certification.

For example:

• Phishing: Malicious actors impersonate trusted services to provide fraudulent responses.
• Man-in-the-Middle Attacks (MITM): Attackers intercept and manipulate responses, altering the content before it reaches the client.
• Server Impersonation: A server might be compromised or faked, serving content that seems legitimate but is not.

---

Proposed Solution:

The Trust-Signal HTTP header would provide a cryptographic signature for each HTTP response, ensuring the client can verify the server’s identity and data integrity for each transaction.

---

Trust-Signal Header Format:

Trust-Signal: verified; sig=<signature>

Where:

• verified: Denotes that the server’s response has been verified with a cryptographic signature.
• sig=: A cryptographic signature that corresponds to the response’s content. The signature is typically generated using a private key and can be verified by the client using the server’s public key.

---

How It Works:

1. Server-Side:

   • The server signs the response body (or selected parts of it) using a private key.
   • The server generates the Trust-Signal header, appending the cryptographic signature.

2. Client-Side:

   • The client verifies the signature using the server’s public key, which could be obtained from a trusted source (e.g., a server certificate, a dedicated public key registry, or a predefined list of trusted keys).
   • If the signature matches, the client trusts the response. If it does not, the client can reject the response or alert the user.

---

Use Cases:

1. Anti-Phishing:
   Clients can verify that the content they receive comes from the expected trusted source and not a fraudulent impersonator.

2. Man-in-the-Middle Protection:
   Even if an attacker intercepts and modifies the response, the altered response will fail the cryptographic verification, protecting the integrity of the data.

3. Sensitive Transactions:
   Applications requiring high security, such as banking or e-commerce, could use the Trust-Signal header to ensure that every critical action, like making payments or transferring sensitive data, is trusted and authenticated.

---

Security Considerations:

• Private/Public Key Management: The security of this mechanism depends on proper management and protection of the private key used for signing. Public keys should be securely distributed and accessible by clients.
• Response Integrity: The signature should cover the entire response body to prevent tampering. Partial response signing (e.g., only headers) should be avoided.
• Non-repudiation: Using cryptographic signatures provides non-repudiation, which ensures that the server cannot deny the authenticity of the signed response.

---

Example Implementation:

1. Server-Side (example in Python):

import hashlib
import base64
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding

def sign_response(content, private_key):
    # Hash the content
    digest = hashlib.sha256(content.encode()).digest()
    
    # Sign the hash with the private key
    signature = private_key.sign(
        digest,
        padding.PKCS1v15(),
        hashes.SHA256()
    )
    
    # Base64 encode the signature
    encoded_signature = base64.b64encode(signature).decode()
    return f"Trust-Signal: verified; sig={encoded_signature}"

# Example response content and private key (in practice, load from secure storage)
response_content = "User data"
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)

# Sign the response content
header_value = sign_response(response_content, private_key)
print(header_value)

2. Client-Side (Example in Python):

import base64
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding

def verify_signature(response_content, signature, public_key):
    digest = hashlib.sha256(response_content.encode()).digest()
    
    # Decode the base64 signature
    decoded_signature = base64.b64decode(signature)
    
    # Verify the signature using the public key
    public_key.verify(
        decoded_signature,
        digest,
        padding.PKCS1v15(),
        hashes.SHA256()
    )
    return True

# Example response content and public key (in practice, load from trusted source)
response_content = "User data"
public_key = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()

# Simulate the signature and verification process
signature = "<signature from server>"
verify_signature(response_content, signature, public_key)

---

Benefits:

• Increased Security: Adds a layer of security to HTTP responses, reducing the risk of impersonation and man-in-the-middle attacks.
• Trust Establishment: Allows clients to independently verify server authenticity for each response, beyond just a secure connection.
• Granular Control: Provides per-response verification, useful for sensitive content or transactions.

---

---

Conclusion:

The Trust-Signal header offers a novel way to enhance HTTP security by providing per-response cryptographic authentication. This proposal aims to give users and applications more control over the trustworthiness of responses, addressing vulnerabilities that may not be fully covered by existing mechanisms.

Let me know if you have any questions

[sbordet]

What is the reference RFC for this?

[joakime]

The OP has posted this same message in other issue trackers.

• Trust-Signal: A New HTTP Header for Verifying Server Authenticity through Cryptographic Signatures openssl/openssl#26536
• Trust-Signal: A New HTTP Header for Verifying Server Authenticity through Cryptographic Signatures envoyproxy/envoy#38150
• Trust-Signal: A New HTTP Header for Verifying Server Authenticity through Cryptographic Signatures nginx/nginx#466

@kkshitish9 many individuals make proposals for new HTTP concepts at various spec / working group mailing lists (eg: ietf-http-wg).
If the idea has merit, people with lots of experience in that spec will participate and give valuable feedback.
If the idea gets traction, then a proposed / draft spec starts getting written.

[joakime]

This proposal feels like some of the early discussion around RFC9421.

https://www.rfc-editor.org/rfc/rfc9421.html