Does SafeOnline protect from SSL renegotiation Man-in-middle??

Hi Prevx,
Just came across a paper on how a SSL man-in-middle attack is possible. Does PrevX SafeOnline protect against such a threat ?

Source:
http://extendedsubset.com/?p=8

 

Yes it detects and prevents janus.

 

How would it? I don't believe SafeOnline does protocol analysis and re-assembly to see something like that.

 

This is correct - this exploit, as far as I can tell, exists at the conceptual level within the protocol itself. If malware was to try and inject itself into the HTTPS stream we'd block it from doing so but it is out of the scope of Prevx to look for these malformed packets (as far as I can tell from my reading of it).

 

Vijay,

It cannot protect against such an attack unless it was coming from a process on the client machine. If malware were set up as a proxy MITM that takes advantage of this flaw, it would work well. If the MITM were on the wire, through an insecure access point or router, SafeOnline could do nothing to prevent this attack.

 

Hi Jduncan,
Thanks for the reply and clarification. So if I understand correctly PrevX secures the browser only and doesn't work on the packet level. I was unclear of the meaning of "man-in-the-browser" term used in your website, but now I understand that you prevent browser hijack.
So firewalls (which can act as SSL proxy/gateway) would probably be the best bet against this new vulnerability.

Thanks,
Vijay

 

Hi Vijay,
I'm not affiliated with this product whatsoever, I work as a network admin at a different company, and in fact I don't use PrevX (though it does look interesting, I'm not a desktop guy).

The man-in-the-browser is a local proxy attack, where your browser or computer routes traffic through a server running on your own machine, or through an external server run by malicious people, but directed by local malware.
SafeOnline could prevent such an attack, I can't verify whether this is the case.

But a firewall/proxy still cannot protect against such an attack, without severely limiting your access to external servers.

Part of the handshake a client and server use to establish a secure connection involves a request for a new cipher, our systems can use several types of encryption, and the client and server can negotiate which to use when communicating. Because the server doesn't know the client before they 'meet' there is a rule written into TLS that makes it possible for the client to request a new set of rules for encryption.

This attack takes advantage of that rule, the bug is written into the protocol, it is not a flaw in code, but a flaw in procedure. The only real protection against such an attack is at the client server level.

The SSL/TLS server must ignore requests for renegotiation from the client after the initial connection is made, this means that a client that doesn't support a given servers available ciphers will not be able to renegotiate a properly secure connection and the server will reject the connection.

One could filter for such renegotiation requests at a firewall and filter them out or reject the traffic, but this leads to an unfortunate situation.

Many installations out there rely upon renegotiation to set encryption based upon server rules. A client connects to a server, and the server checks to see whether encryption is required for the connection, prehaps based upon which directory is being requested from the server. Since the server cannot know whether or not to encrypt traffic until it receives the request, it performs a server initiated renegotiation, at which point the man in the middle attack is possible.

In short, if we were to patch servers to deny renegotiation, many sites would cease to function.

Long term, all clients and servers will need to be changed to use a new protocol that protects against the man in the middle attack, new browsers, new servers. In the interim, a server that doesn't need renegotiation can be patched to block all requests for renegotiation, this is what we're doing at my firm. We are lucky in that we use hardware SSL terminators and that our vendor is working directly with us to patch our hardware. Our servers will be protected against this mitm attack soon. But for the vast majority of sites out there, this attack will be too costly to ameliorate, and until people use new browsers with a new TLS protocol, this attack will be possible.

 

Thank you for the detailed response, jduncan!

 

Hi Jduncan,
Thanks for the detail reply and now I am well informed about the "man-in-the-browser" scenario.
Agree with you assessment on firewall/gateway plan. You can't really block SSL renogotiation, but we are adding a whitelist filter as temporary filler. Until a new RFC arrives ...

 

Can you elaborate on a whitelist filter? I'm curious where you're adding it and which function it serves.
Thanks!

 

We are whitelisting limited employee and customers IP/MAC combo in the firewall and blocking other SSL traffic et al. Its rudimentary, but its a stop-gap solution.
Fortunately our services are not open to all, so we can take this extreme step. But the same may not be applicable to other models.

 

It is a step in the right direction, but it won't stop a man-in-the-middle, they will be using the same MAC address from the same IP, and will issue a renegotiation request on your client's behalf.

Look into the device that services TLS/SSL, if it is a web server, look into what provides the TLS/SSL encryption, if it is openssl, there is a patch available that denies renegotiation.
If your server determines eligibility of encryption based upon directory or user, like with an Apache directive, then you will need to replace this method, perhaps with separate web servers.
You can't wait for a new RFP, then all of the browsers and servers to implement the new RFP, then for all of your users to install and use the new clients, that is unreasonable and will take far too long.

Focus on making it so your site can perform encryption without renegotiation and cover the issues that this may present, then the MITM attack will fail no matter what client is accessing your server.

 

Thanks, jduncan for the info.
Better look into openssl. We provide custom web services, maybe some of my developers can mimick/deploy the patch given by openSSL.