Making TLS More Secure, Lessons from IPv6, LLMs Finding Vulns – ASW #305

Performance is a good metric to evaluate against, especially if it's performance on top of a better security design.

It's not 100% Rust. It's more of a wrapper for AWS-LC that works within [ring], which itself "exposes a Rust API and is written in a hybrid of Rust, C, and assembly language."

But that's ok! In fact, this a good example of breaking complex systems into components and targeting the design of those components for secure use. In other words, Rustls provides a way to migrate from OpenSSL and BoringSSL to a more memory-safe library that increases security for the users of that library. In other words, Rustls also makes it hard to misuse its OpenSSL-like API.

On the theme of OpenSSL, here's a low-risk vuln that's not a cause for concern. As the disclosure notes, "Any problematic use-cases would have to be using an "exotic" curve encoding." -- something that's not going to happen (or be triggered to happen) in all the default deployments out there.

What I really wanted to highlight from this article is its attribution. The Google OSS-Fuzz-Gen found it. My growing hypothesis is that fuzzing remains the most efficient and economical way of finding flaws at scale, especially if you compare the CPU cycles spent between fuzzing and LLMs. Everyone loves to talk about LLMs these days. They're full of promise and fun and hallucinations and use cases for which we probably do have better tools.

With Google and Apple, both with massive browser market share, pushing on this. It feels pretty inevitable -- as a positive security goal to strive for.

Section 4.2.1 lays out the proposed timeline, with a 45 day lifetime once April 2027 rolls around.

I've long admired the Let's Encrypt project for addressing two key costs related to managing TLS certs. One, making certs freely available. Two, providing tools and automation to reduce the overhead of managing them. (I touched on this a bit in a blog post of my own.)

As the article notes, "…the first complete specification of the IPv6 protocol, was published in December 1998, over 25 years ago." That was literally the era of Windows 98 (and the movie, "You've Got Mail" for you Tom Hanks, Meg Ryan, and AOL fans out there).

I like the history this goes into about IPv4 and IPv6. And I like even more how it explains why the push for IPv6 seems to have stalled -- and why that's not necessarily a bad thing.

My mind also went to the appsec parallels. We've had very slow uptake on TLS versions until recently when the browser makers pushed for stricter defaults. (I think the PCI DSS helped here as well. Or it at least helped immensely more than lots of appsec conferences and checklists did.)

So what are the lessons from this IPv6 transition? How do they apply to appsec? What are the great transitions we'd like to see? Is it memory safe languages -- even though most web apps are already written in memory safe languages?

This is a cool mitigation, but there's also the aspect that it's a cool mitigation that's very, very specific to Chrome. That's not necessarily bad if we take a harm reduction view of appsec -- Chrome represents a massive user base and attack surface. What will be interesting is seeing if this is successful in eventually protecting glibc by default so lots of other software benefits without having to make any changes.

I'll throw this onto the "six months" later list to talk about with John.

Also check out the introduction to mseal on LWN.

I'm not going to hype up AI and, despite the catchy title of the article, they don't exactly promise LLMs as the magical hacking tool of the future.

Here's their pitch: "Instead of overwhelming the LLM with multiple whole files, it smartly requests only the relevant portions of the code, performing surgical strikes rather than carpet-bombing the entire codebase. It automatically searches the project files for files that are likely to be the first to handle user input. Then it ingests that entire file and responds with all the potential vulnerabilities."

With a caveat that "…because LLMs aren’t deterministic, one can run the tool multiple times on the exact same project and get different results."

They also talk about drawbacks of a RAG approach they tried and problems with parsing Python into an AST.

Overall, I'm still sticking to my hypothesis that CPU cycle-for-CPU cycle, fuzzers are more effective and economical than LLMs for finding flaws. (And, yes, we've seen some combinations of the two, with LLMs crafting a corpus or tuning fuzzers -- that seems like a great thing to do!)

Check out the repo.

It's a good list of practices that lots of orgs should follow. But...it just doesn't feel like a secure by design list.

I'll concede some processes around the full lifecycle of an app are important, but it feels heavy on the practices of managing vulns as opposed to preventing them. It'd be great to see more examples and guidance on the reducing entire classes of vulns aspect. That feels like an area where appsec can really step up with better discussions on what it means to have a secure design that are more meaningful than "do input validation".

The 404 Media site is one of my favorite sources of tech news. There's a contingent out there who just wants to answer the question, "Can it run DOOM?" But behind that kind of trick are a lot of interesting and impact questions on how to do hardware hacking and how to do that hacking legally -- something that feels like a throwback to the 90s, but remains a modern concern from tractors to trains to medical devices (and to McFlurry machines!?).

Also check out this other article on hardware hacking.

Do you have a favorite CVE?

More details on Apple's security blog.