Language Selection

English French German Italian Portuguese Spanish

Another Protocol Bites The Dust

Filed under
Security

For the last 6 weeks or so, a bunch of us have been working on a really serious issue in SSL. In short, a man-in-the-middle can use SSL renegotiation to inject an arbitrary prefix into any SSL session, undetected by either end.

To make matters even worse, through a piece of (in retrospect) incredibly bad design, HTTP servers will, under some circumstances, replay that arbitrary prefix in a new authentication context. For example, this is what happens if you configure Apache to require client certificates for one directory but not another. Once it emerges that your request is for a protected directory, a renegotiation will occur to obtain the appropriate client certificate, and then the original request (i.e. the stuff from the bad guy) gets replayed as if it had been authenticated by the client certificate. But it hasn’t.

Not that the picture is all rosy even when client certificates are not involved.




Vulnerability in SSL/TLS protocol

h-online.com: According to reports, vulnerabilities in the SSL/TLS protocol can be exploited by attackers to insert content into secure connections. If this is correct, it would affect HTTPS and all other protocols which use TLS for security, including IMAP. The precise effects of the problem are not discussed in the reports. It would, however, appear to be possible to manipulate HTML content from websites during data transfer and, for example, inject malicious code.

The crux of the problem is, rather than a flawed implementation, a design flaw in the TLS protocol when renegotiating parameters for an existing TLS connection. This occurs when, for example, a client wants to access a secure area on a web server which requires the requesting client certificates. When the server establishes that is the case, it begins a renegotiation to obtain the appropriate client certificate. The original request gets replayed during this renegotiation as if it had been authenticated by the client certificate, but it has not. The discoverer of the problem describes this as an "authentication gap".

Rest Here

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Why open source programming languages are crushing proprietary peers

It's no secret that open source now dominates big data infrastructure. From Kubernetes to Hadoop to MongoDB, "No dominant platform-level software infrastructure has emerged in the last ten years in closed-source, proprietary form," as Cloudera chief strategy officer Mike Olson reminded us. Read more

CORD becomes a Linux Foundation project

Central Office Re-architected as a Data Center (CORD), an open source integrated solutions platform for service providers leveraging merchant silicon, white boxes, and open source platforms such as Open Network Operating System (ONOS), OpenStack, Docker, and the cloud operating system XOS, is now part of the Linux Foundation as a new independent project. The Linux foundation is already home to many open source networking projects, including OpenDaylight and ONOS, so CORD is a natural fit for the non-profit foundation. Read more

Google beefs Linux up kernel defenses in Android

Future versions of Android will be more resilient to exploits thanks to developers' efforts to integrate the latest Linux kernel defenses into the operating system. Android's security model relies heavily on the Linux kernel that sits at its core. As such, Android developers have always been interested in adding new security features that are intended to prevent potentially malicious code from reaching the kernel, which is the most privileged area of the operating system. Read more

Fork YOU! Sure, take the code. Then what?

There's an old adage in the open source world – if you don't like it, fork it. This advice, often given in a flippant manner, makes it seem like forking a piece of software is not a big deal. Indeed, forking a small project you find on GitHub is not a big deal. There's even a handy button to make it easy to fork it. Unlike many things in programming though, that interaction model, that simplicity of forking, does not scale. There is no button next to Debian that says Fork it! Thinking that all you need to do to make a project yours is to fork it is a fundamental misunderstanding of what large free/open source projects are – at their hearts, they are communities. One does not simply walk into Debian and fork it. One can, on the other hand, walk out of a project, bring all the other core developers along, and essentially leave the original an empty husk. This is what happened when LibreOffice forked away from the once-mighty OpenOffice; it's what happened when MariaDB split from MySQL; and it's what happened more recently when the core developers behind ownCloud left the company and forked the code to start their own project, Nextcloud. They also, thankfully, dropped the silly lowercase first letter thing. Nextcloud consists of the core developers who built ownCloud, but who were not, and, judging by the very public way this happened, had not been, in control of the direction of the product for some time. Read more