HTTPS Session Origin Validation

TL;DR

Yes, a trusted third party can validate the origin of an HTTPS session using techniques like Certificate Transparency (CT) logs and OCSP stapling. However, complete trust relies on the security of that third party and the underlying infrastructure.

How Third Parties Validate HTTPS Session Origins

1. Certificate Authority (CA) Trust: The foundation is trusting a Certificate Authority. Browsers come with a pre-installed list of trusted CAs. When you connect to an HTTPS website, your browser checks if the site’s certificate was issued by one of these trusted authorities.
   • A third party can verify this trust chain programmatically using libraries in various languages (e.g., Python’s ssl module).
2. Certificate Transparency (CT) Logs: CT logs are publicly available records of all certificates issued by CAs. This helps detect mis-issued certificates.
   • Third parties can query these logs to confirm a certificate exists and hasn’t been revoked.
   • Tools like crt.sh allow manual searching, or APIs can be used for automated checks.
3. Online Certificate Status Protocol (OCSP) Stapling: OCSP allows real-time verification of a certificate’s revocation status.
   • Instead of the browser contacting the CA directly, the web server ‘staples’ the OCSP response to the TLS handshake.
   • Third parties can inspect this stapled OCSP response during connection analysis.
4. DNSSEC: Domain Name System Security Extensions (DNSSEC) adds cryptographic signatures to DNS records, verifying that a domain name resolves to the correct IP address.
   • A third party can check DNSSEC records to ensure the website you’re connecting to is genuinely associated with the domain it claims.
5. HPKP (HTTP Public Key Pinning) – Deprecated: Previously, websites could ‘pin’ specific certificates or public keys in the browser. This meant only those pinned certificates were trusted.
   • This is largely deprecated due to usability issues and complexities.

Practical Steps for Validation

1. Check the Certificate Chain: Use a tool like OpenSSL to inspect the certificate chain.

   openssl s_client -connect example.com:443

   Examine the output for the issuer and subject of each certificate in the chain.

2. Verify CT Log Inclusion: Use crt.sh to search for the domain’s certificate.
   • If found, check the log entries for validity dates and issuing CA.
3. Inspect OCSP Stapling: Tools like Wireshark can capture TLS handshakes and reveal the OCSP stapled response.

   Look for the certificate_status extension in the handshake.

4. DNSSEC Validation: Use a DNS lookup tool that supports DNSSEC (e.g., dig with the +dnssec option).

   dig example.com +dnssec

   Check for the presence of RRSIG records, indicating DNSSEC is enabled.

Limitations

• Trusting the Third Party: The third party performing validation must be trustworthy. Their security infrastructure and processes are critical.
• CA Compromise: If a CA is compromised, it can issue fraudulent certificates that may pass initial checks. CT logs help mitigate this but aren’t foolproof.
• Revocation Issues: OCSP servers can be unreliable or slow, leading to inaccurate revocation status information.