-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathblog-https-verification.html
More file actions
264 lines (249 loc) · 25.5 KB
/
Copy pathblog-https-verification.html
File metadata and controls
264 lines (249 loc) · 25.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
<!DOCTYPE html>
<html lang="en" data-theme="dark">
<head>
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-TZ23TZ28');</script>
<!-- End Google Tag Manager -->
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>How HTTPS makes any website a verification source — Burnt</title>
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<meta name="description" content="TLS certificates authenticate server identity on every HTTPS connection. Burnt uses this existing chain of trust to verify data from authenticated web sessions, turning any website into a potential verification source.">
<link rel="canonical" href="https://burnt.solutions/blog-https-verification.html">
<meta property="og:type" content="article">
<meta property="og:title" content="How HTTPS makes any website a verification source — Burnt">
<meta property="og:description" content="TLS certificates authenticate server identity on every HTTPS connection. Burnt uses this existing chain of trust to verify data from authenticated web sessions, turning any website into a potential verification source.">
<meta property="og:url" content="https://burnt.solutions/blog-https-verification.html">
<meta property="og:site_name" content="Burnt">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="How HTTPS makes any website a verification source — Burnt">
<meta name="twitter:description" content="TLS certificates authenticate server identity on every HTTPS connection. Burnt uses this existing chain of trust to verify data from authenticated web sessions, turning any website into a potential verification source.">
<meta property="og:image" content="https://burnt.solutions/images/og-image.png">
<meta name="twitter:image" content="https://burnt.solutions/images/og-image.png">
<link rel="stylesheet" href="styles.css">
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How HTTPS makes any website a verification source",
"description": "TLS certificates authenticate server identity on every HTTPS connection. Burnt uses this existing chain of trust to verify data from authenticated web sessions, turning any website into a potential verification source.",
"author": {
"@type": "Organization",
"name": "Burnt",
"url": "https://burnt.com"
},
"publisher": {
"@type": "Organization",
"name": "Burnt",
"url": "https://burnt.com"
},
"datePublished": "2026-02-05",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://burnt.solutions/blog-https-verification.html"
}
}
</script>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How does HTTPS help verify data?",
"acceptedAnswer": {
"@type": "Answer",
"text": "HTTPS uses TLS certificates to prove the identity of the server you are communicating with. When a user logs into their bank's website over HTTPS, the TLS certificate chain proves the data is coming from the real bank server. Burnt verifies this certificate chain and extracts specific data points from the authenticated session."
}
},
{
"@type": "Question",
"name": "Is this the same as screen scraping?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No. Screen scraping copies visible content without verifying where it came from. Burnt verifies the TLS certificate chain to confirm the server's identity, then extracts data from a cryptographically authenticated session. The difference is provenance: Burnt can prove the data came from the claimed source."
}
},
{
"@type": "Question",
"name": "What websites can be used as verification sources?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Any website that uses HTTPS and has a user login can serve as a verification source. This includes banks, employers, government portals, insurance carriers, airlines, utilities, and any other organization that provides user accounts. Over 95% of the web is now served over HTTPS."
}
},
{
"@type": "Question",
"name": "How does this relate to DKIM email verification?",
"acceptedAnswer": {
"@type": "Answer",
"text": "DKIM verifies data from email sources, while HTTPS/TLS verifies data from web sources. Together they cover virtually every digital data source. DKIM handles any organization that sends email. HTTPS handles any organization with a website. The combination provides near-universal verification coverage."
}
}
]
}
</script>
</head>
<body>
<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-TZ23TZ28"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
<div class="page">
<div class="post-progress"></div>
<nav class="nav"><div class="nav-inner">
<a href="/" class="nav-logo"><img class="logo-dark" src="images/Burnt-Logo-White.svg" alt="Burnt"><img class="logo-light" src="images/Burnt-Logo-Black.svg" alt="Burnt"></a>
<ul class="nav-links">
<li class="nav-dropdown"><button class="nav-dropdown-trigger">Products <svg viewBox="0 0 10 6" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M1 1l4 4 4-4"/></svg></button><div class="nav-dropdown-menu"><a href="/verify-documents.html">Verify documents</a><a href="/verify-emails.html">Verify emails</a><a href="/verify-attributes.html">Verify attributes</a></div></li>
<li class="nav-dropdown"><button class="nav-dropdown-trigger">Use Cases <svg viewBox="0 0 10 6" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M1 1l4 4 4-4"/></svg></button><div class="nav-dropdown-menu"><a href="/insurance-claims.html">Insurance & Claims</a><a href="/leasing-onboarding.html">Leasing & Onboarding</a><a href="/marketing-acquisition.html">Marketing & Acquisition</a></div></li>
<li><a href="/pricing.html">Pricing</a></li><li><a href="/blog.html">Blog</a></li>
</ul>
<div class="nav-right"><button class="nav-hamburger" aria-label="Open menu" aria-expanded="false"><span class="nav-hamburger-line"></span><span class="nav-hamburger-line"></span><span class="nav-hamburger-line"></span></button><button class="theme-toggle" aria-label="Toggle theme"><svg class="icon-sun" width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg><svg class="icon-moon" width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg></button><a href="https://truth.burnt.com/meetings/truth/product-validation?utm_source=website&utm_medium=cta&utm_campaign=blog&utm_content=nav" target="_blank" rel="noopener noreferrer" class="btn btn-primary">Schedule a demo</a></div>
</div></nav>
<section class="post-hero dot-grid">
<div class="post-hero-inner">
<div class="reveal"><div class="blog-meta">
<span class="blog-tag">Engineering</span>
<span class="blog-dot"></span>
<span class="blog-date">Feb 5, 2026</span>
<span class="blog-dot"></span>
<span class="blog-read">7 min read</span>
</div></div>
<div class="reveal reveal-d1"><h1>How HTTPS makes any website a verification source</h1></div>
<div class="reveal reveal-d2"><p class="post-hero-desc">TLS certificates authenticate server identity on every HTTPS connection. Burnt uses this existing chain of trust to verify data from authenticated web sessions.</p></div>
<div class="reveal reveal-d3">
<div class="post-author-bar">
<div class="post-author-avatar">BT</div>
<div class="post-author-info">
<span class="post-author-name">Burnt Team</span>
<span class="post-author-role">Burnt</span>
</div>
</div>
</div>
</div>
</section>
<article class="post-body">
<p>Every time you visit a website, your browser performs a security ritual that most people never notice. It checks the server's TLS certificate, verifies the certificate chain back to a trusted root authority, and establishes an encrypted connection. This happens in milliseconds, on every page load, billions of times per day across the internet. The primary purpose is security — preventing eavesdropping and man-in-the-middle attacks. But the same mechanism proves something else entirely: the identity of the server you are talking to.</p>
<p>That proof of identity is the foundation of how Burnt verifies data from any website.</p>
<h2>What does HTTPS actually guarantee?</h2>
<p>HTTPS is HTTP over TLS (Transport Layer Security). The TLS protocol does two things: it encrypts the connection so third parties cannot read the data in transit, and it authenticates the server's identity so you know who you are communicating with. The second property — server authentication — is the one that matters for verification.</p>
<p>Here is how server authentication works. When you connect to chase.com, the server presents a TLS certificate issued by a Certificate Authority (CA) like DigiCert or Let's Encrypt. That certificate binds the domain name "chase.com" to a specific public key. The CA has verified that the entity requesting the certificate controls the domain. Your browser checks the certificate's validity, confirms it was issued by a trusted CA, and verifies the cryptographic chain. If everything checks out, the browser knows — with mathematical certainty — that it is communicating with a server authorized to operate as chase.com.</p>
<p>This chain of trust is built on a hierarchy of Certificate Authorities. Root CAs are embedded in your operating system and browser. They sign intermediate CA certificates, which in turn sign server certificates. The entire chain is verifiable by anyone. The system has been running at internet scale for over two decades, and it processes billions of certificate validations every day.</p>
<h3>What the browser already knows</h3>
<p>When you log into your bank over HTTPS, your browser has already verified that you are talking to the real server. The data the server returns — your account balance, transaction history, account status — is guaranteed to come from that authenticated server. Not from a phishing site. Not from a man-in-the-middle. From the server that the Certificate Authority confirmed controls that domain. This is the same guarantee that protects online banking, e-commerce, and every other sensitive web interaction.</p>
<h2>How does Burnt use TLS for verification?</h2>
<p>Burnt builds on top of the trust that TLS already establishes. When a user needs to verify data from a web source — say, their bank balance exceeds a threshold, or their employer's HR portal shows active employment — the process works like this:</p>
<ul>
<li><strong>The user authenticates.</strong> The user logs into their account on the relevant website (their bank, employer portal, insurance carrier, government agency) through a secure browser session. Their credentials never leave the browser. Burnt does not see, store, or transmit login information.</li>
<li><strong>Burnt verifies the server identity.</strong> During the session, Burnt verifies the TLS certificate chain for the website. This confirms that the data is coming from the server that is cryptographically bound to that domain. If the certificate chain does not validate — if someone tried to substitute a different server or intercept the connection — the verification fails.</li>
<li><strong>The data is extracted and verified.</strong> From the authenticated session, Burnt extracts only the specific data point needed: account balance above threshold, employment status active, insurance coverage valid. The raw page content is processed in memory and discarded. Only the verification result persists.</li>
<li><strong>A cryptographic proof is produced.</strong> The verification result includes a proof tying the verified fact to the authenticated source. This proof is independently verifiable — a third party can confirm that the data was extracted from a session with a cryptographically authenticated server.</li>
</ul>
<p>The critical distinction is provenance. The data is not just extracted from a website. It is extracted from a website whose identity has been verified through the TLS certificate chain. The fact that the data came from the claimed source is cryptographically proven, not assumed.</p>
<h2>How is this different from screen scraping?</h2>
<p>Screen scraping and TLS-based verification may appear similar on the surface — both involve extracting data from a website. But the difference is fundamental, and it matters for anyone relying on the output.</p>
<p>A screen scraper loads a web page and copies the visible content. It might parse the HTML, extract text, and report what it finds. But it makes no assertion about where that data came from. The scraped content could be from the real website, from a cached copy, from a locally modified version, or from a completely fabricated page. The scraper has no way to tell, and neither does anyone consuming its output.</p>
<p>Burnt's approach is different in three ways:</p>
<ul>
<li><strong>Server identity is verified.</strong> The TLS certificate chain confirms that the data came from a server authorized to operate as that domain. This is not a heuristic check (like looking at the URL bar). It is a cryptographic verification against the same Certificate Authority infrastructure that secures all of HTTPS.</li>
<li><strong>Session integrity is maintained.</strong> The data is extracted from a live, authenticated session where the user has logged in. The data reflects the user's actual account state, not a public page or a cached version.</li>
<li><strong>A verifiable proof is generated.</strong> The output includes a cryptographic proof that ties the extracted fact to the authenticated session. A downstream consumer can independently verify that the data came from the claimed source.</li>
</ul>
<p>The analogy is the difference between photocopying a document and verifying it at the issuing office. A scraper produces a copy. Burnt produces a verified fact with provenance.</p>
<blockquote>Every HTTPS connection already proves you are talking to the real server. Burnt uses that proof to verify the data the server returns. The trust infrastructure was already there — we just built on top of it.</blockquote>
<h2>What does this unlock beyond email verification?</h2>
<p>DKIM-based email verification, which we covered in a previous post, is powerful but bounded. It works for any data source that sends email — which is most organizations — but it is limited to the information that appears in transactional emails. A booking confirmation contains a flight number and date. A pay notification contains a pay amount and period. But the email does not contain everything the source knows about the user.</p>
<p>HTTPS/TLS-based verification removes that boundary. It covers any data visible in a user's authenticated web session. This opens up verification sources that email cannot reach:</p>
<ul>
<li><strong>Government portals.</strong> DMV records, tax filing status, benefits eligibility, voter registration. Government agencies run web portals but rarely send detailed transactional emails.</li>
<li><strong>Bank and brokerage dashboards.</strong> Account balances, investment holdings, transaction history. These are available through authenticated sessions but are not typically emailed.</li>
<li><strong>Employer HR systems.</strong> Employment status, job title, tenure, benefits enrollment. HR portals contain rich employment data that goes far beyond what appears in a payroll notification email.</li>
<li><strong>Insurance carrier portals.</strong> Policy status, coverage details, claims history. Carrier websites display the complete policy picture, not just the summary in a confirmation email.</li>
<li><strong>Utility and service accounts.</strong> Account status, usage history, payment standing. Utility companies maintain portals with detailed account information.</li>
</ul>
<p>Together, DKIM and HTTPS/TLS cover virtually every digital data source. DKIM handles any organization that sends email. HTTPS handles any organization that runs a website. Between them, the gap in verification coverage effectively disappears.</p>
<hr>
<p>The infrastructure for web-based verification has been hiding in plain sight. TLS certificates have been authenticating server identities for decades. Every browser performs this verification automatically, on every connection, without the user or the server doing anything special. The chain of trust from Certificate Authorities to server certificates is well-established, universally deployed, and cryptographically sound.</p>
<p>It was built to secure web connections. It also happens to provide exactly the trust foundation needed to verify data from any website on the internet.</p>
<section class="post-faq">
<h2>Frequently asked questions</h2>
<div class="faq-list">
<div class="faq-item">
<button class="faq-q">How does HTTPS help verify data?<svg width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="6 9 12 15 18 9"/></svg></button>
<div class="faq-a"><p>HTTPS uses TLS certificates to prove the identity of the server you are communicating with. When a user logs into their bank's website over HTTPS, the TLS certificate chain proves the data is coming from the real bank server. Burnt verifies this certificate chain and extracts specific data points from the authenticated session.</p></div>
</div>
<div class="faq-item">
<button class="faq-q">Is this the same as screen scraping?<svg width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="6 9 12 15 18 9"/></svg></button>
<div class="faq-a"><p>No. Screen scraping copies visible content without verifying where it came from. Burnt verifies the TLS certificate chain to confirm the server's identity, then extracts data from a cryptographically authenticated session. The difference is provenance: Burnt can prove the data came from the claimed source.</p></div>
</div>
<div class="faq-item">
<button class="faq-q">What websites can be used as verification sources?<svg width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="6 9 12 15 18 9"/></svg></button>
<div class="faq-a"><p>Any website that uses HTTPS and has a user login can serve as a verification source. This includes banks, employers, government portals, insurance carriers, airlines, utilities, and any other organization that provides user accounts. Over 95% of the web is now served over HTTPS.</p></div>
</div>
<div class="faq-item">
<button class="faq-q">How does this relate to DKIM email verification?<svg width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="6 9 12 15 18 9"/></svg></button>
<div class="faq-a"><p>DKIM verifies data from email sources, while HTTPS/TLS verifies data from web sources. Together they cover virtually every digital data source. DKIM handles any organization that sends email. HTTPS handles any organization with a website. The combination provides near-universal verification coverage.</p></div>
</div>
</div>
</section>
</article>
<div class="post-share">
<span class="post-share-label">Share</span>
<a href="https://twitter.com/intent/tweet?url=https://burnt.solutions/blog-https-verification.html&text=How%20HTTPS%20makes%20any%20website%20a%20verification%20source" target="_blank" rel="noopener noreferrer" class="share-btn" title="Share on X">
<svg width="16" height="16" viewBox="0 0 24 24" fill="currentColor"><path d="M18.244 2.25h3.308l-7.227 8.26 8.502 11.24H16.17l-5.214-6.817L4.99 21.75H1.68l7.73-8.835L1.254 2.25H8.08l4.713 6.231zm-1.161 17.52h1.833L7.084 4.126H5.117z"/></svg>
</a>
<a href="https://www.linkedin.com/sharing/share-offsite/?url=https://burnt.solutions/blog-https-verification.html" target="_blank" rel="noopener noreferrer" class="share-btn" title="Share on LinkedIn">
<svg width="16" height="16" viewBox="0 0 24 24" fill="currentColor"><path d="M20.447 20.452h-3.554v-5.569c0-1.328-.027-3.037-1.852-3.037-1.853 0-2.136 1.445-2.136 2.939v5.667H9.351V9h3.414v1.561h.046c.477-.9 1.637-1.85 3.37-1.85 3.601 0 4.267 2.37 4.267 5.455v6.286zM5.337 7.433a2.062 2.062 0 01-2.063-2.065 2.064 2.064 0 112.063 2.065zm1.782 13.019H3.555V9h3.564v11.452zM22.225 0H1.771C.792 0 0 .774 0 1.729v20.542C0 23.227.792 24 1.771 24h20.451C23.2 24 24 23.227 24 22.271V1.729C24 .774 23.2 0 22.222 0h.003z"/></svg>
</a>
<button class="share-btn share-copy" title="Copy link">
<svg width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M10 13a5 5 0 007.54.54l3-3a5 5 0 00-7.07-7.07l-1.72 1.71"/><path d="M14 11a5 5 0 00-7.54-.54l-3 3a5 5 0 007.07 7.07l1.71-1.71"/></svg>
</button>
</div>
<div class="post-author-bio">
<div class="post-author-avatar">BT</div>
<div>
<h4>Burnt Team</h4>
<p>The team behind Burnt builds verified data infrastructure that goes straight to the source.</p>
</div>
</div>
<div class="post-related">
<h3>Related posts</h3>
<div class="post-related-grid">
<a href="/blog-dkim-signatures.html" class="post-related-card">
<div class="blog-meta"><span class="blog-tag">Engineering</span><span class="blog-dot"></span><span class="blog-date">Feb 18, 2026</span></div>
<div class="blog-title">How DKIM signatures make email verification possible</div>
</a>
<a href="/blog-permissionless-verification.html" class="post-related-card">
<div class="blog-meta"><span class="blog-tag">Product</span><span class="blog-dot"></span><span class="blog-date">Mar 1, 2026</span></div>
<div class="blog-title">Why we do not need API partnerships to verify data from any source</div>
</a>
</div>
</div>
<section class="sec cta-sec">
<div class="sec-inner">
<div class="reveal"><h2 class="grad-text">Turn any website into a verification source.</h2></div>
<div class="reveal reveal-d1"><p>See how Burnt uses existing HTTPS infrastructure to verify data from any authenticated web session.</p></div>
<div class="reveal reveal-d2"><div class="cta-btns"><a href="https://truth.burnt.com/meetings/truth/product-validation?utm_source=website&utm_medium=cta&utm_campaign=blog&utm_content=cta" target="_blank" rel="noopener noreferrer" class="btn btn-primary btn-lg">Schedule a demo</a></div></div>
</div>
</section>
<footer class="footer"><div class="footer-inner">
<div class="footer-grid">
<div class="footer-brand"><a href="/" class="nav-logo"><img class="logo-dark" src="images/Burnt-Logo-White.svg" alt="Burnt"><img class="logo-light" src="images/Burnt-Logo-Black.svg" alt="Burnt"></a><p>Verified data infrastructure. Prove the truth, directly from the source.</p></div>
<div class="footer-col"><h4>Products</h4><a href="/verify-documents.html">Verify documents</a><a href="/verify-emails.html">Verify emails</a><a href="/verify-attributes.html">Verify attributes</a></div>
<div class="footer-col"><h4>Use Cases</h4><a href="/insurance-claims.html">Insurance & Claims</a><a href="/leasing-onboarding.html">Leasing & Onboarding</a><a href="/marketing-acquisition.html">Marketing & Acquisition</a></div>
<div class="footer-col"><h4>Company</h4><a href="/about.html">About</a><a href="/blog.html">Blog</a><a href="/contact.html">Contact</a></div>
<div class="footer-col"><h4>Legal</h4><a href="/privacy-policy.html">Privacy</a><a href="/terms-conditions.html">Terms</a></div>
</div>
<div class="footer-bottom"><p>© 2026 Burnt. All rights reserved.</p><div class="footer-status"><span class="status-dot"></span>All systems operational</div></div>
</div></footer>
</div>
<script src="script.js"></script>
</body>
</html>