XTrustProvider security hole

You're right that even when using the XTrustProvider class the likelihood of a breach is pretty slim. Someone would have to have a pretty specific idea of what they're attacking and would need to compromise the network before being able to attack, which would hopefully be difficult itself (again, assuming the management interface isn't made public, though generally that's a safe assumption).

 

 

However, there are vectors of attack that wouldn't require the attacker to gain control of part of the network. If they were able to get a payload onto the machine of whoever is running the iControl stuff then they could attack that way. Consider the (pretty useful) application Fiddler (http://fiddlertool.com/fiddler/). It's an application that you can run on the client which shows a log of all HTTP/HTTPS traffic. The newest version is even able to decrypt the SSL traffic, and I believe it's doing a form of man-in-the-middle "attack". Fiddler itself is just a debugging tool and isn't malicious, though something similar could probably be created and used as a payload in some kind of virus attack (which, unfortunately, do make it into corporate networks every once in a while). Granted, if you're able to drop a payload on someone's machine there are probably worse things that could be done (keyloggers, etc), but it is a possible attack vector.

 

 

Both of these situations are incredibly unlikely, to the point that 99.9...% of the time you can probably ignore them. However, as BIG-IP solutions become more widespread and as iControl is utilized in more situations, the miniscule chance of an attack grows (as does the chance of someone putting the management interface on a public network, purposefully or otherwise). I think it would be best to remove vulnerabilities before the chance of it being exploited becomes too high.

 

 

It's also possible that there are other types of attacks that could exploit this vulnerability that I/we can't think of. The way I see it, just because I can't think of a more feasible way to exploit this doesn't mean someone else couldn't. As such, I'd rather plug the hole and remove the possibility of some clever attacker finding a way to exploit it.

 

 

I agree the best solution would be to purchase real certs. With fully valid certs I don't think you'd have to add the cert to the store either, as I would expect most packages to already have some trust stuff implemented to be able to handle certs from globally trusted sources. If security is of highest priority then this is probably the solution that should be used.

 

 

As for the solution we both suggested (number 2 in your list), it wouldn't necessarily prevent an attack but it would reduce the possibility and help to detect one. True, if the system is already compromised when you run the first time you will get the compromised cert. This solution won't protect against that scenario. However, it will protect against someone compromising the system at a later date. The chances of a compromise increases over time, and this solution is a way to mitigate that. As long as things are fine at the very beginning when you install the cert you can then use that valid cert to detect/prevent compromise in the future.

 

 

In the end this discussion may simply be academic but I do believe it's an important one to have. Especially if BIG-IP/iControl will be used in environments where security is of utmost importance (like government networks, etc).