Re: Win32 OpenSSL feature request
At 05:17 PM 1/11/2005 +0100, Erlend writeth: >Hi > >Would like to see a COM/ActiveX interface to OpenSSL, so I can use it from >vb (and possibly other languages too) > >Best regard > >Erlend S. E. Hello Erlend, I agree that this would be a really nice feature for VB users - not having to manually load the DLL and define prototypes and all that complex stuff VB doesn't do very easily...just hooking into a type library and having immediate access to all the exposed interfaces would be fantastic. However, the OpenSSL team would have to think about all of the implications of doing this in terms of what it means for OpenSSL in terms of overall system security - what would happen if someone made raw COM calls using an Internet Explorer script? Since OpenSSL has something called BIO for generic I/O, this could potentially open a security loophole in IE to write to any file on the user's system or create new ones - and since a BIO can represent a socket, this opens the door for installing spyware, desktop icons, and viruses without a user noticing and certainly without permission. Stuff like this will have to be addressed before a COM interface is created for increasing programmatic ease-of-use. Thomas J. Hruska [EMAIL PROTECTED] Shining Light Productions Home of the Nuclear Vision scripting language and ProtoNova web server. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Win32 OpenSSL feature request
The first thing is to make the dll's it stdcall friendly. :-) (at least that the state of the art 3 years ago?) Once upon a time I converted the ddls to be directly usable by VB. The main problems are decribed below. I have not ported the changes beyond 0.9.6a, maybe I should retry. A boaring point was the second one. Once you have that, then, well, it is still a pain to set ssl options, since most 'functions' are actually macros around the general ctrl interface etc. > > Hello Erlend, > > I agree that this would be a really nice feature for VB users - not having > to manually load the DLL and define prototypes and all that complex stuff > VB doesn't do very easily...just hooking into a type library and having > immediate access to all the exposed interfaces would be fantastic. > >From sylvest Mon Apr 23 17:46:44 2001 To: openssl-dev@openssl.org Subject: Re: openSSL and Visual basic > Hi > > I wanted to know if anyone has gotten openSSL to work with visual basic. If > you have, can you please let me know. It would be greatly appreciated. > > Thanks Since it happened that last week I was trying to do that for a project, here the result of some rather q&d hack with a goal to touch just a minimal number of routines in 0.9.6a - The basic approach is to compile the whole stuff with the /Gz option in order not to modify the 3000 exported function prototypes. - All main routines need a __cdecl main The #define for MAIN, all the *test.c modules, and openssl.c - The pwd_read routine needs some __cdecl in the declaration of signal and a pointer array. - in apps/s_socket.c one call to signal needs an addition of __decl for socket_cleanup - mem.c needed some treatment with Malloc, Free, Realloc The macro CRYPTO_malloc_init needs some fix, easiest way was to call with all parms NULL and tests that in mem.c Goal: allow __stdcall type functions to be passed. - There are 5 modules that call qsort and 2 that call bsearch. Instead of finding all the routines that call them, I copied qsort and bsearch into the source from mfc and made them "__stdcall friendly". It seems possible to me to aviod that and replace all the _cmp functions of stack and set comparisions by __cdecl routines, it seems that are not suppoed to be called by applications anyway. - The asm routines : all declarations either need a __cdecl or the asm routines to be modified. With the first option some routines are not callable from VB, so be it for the moment. All ms\test routines passed. I wonder whether one of the friendly developpers would like to work on this for the 0.9.7 version in one way or another, at least to minimise the migration effort a bit. Peter Sylvester __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Win32 OpenSSL feature request
At 07:05 PM 1/12/2005 +0100, Peter Sylvester writeth: > >The first thing is to make the dll's it stdcall friendly. :-) >(at least that the state of the art 3 years ago?) Well, stdcall-friendly is not necessary for COM. I was thinking a nice wrapper DLL that implemented a COM server and made the appropriate calls into the real DLLs would be sufficient. I'm just much more concerned about the security implications in terms of the OS (particularly secured user environments) and IE's ActiveX and Active Scripting interfaces provide that might open a serious security loophole if an appropriate IDispatch-derived interface were implemented in the name of making VB usable with OpenSSL. As it is, I suspect developers already make a C++ ActiveX/COM wrapper for whatever functions they need and call it from their VB program (I know a lot of VB developers do precisely this with other non-VB compliant libraries, so this is a fairly common practice). The way they do it, however, is "security through obscurity" - hackers can't really guess what the CLSID is that is involved, so the system is secured purely by the way Windows issues GUIDs. The problem comes in with a common OpenSSL CLSID. This opens a huge loophole and makes it easy to write an Active Script that utilizes the raw COM object. Most VB programmers I know can do that. OpenSSL would have script kiddies galore overnight. This is why the topic has to be carefully discussed. My recommendation is to use a registry key in HKLM with a random value and combine that with another key stored in a file that is randomly generated at COM server installation. When the COM server is called, it has to be "unlocked" with the CLSID and the randomly generated key file data before it will accept anything else. This prevents Active Scripting except in scenarios where Active Scripting allows registry AND file access. Of course, in that case, all bets are off. If anyone has a better solution, I'd like to hear it. This is about the third request I've had for a COM interface to OpenSSL. And with "better support for C#" requests looming in the distance, a COM server would solve those requests as well. In theory COM can be handled cleanly via the interop handlers .NET provides. Yeah, I know. All of this COM talk is going to make everyone here very ill. So, I'll stuff a sock in it now and wait for people to comment on this. I'd rather not develop it (I have very minimal IDispatch-level development experience and wouldn't mind knowing more, but to learn on OpenSSL...), but I will if someone would be willing to help me integrate it into the build scripts and no one else is capable of handling it (I'm not _THAT_ familiar with the OpenSSL build process). Thomas J. Hruska [EMAIL PROTECTED] Shining Light Productions Home of the Nuclear Vision scripting language and ProtoNova web server. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Win32 OpenSSL feature request
Thomas J. Hruska wrote: > The problem comes in with a common OpenSSL CLSID. This opens a huge > loophole and makes it easy to write an Active Script that utilizes the raw > COM object. Most VB programmers I know can do that. OpenSSL would have > script kiddies galore overnight. This is why the topic has to be carefully > discussed. This is a known problem with a known solution: for example, the Windows Scripting Host has its FileSystemObject, which allows you to read, write, delete, rename etc files. This is not a "huge loophole" because it has been marked as NOT "SafeForScripting", so the browser should not instantiate it from an external web page. The same logic would apply to an OpenSLL COM object. Cheers, ;-) --- ABS Web Site: www.abs.gov.au __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
