I read that the theoretical weakness in SSL has been proven real. Is there a workaround that we can apply as users or admins to protect our users/selves?


The hole only allows for data to be injected, if that injection can cause a data leak of some kind, then you'll need to re-work the server side program to ensure that injected data cannot cause the leaking of sensitive information.

That is, the user's session remains secure on the outbound side (that is, server to client), those communications remain secret, the communications from the inbound side (client to server), the data from the client still remains secret as well, however, that data can have information appended or prepended to it by a man-in-the-middle attack.

So, there is no need for a workaround unless your server/service is made to be vulnerable by this type of attack, and if it is, then the workaround would be specific to your web application.

  • @IceMage So the MitM can't steal any information unless the injected data somehow causes the server to behave "insecurely" in possibly future communication? Would this example work: If the SSL client is providing the server with a list of trusted IP addresses, the MitM can possibly add his IP own to the list and join the trusted list? Assuming the server will consume the augmented packet the same way. – MandoMando Nov 18 '09 at 20:15
  • Theoretically, yes. For an attacker to successfully exploit the SSL vulnerability, they'll have to know what the SSL data looks like, not necessarily what the data is. They would likely replace the entire list with a list of their own. Another thought came to mind. When this type of exploit is executed, the resulting page usually generates erratic data of some form or another. You could instruct your program to ignore any changes to this list if the data it receives is erratic in any way. – IceMage Nov 18 '09 at 20:23

The attack suggests an ability to present data under the trusted credentials of the client which depending on your environment and the uses of the end servers in question could lead to privilege escalation and the like.

The risk is proportional to the data your protecting and the lengths someone would go to to steal it.

Practically the documents suggest little defence. As the problem is an attack from beneath the protocol i.e. below the transport layer then using IPSEC could be an option. This would work best in a closed population of users whereby you have control of the end machines. IPSEC would be less suitable fro an general uncontrolled Internet environment.

Mark Sutton

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.