We are looking at implementing secure sockets in our c++ application using the OpenSSL library. We'd like to use the openssl.cnf file to set which ciphers are acceptable to use. We've looked at the documentation and other posts regarding OpenSSL but we are still unsure whether the OpenSSL library automatically uses the settings in the openssl.cnf file or whether we need to write code to read in the values from openssl.cnf and set the values in the library. Could we get some clarification on this ?
If the OpenSSL library automatically uses the settings how does it find the openssl.cnf file if you choose not to use the OPENSSL_CONF environment variable ? For instance, is it possible to set the location of the openssl.cnf in C++ code or is there any other way to configure where the openssl.cnf file is located for a specific application?
The config file is always loaded by default for all OpenSSL based applications as of OpenSSL 3.0 (for the default library context). Here is the relevant CHANGES entry:
https://github.com/openssl/openssl/blob/97446da7e05bd7164f5c36b68b8bef13a63e06a5/CHANGES.md?plain=1#L1819-L1824
The config file is loaded by default for libssl based applications only as of OpenSSL 1.1.1. Here is the relevant CHANGES entry:
https://github.com/openssl/openssl/blob/97446da7e05bd7164f5c36b68b8bef13a63e06a5/CHANGES.md?plain=1#L2942-L2944
For versions of OpenSSL older than 1.1.1 you have to explicitly load the config file.
If the OPENSSL_CONF environment variable is set then it will use that location in preference. If it is not set then it will load it from OPENSSL_DIR/openssl.cnf where OPENSSL_DIR is defined at compile time.
The value of OPENSSL_DIR for your particular build of OpenSSL can be determined via openssl version -d. For me that is:
$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
You can choose to load the config file programmatically if you wish. If you do that then it should probably be the first thing you do with OpenSSL (otherwise it might load it automatically anyway). For OpenSSL 3.0 you can use OSSL_LIB_CTX_load_config for this:
https://www.openssl.org/docs/man3.0/man3/OSSL_LIB_CTX_load_config.html
You can also use this function to load a config file for a non-default library context.
For older versions of OpenSSL you can load a config file via the CONF_modules_load_file function. You can also do this with 3.0 but OSSL_LIB_CTX_load_config is the preferred way.
https://www.openssl.org/docs/man3.0/man3/CONF_modules_load_file.html
Related
I've been trying to setup Xcode with OpenGL, but I can't get it to work.
I have been getting this error every time:
dyld: Library not loaded: /usr/local/opt/glfw/lib/libglfw.3.dylib
Referenced from: /Users/parisjackson-newman/Library/Developer/Xcode/DerivedData/GLFW_OpenGL-fjibdenxheioomgsseembfpbmeih/Build/Products/Debug/GLFW OpenGL
Reason: no suitable image found. Did find:
/usr/local/opt/glfw/lib/libglfw.3.dylib: code signature in (/usr/local/opt/glfw/lib/libglfw.3.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
/usr/local/lib/libglfw.3.dylib: code signature in (/usr/local/lib/libglfw.3.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
/usr/local/Cellar/glfw/3.3.2/lib/libglfw.3.3.dylib: code signature in (/usr/local/Cellar/glfw/3.3.2/lib/libglfw.3.3.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
(lldb)
I used home-brew to install glfw and glew. And the code I am running is the standard window code from the glfw.org website
Go to your Project Navigator and select your project.
Then, go to the Hardened Runtime section under the Signing & Capabilities tab.
Click the checkbox for Disable Library Validation.
Once this is done, you should be able to run your project.
Seems root issue
install glfw from a package manager like brew brew install glfw
xcode search headers path usr/local/include
xcode search libraries path usr/local/lib
I'm working on an application that uses Boost.Beast and TLS connections. As part of my application's build process, I need to compile OpenSSL into a static library. OpenSSL takes a long time to compile and I'm trying to reduce the build time. I see that OpenSSL's config script has many options for disabling parts of the library.
Is there a list of all the OpenSSL options that I can safely disable, and still be able to use TLS connections via Beast?
The reason I'm not using the preexisting shared library is that I want to be able to deploy a portable, self-contained binary to a target device other than my development PC.
For convenience, here is the link to the OpenSSL document listing config options: https://github.com/openssl/openssl/blob/master/INSTALL
I am not aware of an exhaustive list.
A good start are the build options for embeded systems like openwrt.
https://github.com/openwrt/openwrt/blob/master/package/libs/openssl/Makefile
or buildroot.
https://github.com/buildroot/buildroot/blob/master/package/libopenssl/libopenssl.mk
To set CAINFO option on CURL* currently I am including the CACert.pem file downloaded from https://curl.haxx.se/ca/cacert.pem with the binary.
Is there a way to have that file included within project so that its within binary and there is no need to explicitly specify CAINFO option?
I believe there is some way, because the same calls without setting CAINFO work on OSX where I am using system curl library.
It depends!
libcurl itself can get built to use a large number of different TLS libraries and they all have their own little differences. The devil is really in the details as usual.
mac
The "native" libcurl on macOS is built to use the internal "secure transport" TLS library and by default it uses the internal "trust store" that Apple ships. Most applications thus won't need to provide any CA certs.
Many people are however opting to use their own custom build on mac as well and then it may use nother TLS library (mostly done since the native mac one is fairly limited in functionality).
windows
Similarly, libcurl on windows built to use schannel (the native windows TLS solution) can use the Windows internal trust store.
A libcurl on Windows that is built to use OpenSSL, however - which is the most popular TLS library choice - needs a separate and provided trust store to use, since it won't use the default one. You can then provide that trust store either as a separate file to pass to libcurl or you set it using the CURLOPT_SSL_CTX_FUNCTION callback as show in the cacertinmem example from the curl web site.
I have quick yes/no question. Till this moment I wrote my code using original libmysql.dll but it turns out that it is not available on Linux (correct me if I am wrong). So I read that MySQL C++ Connector is available on Linux as well. I need to write my code multi-platform because it is server that need to run on Windows and on Linux.
The question: Is MySQL C++ Connector without any other additions ready to use to connect to my database? If not -> what libraries should I also download?
Yes, you need that library, but it ships with the connector:
To use the static Connector/C++ library, link against two library files, libmysqlcppconn-static.a and libmysqlclient.a. The locations of the files depend on your setup, but typically the former are in /usr/local/lib and the latter in /usr/lib. The file libmysqlclient.a is not part of Connector/C++, but is the MySQL client library file distributed with MySQL Server. (Remember, the MySQL client library is an optional component as part of the MySQL Server installation process.) The MySQL client library is also available as part of the Connector/C distribution.
(http://dev.mysql.com/doc/connector-cpp/en/connector-cpp-apps-linux-netbeans.html)
Anyway, you didn't actually need to switch libraries, because libmysql.dll is the Windows shared library for Connector/C which, like Connector/C++, is certainly also available on Linux and many other operating systems. You just need to download the correct binary for your platform.
Simply visit the project webpage for all the details and downloads you could ever need:
https://dev.mysql.com/downloads/connector/c/
https://dev.mysql.com/downloads/connector-cpp/
Is it somehow possible to use SQLite with C++ on an Android phone? I haven't found any documentation around how this could be possible.
Just download the SQLite3 amalgamation source file from:
http://www.sqlite.org/download.html
And then add sqlite3.c to your LOCAL_SRC_FILES variable in Android.mk.
It isn't possible to use the built-in SQLite via NDK (or it wasn't six months ago when I looked into this), that can only be accessed with Java. However it may be possible to link in your own completely separate C++ build of SQLite.
See SQLite Android Bindings http://www.sqlite.org/android/doc/trunk/www/index.wiki which describes how to include sqlite3 for Android targets 15 (4.0.3) and greater. It's copied below.
SQLite Android Bindings
The SQLite library is a core part of the Android environment. Java
applications and content providers access SQLite using the interface
in the android.database.sqlite namespace.
One disadvantage of using Android's built-in SQLite support is that
the application is forced to use the version of SQLite that the
current version of Android happened to ship with. If your application
happens to require a newer version of SQLite, or a build with a custom
extension or VFS installed, you're out of luck.
The code in this project allows an application to use the Android NDK
to build a custom version of SQLite to be shipped with the application
while still continuing to use the standard Java interface.
Normal Usage
Installation
Android API levels 15 (Android 4.0.3) and greater are supported. If
targetting API level 16 or greater, use the default "trunk" branch of
this project. Or, for API level 15, use the "api-level-15" branch. It
is not possible to target an API level lower than 15.
Copy the following files from this project into the equivalent
locations in the application project.
jni/Android.mk
jni/Application.mk
jni/sqlite/* (copy contents of directory recursively)
src/org/sqlite/database/* (copy contents of directory recursively)
Following this, the directory structures should contain
these files.
For API level 15 only, also copy the following:
src/org/sqlite/os/* (copy contents of directory recursively)
Directory "jni/sqlite/" contains copies of the sqlite3.h
and sqlite3.c source files. Between them, they contain the source code
for the SQLite library. If necessary, replace these with the source
for the specific version of SQLite required. If SQLite is to be
compiled with any special pre-processor macros defined, add them to
the "jni/sqlite/Android.mk" file (not jni/Android.mk).
Once the files have been added to the project, run the command
"ndk-build" in the root directory of the project. This compiles the
native code in the jni/ directory (including the custom SQLite
version) to shared libraries that will be deployed to the device along
with the application. Assuming it is successful, unless you modify the
sources or makefiles within the jni/ directory structure, you should
not need to run "ndk-build" again.
Application Programming
The classes that make up the built-in Android SQLite interface reside
in the "android.database.sqlite" namespace. This interface provides
all of the same classes, except within the
"org.sqlite.database.sqlite" namespace. This means that to modify an
application to use the custom version of SQLite, all that is usually
required is to replace all occurrences "android.database.sqlite"
within the source code with "org.sqlite.database.sqlite".
For example,the following:
import android.database.sqlite.SQLiteDatabase;
should be replaced with:
import org.sqlite.database.sqlite.SQLiteDatabase;
As well as replacing all uses of the classes in the android.database.sqlite.*
namespace, the application must also be sure to use the following two:
org.sqlite.database.SQLException
org.sqlite.database.DatabaseErrorHandler
instead of:
android.database.SQLException
android.database.DatabaseErrorHandler
Aside from namespace changes,
there are other differences from the stock Android interface that
applications need to be aware of:
The SQLiteStatement.simpleQueryForBlobFileDescriptor() API is not
available.
The collation sequence "UNICODE" is not available.
The collation sequence "LOCALIZED", which normally changes with the
system's current locale, is always equivalent to SQLite's built in
collation BINARY.
Disclaimer: i have only used this method for standalone executables, not libraries that implement JNI functions. It may work for a .so or not. Also, i'm working with a custom Android device not a phone.
You can use the built in SQLite via NDK but it's more of a hack than something supported. You need to nick sqlite3.h and libsqlite.so from an android source distribution and compile using them. Put sqlite3.h in your application source directory and you need to put the .so somewhere under the out/yourapp directory or build/platform/android-x/arch-arm/usr/lib for the linking step to finish. I have it in both places but i'm not sure which one is really needed.
You will end up linking to the libsqlite.so you provided but the binary will run fine using the system libsqlite.so on a target device.