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

Openwashing

Mentor Embedded Linux adds SMACK security and IoT support

Mentor Graphics has updated Mentor Embedded Linux (MEL) with Yocto Project 2.0 code, SMACK security, and support for CANopen, BACNet, and 6LoWPAN. Mentor Graphics has spun a more secure and industrial IoT-ready version of its commercial Mentor Embedded Linux (MEL) distribution and development platform that moves up to a modern Linux codebase built around Yocto Project 2.0 (“Jethro”). Yocto Project 2.0, which advances to GCC 5.2 and adds Toaster support, among other enhancements, was recently adopted by rival embedded distro Wind River Linux 8. Read more

Development News

  • GHC performance is rather stable
    Johannes Bechberger, while working on his Bachelor’s thesis supervised by my colleague Andreas Zwinkau, has developed a performance benchmark runner and results visualizer called “temci”, and used GHC as a guinea pig. You can read his elaborate analysis on his blog.
  • Ready for a nostalgia kick? Usborne has put its old computer books on the web for free
    UK publishing house Usborne is giving out its iconic 1980s programming books as free downloads. The books, which are available for free as PDF files, include Usborne's introductions to programming series, adventure games, computer games listings and first computer series. The series was particularly popular in the UK, where they helped school a generation of developers and IT professionals.
  • LLVM Patches Confirm Google Has Its Own In-House Processor
    Patches published by Google developers today for LLVM/Clang confirm that the company has at least one in-house processor of its own. Jacques Pienaar, a software engineer at Google since 2014, posted patches today seeking to mainline a "Lanai" back-end inside LLVM. He explained they want to contribute their Lanai processor to the LLVM code-base as they continue developing this back-end with a focus on compiling C99 code. He mentions Lanai is a simple in-order 32-bit processor with 32 x 32-bit registers, two registers with fixed values, four used for program state tracking, and two reserved for explicit usage by user, and no floating point support.

Security Leftovers