CEF3 BoringSSL/OpenSSL Conflict

[ryanjnz]

Hi,

We have been developing a cross-platform application using CEF and recently upgraded to 3.2171.1979.
Within our application we make some internal SSL Requests and for Windows in particular we use OpenSSL v1.0.1L for this.

As a result of the upgrade, we have found that when `CefExecuteProcess(main_args, app.get(), NULL);` is execute pre/post any SSL Requests crash the entire application.

After some research, we have some questions:
1) Does v3.2171.1979 use Google Chrome's BoringSSL implementation rather than OpenSSL?
2) If BoringSSL is being used, what version of BoringSSL is it?
3) Is it possible it is conflicting with the OpenSSL v1.0.1L thus the crash?
4) We are thinking we need to use BoringSSL rather than OpenSSL to fix this. Is there any Windows 32bit Libraries available?

Cheers,
Ryan

[magreenblatt]

Does the crash originate from CefExecuteProcess? What is the symbolized stack trace?

[ryanjnz]

Does the crash originate from CefExecuteProcess? What is the symbolized stack trace?

An example, lets say I have a class MyApp which only extends CefApp and IMPLEMENT_REFCOUNTING(MyApp);

Code: Select all

CefMainArgs main_args(argc, argv);
CefRefPtr<MyApp> app(new MyApp);
CefSettings settings;

HTTPSocket httpSocket;
string response = httpSocket.Get("https://somewebsite.com");


Uses OpenSSL to make a successful HTTPS Request. As soon as we do the following...

Code: Select all

CefMainArgs main_args(argc, argv);
CefRefPtr<MyApp> app(new MyApp);
CefSettings settings;

HTTPSocket httpSocket;
string response = httpSocket.Get("https://somewebsite.com");

int exit_code = CefExecuteProcess(main_args, app.get(), NULL);


Then we have a crash, with no debugging information because it has gone into the CEF layer. The debugger does not even reach `CefExecuteProcess` line in the code.
If we do the same again but HTTP instead everything runs okay as we have not made a SSL connection using OpenSSL.

On Linux it is fine, we do not use OpenSSL instead we use native.. But on Windows we must use OpenSSL implementation which is where we see problem.

Please bare in mind we did not have issue with older version of CEF using OpenSSL etc, so it must be when BoringSSL is implemented in Chromium?

[magreenblatt]

Please bare in mind we did not have issue with older version of CEF using OpenSSL etc, so it must be when BoringSSL is implemented in Chromium?

Not necessarily. You can get VS2013 debug symbols (PDB files) from http://magpcss.net/cef_downloads/. Please run libcef.dll.pdb placed next to libcef.dll and post the symbolized stack trace for the crash.

[ryanjnz]

Please bare in mind we did not have issue with older version of CEF using OpenSSL etc, so it must be when BoringSSL is implemented in Chromium?

Not necessarily. You can get VS2013 debug symbols (PDB files) from http://magpcss.net/cef_downloads/. Please run libcef.dll.pdb placed next to libcef.dll and post the symbolized stack trace for the crash.

We are using VS2010 - Will the VS2013 debug symbols still function okay?

[magreenblatt]

Please bare in mind we did not have issue with older version of CEF using OpenSSL etc, so it must be when BoringSSL is implemented in Chromium?

Not necessarily. You can get VS2013 debug symbols (PDB files) from http://magpcss.net/cef_downloads/. Please run libcef.dll.pdb placed next to libcef.dll and post the symbolized stack trace for the crash.

We are using VS2010 - Will the VS2013 debug symbols still function okay?

Probably not

[magreenblatt]

Why do you need to perform the HTTPS request before CEF is initialized? If you wait until after CEF is initialized you can use CEF's network stack via CefURLRequest.

[ryanjnz]

Why do you need to perform the HTTPS request before CEF is initialized? If you wait until after CEF is initialized you can use CEF's network stack via CefURLRequest.

It was an example, we do SSL requests internally as part of our application that isn't CEF specific. Usually we do it well after CEF is initialised, but I wanted to show an example of where the crash occurs.

We have CEF's UI layer separate to our application layer so we do not use CEF specific calls in certain areas of code.

[magreenblatt]

It appears that Chromium has never used OpenSSL on Windows, and the switch from NSS to BoringSSL did not occur until M41 (2272 branch) [1], so the problem is likely not BoringSSL. In order to further debug the crash in CEF you will likely need to build your application with VS2013 so that you can use the debug symbols.

[1] https://code.google.com/p/chromium/issu ... ?id=338884

[ryanjnz]

It appears that Chromium has never used OpenSSL on Windows, and the switch from NSS to BoringSSL did not occur until M41 (2272 branch) [1], so the problem is likely not BoringSSL. In order to further debug the crash in CEF you will likely need to build your application with VS2013 so that you can use the debug symbols.

[1] https://code.google.com/p/chromium/issu ... ?id=338884

Okay, we will build it in VS2013 wit the debugging symbols. I should be in the office tomorrow to try this. Thank you for the prompt replies, will post here as soon as possible again.