README
¶
Signed Hypertext Protocol (SHP)
===============================
Overview
The Signed Hypertext Protocol (SHP) is a backward-compatible extension to HTTP that provides cryptographic proof of content integrity from origin server to browser rendering. While TLS secures the communication channel, SHP secures the content itself — protecting against compromised CDNs, malicious proxies, and parser ambiguity attacks.
Key Innovation: SHP enables browsers to switch to strict, deterministic parsing mode when content signature is valid, eliminating entire classes of injection vulnerabilities while improving performance.
[Origin Server] ──signs──> [CDN] ──forwards──> [Proxy] ──forwards──> [Browser]
↑ ↓
└─────────────────signature verification──────────────────────verifies
The Problem
1. TLS Protects Transit, Not Content
Current web security relies on TLS, which only guarantees channel security. It cannot prevent:
- Compromised CDNs injecting malicious code (Polyfill.io, 2024)
- Corporate proxies modifying HTML
- Cached content tampering
- Man-in-the-Middle at SSL termination points
2. Parser Ambiguity Creates Vulnerabilities
HTML parsers must "guess" structure when encountering malformed markup. This non-deterministic behavior:
- Enables mutation XSS attacks
- Creates exploitable browser-specific heuristics
- Wastes 15-20% of parsing time on error recovery
- Makes security audits impossible (behavior unpredictable)
The Solution
Core Mechanism
- Server validates HTML against strict schema before transmission
- Server signs content using TLS certificate private key
- Browser verifies signature matches content hash
- Strict mode enabled if signature valid; legacy mode if invalid
Graceful Degradation (Not XHTML's Draconian Failure)
| Signature Status | Browser Behavior |
|---|---|
| ✓ Valid | Strict parser (fast), security indicator shown, privileged APIs enabled |
| ✗ Invalid | HTML5 quirks mode (compatible), security indicator removed |
| ⊘ Missing | HTML5 quirks mode (backward compatible) |
Result: User experience preserved, security posture visible.
HTTP Headers Example
http
HTTP/2 200 OK
SHP-Version: 1.0
SHP-Signature: iQIzBAABCAAdFiEE...
SHP-Algorithm: SHA256-RSA2048
SHP-Timestamp: 2025-11-20T10:30:00Z
Content-Type: text/html
Content-Validation: strict
<!DOCTYPE html>
<html>
<!-- Validated and signed content -->
</html>
Browser Polyfill (Works Today)
For browsers without native SHP support, include JavaScript validator:
html
<!DOCTYPE html>
<html>
<head>
<meta name="shp-signature" content="[base64-signature]">
<meta name="shp-pubkey" content="[public-key]">
<script src="https://cdn.shp-protocol.org/polyfill.min.js"
integrity="sha384-..."></script>
</head>
<body>
<!-- Content validated before render -->
</body>
</html>
See: examples/polyfill/shp-verify.js for minimal implementation.
Why SHP?
Security Benefits
- Prevents CDN compromise attacks: Invalid signatures detected immediately
- Eliminates parser ambiguity exploits: Strict mode deterministic
- Enables non-repudiation: Proof of content origin for legal/compliance
- Reduces attack surface: Estimated 40-60% reduction (requires validation)
Performance Benefits
- Deterministic parsing: Identical DOM structure across all browsers
- Reduced attack surface: No parser ambiguity exploits
- Future performance: Browsers can optimize trusted-content parsers (see spec § 9.4)
Developer Experience
- Validation at build time: Catch errors before deployment
- Consistent cross-browser behavior: DOM structure identical everywhere
- Security by default: Opt-in to strictness without breaking legacy sites
Comparison with Existing Standards
| Feature | HTML5 | XHTML | SXG | SHP |
|---|---|---|---|---|
| Strict validation | ✗ | ✓ | N/A | ✓ |
| Backward compatible | N/A | ✗ | ✓ | ✓ |
| E2E integrity | ✗ | ✗ | ✓ | ✓ |
| Graceful degradation | N/A | ✗ | N/A | ✓ |
| Uses standard TLS certs | N/A | N/A | ✗ | ✓ |
| Browser support | All | Dead | Chrome only | All (polyfill) |
Key distinction: SHP combines SXG's integrity with XHTML's strictness, while maintaining HTML5's pragmatic compatibility.
Project Status
Current Phase: Research proposal
Seeking: Academic partnership for validation (MIT CSAIL)
Completed
- Protocol specification (draft)
- Threat model analysis
- Polyfill architecture
- Research proposal (25 pages)
In Progress
- Reference implementation (validator in Go/Rust)
- Working polyfill demonstration
- Performance benchmarking suite
- Formal security analysis
Planned
- Pilot deployment (Ukrainian government portals)
- Academic publication (security conferences)
- W3C standardization proposal
- Browser vendor engagement
Documentation
- Full Research Proposal (7,500 words) — Technical specification, threat analysis, adoption strategy
- Specification Draft (RFC-style) — Protocol details, cryptographic parameters
- Polyfill Example — Minimal JavaScript implementation
Use Cases
Government & High-Security Sectors
- Electronic government services (e-government portals)
- Financial transactions (banking, payments)
- Healthcare systems (HIPAA compliance)
- Legal documents (non-repudiation required)
Enterprise
- Corporate intranets (protect from proxy injection)
- SaaS applications (prove content authenticity)
- API documentation (guarantee accuracy)
General Web
- News sites (prevent content manipulation)
- E-commerce (protect checkout flows)
- Social platforms (verify post integrity)
Getting Started
For Researchers
- Read the full proposal
- Review threat model analysis
- Explore research questions
- Contact us about collaboration
For Developers
- Clone this repository
- Try the polyfill example
- Run validation tests:
npm test - Read implementation guide
For Organizations
- Review deployment guide
- Assess cost-benefit analysis
- Pilot SHP on test servers
- Contact for consultation
FAQ
Q: Won't this break existing websites?
A: No. Sites without SHP work exactly as today. SHP is opt-in via HTTP header.
Q: How is this different from HTTPS?
A: HTTPS protects the channel (client ↔ CDN). SHP protects the content (origin ↔ browser), even through compromised intermediaries.
Q: Why not use Signed HTTP Exchanges (SXG)?
A: SXG requires special certificates and focuses on prefetching. SHP uses standard TLS certs and focuses on parsing security.
Q: What's the performance overhead?
A: Signature verification: ~1-2ms. Initial parsing: similar to HTML5. Future: browsers can optimize for trusted content (potentially 15-30% faster when ecosystem matures).
Q: Who will adopt this?
A: Government regulation (like GDPR) can mandate SHP for public portals. Financial/healthcare sectors adopt for compliance.
Research Partnership
This project seeks academic validation from leading institutions. We're particularly interested in:
- Formal verification of security properties
- Performance benchmarking (strict vs. tolerant parsing)
- Attack surface analysis (fuzzing, penetration testing)
- Adoption studies (developer tooling, UX)
Contact: If your research group is interested in web security, cryptography, or systems performance, let's collaborate.
About
Author: Ruslan [Last Name]
Role: Technical Director & Integration Specialist
Location: Ukraine
Context: Developed while maintaining critical infrastructure security under adversarial conditions
Background:
- 20+ years enterprise IT experience
- Expertise in legacy system integration (AXapta 2009 ↔ modern tech)
- Proven rapid protocol development (TDTP: 5 days specification → production)
- Real-world security validation in high-threat environment
Contributing
This is currently a research project. Contributions welcome after initial validation phase.
Ways to help:
- Review specification for security issues
- Implement parsers in different languages
- Benchmark performance
- Suggest use cases
- Report vulnerabilities
See CONTRIBUTING.md for guidelines.
License
MIT License — See LICENSE file.
Note: Protocol specification itself is public domain (like HTTP/HTML specs). Implementations may use any license.
Contact
Project Discussion: GitHub Issues
Security Issues: security@shp-protocol.org (PGP key in repo)
General Inquiries: contact@shp-protocol.org
Academic Collaboration: research@shp-protocol.org
Acknowledgments
Inspired by:
- Tim Berners-Lee (HTTP/HTML architecture)
- XHTML Working Group (strict validation vision)
- Signed HTTP Exchanges team (content integrity)
- Browser security researchers (attack surface reduction)
Built in Ukraine 🇺🇦 during challenging times — demonstrating that innovation persists under adversity.
Status: Active research project | Last updated: November 2025
Directories