SSL and TLS Authentication Gap vulnerability discovered
Last updated on: December 20, 2022
A serious vulnerability has been discovered in the way web servers utilise SSL (and TLS, up to the most recent version, 1.2), effectively allowing an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. Both the Apache web server and the IIS have been found to be vulnerable.
The problem is with the renegotiation feature, which allows one part of an encrypted connection (the one taking place before renegotiation) to be controlled by one party with the other part (the one taking place after renegotiation) to be controlled by another. A MITM attacker can open a connection to an SSL server, send some data, request renegotiation and, from that point on, continue to forward to the SSL server the data coming from a genuine user. One could argue that this is not a fault in the protocols, but it is certainly a severe usability issue. The protocols do not ensure continuity before and after negotiation.
To make things worse, web servers will combine the data they receive prior to renegotiation (which is coming from an attacker) with the data they receive after renegotiation (which is coming from a victim). This issue is the one affecting the majority of SSL users.
The following example demonstrates how the flaw can be exploited by an attacker to send an arbitrary request using the authentication credentials of a victim. The red parts are sent by the attacker and the blue parts are sent by the victim.
GET /path/to/resource.jsp HTTP/1.0 Dummy-Header: GET /index.jsp HTTP/1.0 Cookie: sessionCookie=Token
The good news is that, although the attacker can execute an arbitrary request, he will not be able to retrieve the corresponding response. On the negative side, the client will see something different from that what she requested.
You can see that GET attacks are essentially trivial to execute. To date, no one has claimed a successful execution of a POST request using this flaw. Until someone does, that means that an application that only makes changes in response to POST requests will probably not be vulnerable. Further, an application not vulnerable to CSRF attacks will probably be safe too, because the attacker won’t be able to generate or predict the token required for the request to go through.
- If you can, disable renegotiation. There isn’t normally a configuration option to do this, but patches are being developed and will be available soon. The majority of web sites do not use renegotiation so disabling it won’t be a problem. Those that do will need to make changes to their sites to make them work without it.
- Use a web application firewall to monitor the contents of all request headers to spot what seems like an embedded HTTP request line. The good news is that the embedded request line will not be obfuscated, making it easier to detect. I do not believe that this advice can help the bypass of the client certificate authentication, though.
- If you can, monitor all connections that make use of the renegotiation feature. That won’t help you if renegotiation is an integral feature of your web site, but it may do if it is rarely used.
- Marsh Ray’s blog post (Marsh discovered the problem a couple of months ago) contains a detailed description of the problems in the attachment.
- The post by Martin Rex to the TLS mailing list that prompted public disclosure.
Web services proxied behind our Microsoft Forefront Threat Management Gateway 2010 systems are receiving an “F” on the SSL test due to the fact that they support insecure client-initiated renegotiation.
I’ve looked into how to mitigate this, and the fix seems to be to install Microsoft KB980436 and change the AllowInsecureRenegoClients DWORD value at HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\ to “0”; however, this appears to break Microsoft Outlook for Mac clients (including Outlook 2016 for Mac) when Exchange is proxied by TMG (see Microsoft KB2955530).
Since we need to support Outlook for Mac in our environment, are we basically stuck with an insecure TLS setup/F rating on the Qualys SSL Labs SSL Test for our TMG servers? Is there any configuration of TMG 2010 on Windows Server 2008 R2 in an environment supporting Outlook for Mac possible where it gets something higher than F?
Thanks for the heads up Scott! This is just plain silly… It is really strange that there has not been any updates for the Mac on this.
how did you install KB980436 hotfix on Win2008R2 server? I´ve got Standard edition and after I run msu file, it says “this update is not applicable to your computer”.
It probably says not applicable because it is included in SP1.
I’ve got the impression that the test for this on your page is not 100% accurate. For our Oracle HTTP Server with
it still says that our server is vulnerable. While http://ssl-checker.online-domain-tools.com/ and https://sslanalyzer.comodoca.com say that everything is ok. What exactly is checked in that test?