Uploaded October 2019 | Updated September 2026, 1 hour ago
With a 19 year old vulnerability, we were able to sign a message with the private key of Facebook. We'll show how we found one of the oldest TLS vulnerabilities in products of 10 different vendors and how we practically exploited it on famous sites. We'll also discuss how the countermeasures introduced back in TLS 1.0 and expanded over the years failed to prevent this and why RSA PKCS #1 v1.5 encryption should be deprecated. Finally, we'll present what related problems are still present and unfixed in many popular TLS libraries.
With a 19 year old vulnerability, we were able to sign a message with the private key of Facebook. We'll show how we found one of the oldest TLS vulnerabilities in products of 10 different vendors and how we practically exploited it on famous sites. We'll also discuss how the countermeasures introduced back in TLS 1.0 and expanded over the years failed to prevent this and why RSA PKCS #1 v1.5 encryption should be deprecated. Finally, we'll present what related problems are still present and unfixed in many popular TLS libraries.





![Black Hat USA 2018 - Stop that Release, Theres a Vulnerability!
Software companies can have hundreds of software products in-market at any one time, all requiring support and security fixes with tight release timelines or no releases planned at all. At the same time, the velocity of open source vulnerabilities that rapidly become public or vulnerabilities found within internally written code can challenge the best intentions of any SDLC.
How do you prioritize publicly known vulnerabilities against internally found vulnerabilities? When do you hold a release to update that library for a critical vulnerability fix when its already slipped? How do you track unresolved vulnerabilities that are considered security debt? You ARE reviewing the security posture of your software releases, right?
As a software developer, product owner, or business leader being able to prioritize software security fixes against revenue-generating features and customer expectations is a critical function of any development team. Dealing with the reality of increased security fix pressure and expectations of immediate security fixes on tight timelines are becoming the norm.
This presentation looks at the real world process of the BlackBerry Product Security team. In partnership with product owners, developers, and senior leaders, theyve spent many years developing and refining a software defect tracking system and a risk-based release evaluation process that provides an effective software security gate. Working with readily available tools and longer-term solutions including automation, we will provide solutions attendees can take away and implement immediately.
• Tips on how to document, prioritize, tag, and track security vulnerabilities, their fixes, and how to prioritize them into release targets
• Features of common tools [JIRA, Bugzilla, and Excel] you may not know of and examples of simple automation you can use to verify ticket resolution.
• A guide to building a release review process, when to escalate to gate a release, who to inform, and how to communicate. Black Hat USA 2018 - Stop that Release, Theres a Vulnerability!](https://i.ytimg.com/vi/BxAdOKeGD7s/mqdefault.jpg)




