> You have lots of good points. Thank you again. You're welcome.
> I work for AOL, developing cross platform SDK for instant messaging that > supports plugins. Plugins can be malicious. And AOL is responsible for > protecting users' identity and privacy. Considering our user base, a > trojan is more likely to target our users than to protect them. So you need a "security" scheme for plugins that covers more than just OpenSSL. Any mechanism that could subvert OpenSSL could subvert other plugins. > What do the majority applications do on Unix if static linking with > openssl isn't suitable? > > Thanks. > > Yvonne You have a very tricky problem. In general, an attacker needs to do three things: 1) Get malicious code to run on your machine. 2) Get access to sensitive information in his malicious code. 3) Pass that information to himself from the malicious code. You can attack any of these three points. It sounds like plugins to an instant messaging platform make attacking 2 or 3 impossible, so you're back to 1. Couldn't anyone could do 1 also put his code in front of your SDK? (or trace your SDK as it talks to client applications). It seems like if you have to attack 1, you have to do it at the system level. (Or you have to come up with a way for applications to validate their own context and then validate the SDK before they start talking to it.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
