Web Security Disasters (1991-2025)
That Lock Icon Has a Story
Okay, elephant in the room: this is part 1 of a trilogy. But here’s why that matters - like MCP itself, this story starts slow then hits ludicrous speed. Don’t blink during Part 2 or you’ll miss the entire future of AI tooling.
This isn’t just a security story. It’s about how context became the missing ingredient that made SSL/TLS take 30 years to get right, and how that same principle revolutionized AI protocols in just 8 months.
📖 Part 1 Focus: The complete web security evolution (1991-2025)
🚀 Coming Up: Part 2 reveals how MCP learned from these disasters
🔧 Part 3: Building context-aware systems the Terry way
Pre-2025 web ‘evolution’ seemed fast at the time. Below I’ll show you what real speed looks like.
Seriously, software development, as any profession that deeply affects humans (and the world we live in) is an art. I’m not saying everyone is a good artist.
I’m saying that some do it for the dough, others do it for ❤️. Promise this is valid context for this exciting journey ahead.
For shits and giggles, take a side trip to 🔗 first website EVER! - don’t forget to come back!
🔐 That Lock Icon in Your Browser
HTTP - the thing that makes the 🕸️ web work. Every time you type a URL, click a link, or submit a form, (most of your ‘phone calls’ too!) you’re using HTTP. It’s the universal language that lets your browser talk to servers. Without it, there’d be no web as we know it. No Amazon, no social media, no cat videos. HTTP is so ubiquitous that we don’t even think about it - it’s just there, like electricity or running water.
Al Gore didn’t invent the internet, a huge posse of people did. Read on to learn more.
HTTP 0.9 was introduced in 1991, it did one thing: GET. This is analogous to the introduction of MCP in Nov. 2024.
It was almost a year later in 1992 before Tim Berners Lee @timb️ added very basic, completely insecure Basic Authentication.
4 years later, RFC 1945 is born: HTTP/1.0
🥸 Because https wasn’t a thing yet, a better name would have been
whisper your password quietly and hope no one is listening. Fun fact, it usesBase64encoding. It’s basically a=1, b=2, etc.
‘That’ll Do’ Years (1994-200X)
You gotta understand - everything was new. I mean EVERYTHING. We didn’t have the computing primitives we take for granted today. JavaScript? Didn’t exist until December 1995. CSS? Not until 1996. Hell, most people were still using dial-up modems that made sounds like R2-D2 having a seizure.
We were literally building the foundations of modern computing while standing on quicksand. Every “standard” was really just “what Netscape/Microsoft/Cisco/start-up/whoever did last week.”
Meanwhile, the webmasters/technicians/engineers/administrators/sysops, and a bunch of other amazing trade workers, factory workers… I can’t name everyone. Let’s just say lots of people did their ‘thing’ and figured it out, invested their time, toil and creativity.
Everyone had to constantly adapt, adjust and ‘MacGyver that shit’.
The fact that ANY of this worked is a minor miracle. The fact that we’re still using evolved versions of these technologies in 2025? That’s testament to how solid these foundations turned out to be.
1994 🍪 Can I Haz Cookie?
Lou Montulli, founding engineer at Netscape, ran into a fundamental problem with the HTTP protocol: it’s stateless.
This means your browser has amnesia - every time it talks to a server, it’s like they’ve never met before. The server has no memory of previous requests. Now you could build something like a virtual shopping cart, or do nefarious tracking of unknowing users.
Montulli devised the “cookie” as a small piece of data that the server could send to the browser, which the browser would then store and send back with every subsequent request to that same server. This allowed the server to “remember” the user across multiple page views, enabling login sessions, shopping carts, and personalization.
Side-timeline on cookies: it was 1995 when the public could use Cookies, if they had the latest Netscape, IE followed suit. Keep in mind, it would take hours to download and you might not have a way to “back-up” your hard drive. You might not have enough space either :D
It took until February 1997 for RFC 2109 to make cookies “official.” It was 2011 before there were any significant cookie updates.
1995 SSL 2.0 (and HTTP/1.0)
In February 1995, Netscape released SSL 2.0 to the world. Now we’ve got “secure” communications! Well, sorta…
Meanwhile, HTTP/1.0 (RFC 1945) showed up late to the party in November 1995, basically documenting what everyone was already doing in the wild.
1996 SSL 3.0
SSL 2.0 was broken faster than a politician’s promise, so in 1996 they released SSL 3.0. Third time’s the charm, right?
This time, they brought in the big guns. Paul Kocher (a 23-year-old cryptography wunderkind), Phil Karlton, and Alan Freier completely redesigned the protocol from scratch. No more band-aids on bullet wounds. Kocher, who would later win the Marconi Prize for this work, built something that was actually… good?
The genius of SSL 3.0 wasn’t just that it fixed the security holes - it was designed to evolve. Kocher anticipated that future research would discover new attacks and algorithms, so he built in the ability to negotiate sessions and swap out weak algorithms for stronger ones without breaking the whole system.
Fun fact: Kocher was mostly self-taught in cryptography and originally planned to be a veterinarian. Instead, he ended up securing the entire internet. Life’s funny that way.
1997 HTTP/1.1 - The Real Deal
In January 1997, HTTP/1.1 (RFC 2068) finally arrived with the killer feature: the Host: header.
🚀 This allowed servers to host more than one ‘domain’ on a server. For you newbs, back in the day, if you wanted to run more than one
website, you needed another physical server. You might even need a bridge or MAU (shout-out to TokenRing).
As far as security goes, it was a little bit better. Every time a server prompted for a password, it would send a “nonce” - a random one-time-use password. Kinda like those annoying “2FA” messages… 📟
The client would use the nonce and hash it up with the username and password.
A modern computer can “crack” this type of hash in 10 minutes (way faster on the big iron).
1999 TLS 1.0
So 🥳 party on right? Haha, not so fast there keyboard commander. SSL “3.0” was broken as a politician’s promise (love u Grandpa)!
No big deal, IETF “fixed” it in January 1999 with “TLS 1.0” (RFC 2246).
The name change was because Netscape ‘owned’ SSL. Cue modem sounds…
Oh no, 1.0 - those are always broken right?
Speaking of v1.0… Y2K!
While we were all panicking about two-digit years breaking everything, we were literally sending passwords in plain text over the internet. Y2K: the greatest misdirection in tech history.
Fun fact: More damage was probably done by companies rushing untested Y2K “fixes” into production than the actual date rollover would have caused. But hey, at least consultants got new boats!
I finished my schooling and ‘officially’ entered the workforce during peak Y2K hysteria. First lesson learned: fear sells better than actual security fixes.
2000’s - The Certificate Authority Gold Rush
During these ancient times, it was not only rocket-science to get a certificate (WtF is a CSR? You want me to run what commands?) - you had to pay.
Certificate Authorities
🌐 Network Solutions, 👯♀️ GoDaddy, and others made a small fortune on certificate signing. Safe estimates of 💰 $700M to $1.5B (big B!) annually
2006 TLS 1.1
Yeah, TLS 1.0 was broken alright, and it wasn’t a ‘legal issue’ this time. In 2006 it was fixed with TLS 1.1. I’m sure everybody updated all their software…
First Rule of Programming
Never ‘roll your own’ encryption. Not everyone listens (and that’s a good thing IMHO).
Some cool cats (and countless other direct and indirect contributors) were like, “someone’s gotta do it,” so they did (keep reading for details).
Who knows what goes on in the mind of folks on this level? I can only imagine, and probably not vividly enough.
On behalf of the entire human race, I want to thank all the folks that made our world! There are so many, but I’m gonna talk about two:
Tim Dierks 🔗
A Long History with TLS: Tim Dierks has been a central figure in the development of TLS for a very long time.
Before authoring TLS 1.2, he was also a co-author of the previous versions, TLS 1.0 (RFC 2246) and TLS 1.1 (RFC 4346).
Role as Editor: His role was that of an “editor” or lead author for the IETF working group. He was responsible for taking the discussions, proposals, and consensus from the community and drafting them into a coherent and precise technical specification.
Industry Experience: At the time, he had extensive experience in the security industry, having worked for companies like Certicom (a pioneer in elliptic curve cryptography) and was later a key engineer at Google. His deep, long-term involvement made him the natural choice to continue leading the documentation of the protocol’s evolution.
Eric Rescorla 🔗
A Renowned Security Expert: Eric Rescorla is one of the most respected and influential figures in applied cryptography and internet security. He is a prolific researcher and engineer who has contributed to numerous security standards.
Deep Technical Expertise: He brought immense technical depth to the project. He is the author of the widely respected book “SSL and TLS: Designing and Building Secure Systems” and has taught security courses at Stanford University.
The Future of TLS: His involvement didn’t stop with 1.2. Underscoring his central role in the protocol’s evolution, Eric Rescorla went on to become the sole author of the next-generation standard, TLS 1.3 (RFC 8446), which was a massive overhaul of the protocol.
Industry Leadership: He has held prominent roles, including CTO of the Mozilla Foundation, where he was responsible for the security and technical direction of the Firefox browser.
2008 TLS 1.2
So two years go by, Tim and Eric (renowned developers, we can’t thank these people enough 🙏) are finally starting to sleep at night. The recurring nightmare of their elderly parents asking why ‘this nice, foreign sounding man said he has my login?’.
I might have made part of that up, but you get the point.
Untold umteen-quadrillions of ‘secure’ bytes served, PCI DSS was breathing down the necks of everyone!
Proactively, a team led by Tim and Eric made many improvements and TLS 1.2 was released.
And they all lived happily ever after… Nope. It lasted until the BEAST showed up in 2011.
Insider secret: there were many powerful organizations that were aware of this. SSL was never secure. If you look at the history of electronic communication, it never was/is. Unless you are the “powerful organization”. Turns out that’s not all you need, just ask Pete Hegseth :)
2011 BEAST - Browser Exploit Against SSL/TLS
Turns out TLS 1.2 still allowed for insecure “encryption” in older browsers. This was done intentionally (~2007), to make sure nobody was left out. The Internet was booming at that time, and nobody wanted to waste their precious SEO money and find out their mom can’t get to their website on her “old computer”. It was probably on AOL, and hadn’t been “updated” since the factory.
You gotta understand, back then it was really slow to “Update your Apps” - many of the applications in use didn’t even support automatic updates, or you had to pay for them.
2014 💔 Heartbleed 🩸 AND POODLE!
❤️🔥 The internet was on fire! Padding Oracle On Downgraded Legacy Encryption. Again, older browsers were at risk. SSL 3.0 allowed for insecure communication!
Heartbleed was the worst… The code was broken. Catastrophic bug in OpenSSL. This time the protocol was fine - someone just built it wrong. Like having perfect blueprints but using duct tape instead of rivets.
Too bad it was “THE” implementation of it. Not only on just about everyone’s computer/phone, but also in every server, camera, and every other dumb-idea-connected-to-the-internet (see here for an index).
I can recall stories of people scrambling asking “who knows how to work on OpenSSL?“.
2015 😱 FREAK (Mar) & 🪵 Logjam (May)
Again, legacy browsers supporting 90’s “export-grade” (so-called cryptography) was weak sauce! They were part of a series of major SSL/TLS vulnerabilities that highlighted the urgent need for the kind of widespread, modern encryption that Let’s Encrypt was created to provide.
- FREAK: An attacker could trick a modern browser and server into negotiating one of these ancient, weak “export” cipher suites, which could then be broken in hours.
- Logjam: A similar attack targeting the Diffie-Hellman key exchange algorithm when used with weak, common prime numbers.
2015-2020 HTTP/2 Takes Over
While we were all distracted by TLS drama, HTTP itself got a major upgrade. HTTP/2 (based on Google’s SPDY) multiplexed connections, compressed headers, and finally made the web feel fast. By 2020, over 50% of websites were using it.
2015 🔐 Let’s Encrypt (Dec)
Finally, one of the ‘powers that be’ - a few of them actually - said enough. They have a PDF, but it was some cool cats:
- Josh Aas (of Mozilla fame)
- Peter Eckersley (EFF)
- J. Alex Halderman (University of Michigan)
These wonderful human beings were like, ‘we’ are all paying $1.5B+ a year and it’s still insecure? At the time, it was very, very common to “ignore the security error” in your browser.
Side note…
I’m not sure what motivated them, but I gotta think these super-nerds realized how damaging it was for everyone to just “ignore” the security errors.
Maybe the “certificate authorities” knew this all along and were just seeing how long they could make it work?
My optimistic view is that initially, it was pretty universally thought that if it didn’t “cost extra” and you had to fill out paperwork to get a certificate, nobody would trust it?
I don’t imagine an “app store” was in the minds of executives. As the TLS and SSL authors erred in the protocol and software implementation, so did the “business decision makers”.
Maybe some of the execs did see the light, because EFF, Mozilla Foundation, Akamai, Cisco, IdenTrust, Google Chrome, Facebook, Automattic and others busted out the checkbooks.
Woulda Coulda Shoulda
It seems that if we had it all to do over again, the certificate would be included with your domain. Why we thought ‘anybody’ should get a domain and only those that meet minimum requirements and can afford the 10-100x additional annual cost, sounds kinda ludicrous.
There were other aspects at play, probably encryption restrictions, ‘cold-war’ type stuff. It’s kinda hilarious when you consider the recent news of how government officials are conducting business on known, 3rd party channels that are insecure as it gets.
It’s my opinion that the current situation would be improved if “everybody” had access, rather than just the ‘bad actors’. Given that the public has been given proof of the messages, maybe this is the case now?
🏆 Achievement Unlocked! 🏆
You now understand web security better than people who built it in the 90s.
(Seriously, you just learned what took the industry 20 years to figure out)
🦸 2018 TLS 1.3
Finally, Eric Rescorla basically said “let’s rebuild this from scratch and do it right.” Major overhaul, tons of improvements, and here we are today - mostly secure, mostly free, mostly working. After 4 years of work and endless debate, we got a protocol that actually fixed the fundamental problems instead of just patching holes.
2022 HTTP/3 - Because Why Not?
June 2022 saw the publication of HTTP/3 (RFC 9114). The madlads threw out TCP entirely and built it on top of QUIC (which runs on UDP).
Want to hear a funny UDP joke? The problem with UDP jokes is that not everyone gets them. context
You might not get it, and I don’t care!
Yes, they rebuilt the entire internet protocol stack. Again.
The crazy part? It actually works. HTTP/3 is faster, more reliable on crappy connections (looking at you, mobile networks), and handles packet loss like a champ. As of 2024, 95% of browsers support it and about a third of major websites use it.
Looking at Cloudflare Radar, you can see the stats:
- HTTP/1.x: ~10%
- HTTP/2: ~60%
- HTTP/3: ~30%
So here we are in 2025. From “please don’t look at my password” in 1991 to quantum-resistant encryption and protocols that can handle your phone switching from WiFi to 5G without missing a beat. Not bad for 34 years of duct tape and good intentions.
The Plot Twist Coming in Part 2
Here’s the thing: 30 years. That’s how long it took to get web security mostly right.
But what if I told you there’s a protocol that learned from ALL these mistakes and went from “hey, here’s an idea” to “Google, OpenAI, and Microsoft are all in” faster than it took SSL to get its first bug fix?
What if I told you it happened in 8 months?
Part 2 reveals: How MCP (Model Context Protocol) speedran the entire evolution we just witnessed, why context was the missing ingredient all along, and what happens when AI tools finally learn to explain themselves.
Spoiler: It changes everything.
📢 Enjoyed this journey through web history?
Share Part 1 with that friend who thinks they know everything about web development.
(Then blow their mind with Part 2 when it drops)
🎉 ACHIEVEMENT: SECURITY HISTORIAN 🎉
You just learned what took the industry 20+ years to figure out.
Ready for the revolution? Part 2 awaits…