|
Replies:
37
-
Last Post:
May 17, 2016 5:16 PM
Last Post By: Dave Nottage
|
|
|
Posts:
26
Registered:
12/28/99
|
|
Hi All.
According to new Google policies for Android v. 6 (new libraries for OpenSSL) I have to deploy recent libssl.so and libcrypto.so files with the Android version of my apps.
I have succesfully managed this inclusion but Google now says that "my" OpenSSL version has one or more vulnerabilities (and everyone has time to fix it until next July 11).
So, someone knows where to download a recent (1.02f/1.01r or higher) version of OpenSSL android binaries (libssl.so + libcrypto.so)?
Thanks
Marco
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Marco wrote:
According to new Google policies for Android v. 6 (new libraries for
OpenSSL) I have to deploy recent libssl.so and libcrypto.so files with
the Android version of my apps.
Unfortunately, that will not work
Google is not using a new version of OpenSSL, they are using a forked version
called BoringSSL, making all kinds of changes to its API, breaking backwards
compatibility. And to make matters worse, this forked library is using the
same filenames as OpenSSL, and the libraries are pre-loaded at device startup.
So even if you deployed actual OpenSSL libraries with your app, they would
never get loaded because the pre-loaded BoringSSL library would take priority.
I have succesfully managed this inclusion but Google now says that
"my" OpenSSL version has one or more vulnerabilities (and everyone has
time to fix it until next July 11).
If you have managed to actually load OpenSSL at runtime despite BoringSSL's
presence, do tell how you did it! Or, is Google merely validating your app
executable, and not actually running it?
So, someone knows where to download a recent (1.02f/1.01r or higher)
version of OpenSSL android binaries (libssl.so + libcrypto.so)?
Even if you could find it (which AFAIK, nobody has yet), I don't think it
will work on Android 6+ devices.
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
26
Registered:
12/28/99
|
|
Marco wrote:
According to new Google policies for Android v. 6 (new libraries for
OpenSSL) I have to deploy recent libssl.so and libcrypto.so files with
the Android version of my apps.
Unfortunately, that will not work 
Hi Remy, this is what I've already done.
I've some Delphi Apps in which I use a TIdSSLIOHandlerSocketOpenSSL to connect to an ISAPI server with https.
After many reports of my apps crashing if installed in Android 6 devices I've searched the net for some tips and the couple of needed .so compiled files, 1.02 version, added the two files to the play store deployment of my apps (assets\internal) and changed the Indy's path calling
IdOpenSSLSetLibPath(TPath.GetDocumentsPath)
in the OnCreate of my datamodule.
After those modifications of my code my Apps run perfectly on my brand new S7 with Android 6.0.1, and on all the other recent Android devices (tested using the Play Store deployment).
And now the Google warning pops up telling me that the OpsnSSL files deployed with my apps are not of the minimum required 1.02f version (or 1.01r).... and so my post in this forum.
Is my solution not correct?
Thanks for your help.
Marco
Edited by: Marco Cirinei on May 10, 2016 8:58 AM
Edited by: Marco Cirinei on May 10, 2016 8:59 AM
|
|
|
|
Posts:
77
Registered:
6/2/12
|
|
Hi Marco
Can you share two .so files of SSL ? or where did you find them ?
|
|
|
|
Posts:
26
Registered:
12/28/99
|
|
Hi Marco
Can you share two .so files of SSL ? or where did you find them ?
Hi Mauro,
I've tryied two couples of .so files. The first couple, I think, is the couple you point in your google+ group post.
Anyway you can download here the latest .so files, the ones that I deploy at this moment:
https://drive.google.com/file/d/0B7AxqW32K0oXWW9nUk9qaFpHT0k/view?usp=sharing
Please share the conclusion of your problem.
Marco
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Marco wrote:
I've tryied two couples of .so files. The first couple, I think, is
the couple you point in your google+ group post.
Which is where exactly?
Anyway you can download here the latest .so files, the ones
that I deploy at this moment:
Where did the files come from originally?
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
|
|
|
Posts:
26
Registered:
12/28/99
|
|
Remy. Chris,
yes , thanks, those seem to be exactly the binary files that I've tested on latest build of my apps.
The problem is that google tells me that those files are not, still, enough up to date.
Chris, please, if you'll finally succeed in your linux compilation share the results with this forum 
Thanks
Marco
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Marco wrote:
yes , thanks, those seem to be exactly the binary files that
I've tested on latest build of my apps.
The problem is that google tells me that those files are not, still,
enough up to date.
But, they do work with Indy on Android 6 despite the warning? It is not
a fatal error that prevents the app from functioning correctly at runtime?
What about the static .a files? Do they work with Delphi? Or only the dynamic
.so files?
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
26
Registered:
12/28/99
|
|
{quote:title=Remy Lebeau (TeamB) wrote:}
But, they do work with Indy on Android 6 despite the warning? It is not
a fatal error that prevents the app from functioning correctly at runtime?
Yes Remy,
my apps run fine, the warning tells me that this vulnerabilities will be tolerate only until 7/11.
Here all the details:
https://support.google.com/faqs/answer/6376725
What about the static .a files? Do they work with Delphi? Or only the dynamic
.so files?
I haven't idea on how to link those .a files.
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Marco wrote:
That article talks about static linking to OpenSSL. Indy *dynamically
links* to OpenSSL.
I haven't idea on how to link those .a files.
Like any other external object file, using the 'external' keyword on function
declarations, and optionally the {$L} compiler directive.
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
160
Registered:
8/22/11
|
|
Marco wrote:
According to new Google policies for Android v. 6 (new libraries for
OpenSSL) I have to deploy recent libssl.so and libcrypto.so files with
the Android version of my apps.
Unfortunately, that will not work
Google is not using a new version of OpenSSL, they are using a forked version
called BoringSSL, making all kinds of changes to its API, breaking backwards
compatibility. And to make matters worse, this forked library is using the
same filenames as OpenSSL, and the libraries are pre-loaded at device startup.
So even if you deployed actual OpenSSL libraries with your app, they would
never get loaded because the pre-loaded BoringSSL library would take priority.
I have succesfully managed this inclusion but Google now says that
"my" OpenSSL version has one or more vulnerabilities (and everyone has
time to fix it until next July 11).
If you have managed to actually load OpenSSL at runtime despite BoringSSL's
presence, do tell how you did it! Or, is Google merely validating your app
executable, and not actually running it?
So, someone knows where to download a recent (1.02f/1.01r or higher)
version of OpenSSL android binaries (libssl.so + libcrypto.so)?
Even if you could find it (which AFAIK, nobody has yet), I don't think it
will work on Android 6+ devices.
--
Remy Lebeau (TeamB)
Ive been running on android 6 loading the .so libraries just fine for months. The new problem is we need to compile new versions of the openssl libraries. Cygwin is not working correctly to compile for me so im switching to a linux install to create them (if possible) https://wiki.openssl.org/index.php/Android#Build_the_OpenSSL_Library_2
heres a repository you can grab some current prebuilt ones https://github.com/emileb/OpenSSL-for-Android-Prebuilt.git
Edited by: Chris Dunn on May 10, 2016 11:59 AM
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Chris wrote:
Ive been running on android 6 loading the .so libraries just fine
for months.
How does that work? My understanding is that the new BoringSSL library uses
the same filenames as OpenSSL, and BoringSSL is pre-loaded, so it takes priority
over any OpenSSL binaries deployed with an app. Or does deploying to the
app's internal folder supercede that?
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
160
Registered:
8/22/11
|
|
Chris wrote:
Ive been running on android 6 loading the .so libraries just fine
for months.
How does that work? My understanding is that the new BoringSSL library uses
the same filenames as OpenSSL, and BoringSSL is pre-loaded, so it takes priority
over any OpenSSL binaries deployed with an app. Or does deploying to the
app's internal folder supercede that?
--
Remy Lebeau (TeamB)
Some versions of the Android Java system loader will load the system's version of the OpenSSL library, even though you built and included a copy with your application. In this case, you might need to write a wrapper shared object and link to the static version of the OpenSSL library.
|
|
|
|
Posts:
77
Registered:
6/2/12
|
|
update:
i have change my code to:
IdOpenSSLSetLibPath(System.IOUtils.TPath.GetDocumentsPath);
in deployment option:
libssl.so and libcrypto.so to remote_path = assets\internal
Download SSL files ( OpenSSL 1.0.2g Android.zip )
http://www.delphipraxis.net/188736-kompilierte-openssl-bibliotheken-fuer-android.html
compiled.. and work fine on my Samsung S6 Edge 6.0.1
i have uploaded and published on Google play store, APK Correct , no Google warning. all ok.
i have downloaded from others smartphone ( android 6.0 ) my app from store and work fine.
Note:
Add System.StartUpCopy in DPR as first unit
|
|
|
|
Posts:
160
Registered:
8/22/11
|
|
update:
i have change my code to:
IdOpenSSLSetLibPath(System.IOUtils.TPath.GetDocumentsPath);
in deployment option:
libssl.so and libcrypto.so to remote_path = assets\internal
Download SSL files ( OpenSSL 1.0.2g Android.zip )
http://www.delphipraxis.net/188736-kompilierte-openssl-bibliotheken-fuer-android.html
compiled.. and work fine on my Samsung S6 Edge 6.0.1
i have uploaded and published on Google play store, APK Correct , no Google warning. all ok.
i have downloaded from others smartphone ( android 6.0 ) my app from store and work fine.
Thanks Mida
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Mida wrote:
You have to be a registered user of that forum in order to download those
files.
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
7
Registered:
6/25/12
|
|
We are having the same issue trying to access our Web Service using SSL. I have tried all sorts of things to get this to work - including all of the things suggested here - but it still doesn't work.
If I could try with these files then it might work, but as Remy says, you need to be a registered user to download the files. Is there another way to get these files?
Thanks,
Ian
|
|
|
|
Posts:
26
Registered:
12/28/99
|
|
We are having the same issue trying to access our Web Service using SSL. I have tried all sorts of things to get this to work - including all of the things suggested here - but it still doesn't work.
If I could try with these files then it might work, but as Remy says, you need to be a registered user to download the files. Is there another way to get these files?
Thanks,
Ian
Ian,
that forum registration is an almost istantaneous process, and is free: I did it yesterday in 2 minutes.
After this you can immediatly download the files.
Marco
Edited by: Marco Cirinei on May 12, 2016 9:10 AM
|
|
|
|
Posts:
7
Registered:
6/25/12
|
|
Thanks Marco. I'll give it go then...
|
|
|
|
Posts:
7
Registered:
6/25/12
|
|
I have the files now but sadly I am still getting the Could not load SSL library message.
Steps taken:
1. Downloaded files - libcrypto.so, libssl.so
2. Added files to project folder
3. Added files to Android Deployment - Remote Path assets\internal
4. Added IdOpenSSLSetLibPath(System.IOUtils.TPath.GetDocumentsPath) to code
I have spend a few days now trying to get this to work - out of ideas. I have tried the armeabi-v7a files and x86 files.
Am I missing anything?
Thanks,
Ian
Edited by: Ian Rees on May 12, 2016 9:25 AM
|
|
|
|
Posts:
7
Registered:
6/25/12
|
|
Additional information:
Using ShowMessage(WhichFailedToLoad); ( from IdSSLOpenSSLHeaders ) gives this message:
"Failed to load /data/user/0/<packagename>/files/libcrypto.so"
is that the default location of 'assets/internal'? If I deploy the files to assets/internal I was expecting that to appear in the path?
Confused...
Can anyone help?
Thanks,
Ian
|
|
|
|
Posts:
7
Registered:
6/25/12
|
|
More info...
ShowMessage(OpenSSLVersion) before and after setting the library path states:
BoringSSL
I need a way to override this to OpenSSL - is there a way to do this?
I'm in the UK (Wales) - not sure if that makes a difference, or if it explains why it isn't working for me and is for others?
Thanks,
Ian
|
|
|
|
Posts:
160
Registered:
8/22/11
|
|
Delphi 10.1
Project file
///////////////////////////////////////////////////////////
uses
System.StartUpCopy,
System.IoUtils,
FMX.Forms,
IdSSLOpenSSLHeaders,
{$IFDEF IOS}
IdSSLOpenSSLHeaders_Static,
{$ENDIF }
{$R *.res}
begin
Application.Initialize;
{$IFDEF ANDROID}
IdOpenSSLSetLibPath(TPath.GetDocumentsPath);
{$ENDIF}
Application.CreateForm(TMainForm, MainForm);
Application.Run;
end.
/////////////////////////////////////////////////////////////
Deploy libraries in documents folder
Project -> Deployment -> All Configurations -> android platform -> Add file -> select your libraries
set remote path for files to: .\assets\internal\
add a button to your form and use
Showmessage(OpenSSLVersion);
mine shows OPENSSL 1.0.2g 1 Mar 2016
for Android 6 and down
Edited by: Chris Dunn on May 12, 2016 7:42 AM
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Chris wrote:
System.StartUpCopy,
...
IdOpenSSLSetLibPath(TPath.GetDocumentsPath);
...
set remote path for files to: .\assets\internal\
Thanks for that!
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
77
Registered:
6/2/12
|
|
Have you add System.StartUpCopy in DPR , as first unit ?
uses
System.StartUpCopy,
|
|
|
|
Posts:
160
Registered:
8/22/11
|
|
Have you add System.StartUpCopy in DPR , as first unit ?
uses
System.StartUpCopy,
True forgot that.
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
Ian wrote:
I have the files now but sadly I am still getting the *Could not
load SSL library* message.
What does Indy's WhichFailedToLoad() function say now?
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
|
|
|
Posts:
160
Registered:
8/22/11
|
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
|
|
|
Posts:
160
Registered:
8/22/11
|
|
Does this differ from the 1.0.2h that I had posted yesterday?
yes. these were built with no switches.
works with android 4.0 and up.
build with r9d ndk
Edited by: Chris Dunn on May 17, 2016 12:25 PM
|
|
|
|
Posts:
1,850
Registered:
1/7/00
|
|
yes. these were built with no switches.
works with android 4.0 and up.
build with r9d ndk
Thanks for your efforts, Chris.
What's the build procedure? I seem to have lost track. I note from elsewhere however, that Linux is required - I can set up a Linux VM for myself easily enough, though.
--
Dave Nottage [TeamB]
Delphi Worlds blog: http://www.delphiworlds.com/blog
|
|
|
|
Posts:
16
Registered:
11/11/11
|
|
Can anyone confirm it works with these params.
FSSL := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
FSSL.SSLOptions.Method := sslvTLSv1_2;
FSSL.SSLOptions.Mode := sslmClient;
Showmessage(OpenSSLVersion);
-> OPENSSL 1.0.2g 1 Mar 2016
ShowMessage(WhichFailedToLoad);
-> empty/nothing
only error i get is : Error connection with SSL. EOF was observed that violates the protocol.
Edited by: David Drouin on May 12, 2016 2:16 PM
|
|
|
|
Posts:
9,447
Registered:
12/23/01
|
|
David wrote:
FSSL.SSLOptions.Method := sslvTLSv1_2;
That means OpenSSL will use the TLS 1.2 method exclusively and not perform
any version negotiation (using the SSLv23 method). As such, the server must
also be using a matching TLS 1.2 method (without version negotiation) or
else the handshake will fail due to a protocol mismatch (which would explain
the EOF error).
If you want to use version negotiation and just enable TLS 1.2 by itself,
do this instead:
//FSSL.SSLOptions.Method := sslvTLSv1_2;
FSSL.SSLOptions.SSLVersions := [sslvSSLv23, sslvTLSv1_2];
This will set the SSLOptions.Method to SSLv23 and remove it from the SSLOptions.SSLVersions,
leaving TLS 1.2 enabled by itself so earlier SSL/TLS versions will be disabled
during version negotiation.
{code}
--
Remy Lebeau (TeamB)
|
|
|
|
Posts:
7
Registered:
6/25/12
|
|
Thank you guys for all the help!
I can confirm now that we have it working.
We created a blank project and did as suggested in your comments and it worked - correct version of SSL.
However, in my main project it still didn't work, but I noticed that I had:
{$IFDEF IOS}
IDSSLOpenSSLHeaders_Static
{$ENDIF }
IDSSLOpenSSLHeaders
IdSSLOpenSSL
at the top of my uses. So I moved them to the bottom so that they were the last units in the uses section and it works!
Thanks to everyone for the help and suggestions,
Ian
|
|
|
|
Posts:
7
Registered:
6/25/12
|
|
Just to add - I suspect that our SOAP WSDL was somehow changing the SSL back to BoringSSL; placing the SSL units last seems like a good thing to do...
Thanks again,
Ian
|
|
|
|
Posts:
16
Registered:
11/11/11
|
|
David wrote:
FSSL.SSLOptions.Method := sslvTLSv1_2;
That means OpenSSL will use the TLS 1.2 method exclusively and not perform
any version negotiation (using the SSLv23 method). As such, the server must
also be using a matching TLS 1.2 method (without version negotiation) or
else the handshake will fail due to a protocol mismatch (which would explain
the EOF error).
If you want to use version negotiation and just enable TLS 1.2 by itself,
do this instead:
//FSSL.SSLOptions.Method := sslvTLSv1_2;
FSSL.SSLOptions.SSLVersions := [sslvSSLv23, sslvTLSv1_2];
This will set the SSLOptions.Method to SSLv23 and remove it from the SSLOptions.SSLVersions,
leaving TLS 1.2 enabled by itself so earlier SSL/TLS versions will be disabled
during version negotiation.
{code}
--
Remy Lebeau (TeamB)
I should have specify that I only get this error on Android 6.0
|
|
|
|
Legend
|
|
Helpful Answer
(5 pts)
|
|
Correct Answer
(10 pts)
|
|
Connect with Us