> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Tony Girgenti > Sent: Tuesday, June 28, 2016 08:26 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] Getting error 'SSLv2_client_method': identifier > not found > > I forget where I downloaded OpenSSL from, but all I did was download a zip > file and unzipped all the file to a folder called: OpenSSL-Win32. > > From there, I simply pointed my Visual Studio project properties directory > search for includes and lib files to that folder. I did not compile or > change anything in that folder.
Linking against a security component of unknown provenance? Let's just say that would not be my preferred approach. Of course this points to one of the (many) problems with TLS: It's not easy to get it into your application. Open-source implementations (OpenSSL, GnuTLS, LibreSSL, NSS, CyaSSL, ...) are not trivial to work with. Many OSes come with some TLS implementation installed by default or as an add-on package, but then you have to work with their API, build, configuration, etc, which often raises issues with portability; and if, say, you're trying to use an application (or other component) that's built to use OpenSSL, then Microsoft's SChannel isn't going to do you much good. That said, it's not that hard to read the instructions, download the OpenSSL tarball, verify its signature, and build it. Then all you have to worry about are the myriad difficulties of using the OpenSSL API, dealing with the wide array of SSL and TLS protocol and ciphersuite pitfalls, navigating the nightmarish bog of X.509-certificate PKIs, diagnosing obscure failures, educating users, ... TLS is a solution that asymptotically approaches being worse than the problem. (Now I want that on a t-shirt.) But at the moment there are no viable alternatives for most use cases. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
