IndySockets / Indy

Indy - Internet Direct
https://www.indyproject.org
448 stars 153 forks source link

Add support for LibreSSL TLS library #231

Open rlebeau opened 5 years ago

rlebeau commented 5 years ago

Apple deprecated OpenSSL on Mac OSX starting in High Sierra. Older OpenSSL dylibs are still provided for backwards compatibility, but newer OpenSSL dylibs appear to be symlinks to LibreSSL (forked from OpenSSL 1.0.1g), which causes issues for Indy when it tries to load/use OpenSSL on OSX.

See the "Mac Os switched to LibreSSL from OpenSSL - Indy no longer working for me" discussion on the FreePascal forum.

In 2014, LibreSSL provided a new libtls library to greatly simplify adding TLS to socket code.

Indy should provide new SSLIOHandler components for LibreSSL, preferrably using its libtls API.

Possibly also update the OpenSSL SSLIOHandler components to recognize the LibreSSL symlinks and adjust accordingly, or fail more gracefully.

TommySlokky commented 5 years ago

Are you sure OpenSSL are provided with new clean installations of Mac OS - my impression from reading on the internet is that OpenSSL is completely left out

If OpenSSL libs are still included - a nice interim solution would be to have Indy somehow recognize those and use them if possible (even if symlink point to LibreSSL)

rlebeau commented 5 years ago

Are you sure OpenSSL are provided with new clean installations of Mac OS

I have no clue. I'm not a Mac user. But on some Mac systems (like the system of the user who first reported this issue), the OpenSSL libs are present.

If OpenSSL libs are still included - a nice interim solution would be to have Indy somehow recognize those and use them if possible (even if symlink point to LibreSSL)

Indy already uses the symlinks if present, since they have the original OpenSSL filenames, and just map to the LibreSSL libraries. The issue is whether the LibreSSL libraries still expose enough of the forked OpenSSL functionality for Indy to work or not. Since LibreSSL is forked from OpenSSL 1.01g, that functionality might be too old to work with some modern websites. That is still being diagnosed...

TommySlokky commented 4 years ago

As mentioned here in the same thread https://forum.lazarus.freepascal.org/index.php/topic,42598.msg297719.html#msg297719 I actually found libssl.35.dylib (LibreSSL) to be working for my https needs. I do not recollect about other versions. I will have to recheck if it works adding .35 to thelist

TommySlokky commented 4 years ago

Yes, seems ".35" (LibreSSL) seems to work just fine. Can see I in 2018 found and posted the same thing, but I simply forgot about it. But that explains why my app stopped working after replacing Indy10 with new version (and somehow I list the old Indy... I have taken a backup of the wrong Indy before updating to the new version... What a dumb mistake, but at least I get to post here about .35 working well on MacOS)

TommySlokky commented 4 years ago

My findings:

References:
- https://forum.lazarus.freepascal.org/index.php/topic,42598.0.html
- https://forum.lazarus.freepascal.org/index.php/topic,42598.msg297566.html#msg297566
- https://forum.lazarus.freepascal.org/index.php/topic,42598.msg297719.html#msg297719

Note:
  Test environment: New SVN of Lazarus/FPC + New Indy10-2019-12-xx on MacOS Catalina 10.15.2

Note:
  I can also see that Hansaplast in 2018 found that on macOS 10.13.6 + macOS 10.14  libssl.dylib + libcrypto.dylib pointed to "0.35". I believe this fits my own experience as well.

Note:
  From forum posts + own experience it seems the only persistently available dylibs available across 10.13.6, 10.14, 10.15.1, 10.15.2 are:
  - libssl.dylib
  - libssl.0.9.7.dylib
  - libssl.0.9.8.dylib
  - libssl.35.dylib
    ...
  - libcrypto.dylib
  - libcrypto.0.9.7.dylib
  - libcrypto.0.9.8.dylib
  - libcrypto.35.dylib

  I mention this because these are the only common ones between versions Hansa tested and those I tested (e.g. 10.15.1 and 10.15.2 changed some ".4x" as well)

Crawling https websites as test case:
  a) About 1000 pages on website using newer SSL than TLS1
  b) ...

Inside *IdSSLOpenSSLHeaders wen can add the following to *SSLDLLVers*:
* .35 : Works well. Tested on multiple computers/websites Persistently available. : *OpenSSLVersion* returns LibreSSL 2.2.7 ...
* .44 : Seems to work as well. But not available on all systems. I found it on 10.15.1 + 10.15.2 : *OpenSSLVersion* returns LibreSSL 2.8.3 ...
* .43 : I vaguely remember this worked as well. Hansa found it on 10.13.6 + 10.14.0 :

I have tried coming up with the best order adding LibreSSL versions based on
  1) when TLS improvements been added
     * https://stackoverflow.com/questions/48178052/when-was-tls-1-2-support-added-to-openssl
  2) How flawless + sure I am of it runs perfectly on Indy on Mac

And I have come op with:
  SSLDLLVers : array [0..9] of string = (
    '.10', // ?
    '.1.0.2','.1.0.1', // newest OpenSSL support versions with TLS1.2
    '.35', // MacOS LibreSSL forks from OpenSSL version 1.0.1 almost always found
    '.44', // MacOS LibreSSL forks from OpenSSL version? sometimes? found ... Add '.43'? as well?
    '.1.0.0','.0.9.9','.0.9.8','.0.9.7','.0.9.6' // too old OpenSSL for most HTTPS websites
  );
rlebeau commented 4 years ago

I have checked in an update to add LibreSSL's .35, .43, .44 dylibs to the SSLDLLVers array.

rlebeau commented 4 years ago

There is currently effort in progress to develop a new SSLIOHandler for the libtls API.