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 business should bet on open source

Among the benefits of OSS is that it is hardly ever a standalone product. Most OSS is built on other open-source projects. Because of the way it is licensed, these enhancements are then passed back to the open-source community, so the software constantly evolves. So, if such open-source technology is readily available, and has proved its scalability in webscale businesses, why reinvent the wheel? Open source is certainly more accepted in the enterprise, said Tony Lock, distinguished analyst at Freeform Dynamics. “It is suitable for all businesses, not just for webscale businesses.” Read more

Lubuntu 15.10 Beta 1 Still Doesn't Use LXQt, Now Powered by Linux Kernel 4.1 LTS

The development team of the Lubuntu Linux operating system were among the last to announce the release of the first Beta build of the Ubuntu 15.10 (Wily Werewolf) release for opt-in flavors. Read more

NetworkManager 1.0.6 Adds Support for Wake-on-LAN Configurations, More

Lubomir Rintel informs users about the release and immediate availability for download of the sixth maintenance version of the open-source NetworkManager network connection management utility for GNU/Linux operating systems. Read more

GNOME 3.17.91 beta tarballs due (and more) (responsible: jjardon)

We would like to inform you about the following: * GNOME 3.17.91 beta tarballs due * String Freeze Tarballs are due on 2015-08-31 before 23:59 UTC for the GNOME 3.17.91 beta release, which will be delivered on Wednesday. Modules which were proposed for inclusion should try to follow the unstable schedule so everyone can test them. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 3.17.91. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! Read more