Indy / OpenSSL / Lazarus / SSL / OS X / alternative?

[MISV]

Has anyone experience using Indy with SSL on OS X? I would require connecting it to OpenSSL, but not sure if this is feasible on OS X or if perhaps a better solution exists.

On Windows I am now using WinIne with Indy as fallback since users there have to download OpenSSL themselves.

I have read OS X comes with old versions of OpenSSL - if so, I guess I could try hook those together with Indy? I would prefer a soluion where users do not have o download something to get SSL working (although such a solution is preferable to not having a solution)

[skalogryz]

synapse (https) worked for me with OpenSSL is OSX.

[MISV]

Problem #1:
Lazarus + Indy + OpenSSL + OS X problems + EIdOSSLCouldNotLoadSSLLibrary

Currently I am using
- OS X Yosemite 10.10.5
- newest Indy (10.6.2.0, download 2016 March 13 -  Indy10_5346.zip)
- Lazarus 1.4.4

Solution for #1
Install openssl like this (for 32bit compability) in command line: brew install openssl --universal

Stackoverflow here:
https://stackoverflow.com/questions/35978851/lazarus-indy-openssl-os-x-problems

[MISV]

Problem #2:
Lazarus + Indy + OpenSSL + OS X problems + EIdSSLConnecError

Message:
Error connecting with SSL - EOF was observed that violates the protocol

In file 'Protocols/IdSSLOpenSSLHeaders.pas at line 19418'

Stackoverflow here:
https://stackoverflow.com/questions/35987485/lazarus-delphi-indy-openssl-os-x-problems-eidosslconnecerror

[MISV]

New problem - the 0.9.8 openssl library version seems not to be compatible with CloudFlare SSL

From
http://stackoverflow.com/questions/43078991/lazarus-indy-mac-openssl-ssl-error-on-cloudflare-websites

Lazarus 1.6.4 / macOS Sierra 10.12.3 /h newest Indy HTTP library / 32bit carbon application using Apple supplied libcrypto.0.9.8.dylib and libssl.0.9.8.dlib in /usr/lib/ ...

You will get error when connecting to a CloudFlare SSL website:

'EIdOSSUnderlyingCryptoError' with message; Error connecting with SSL. error:14077410:SSL rouines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

[Phil]

New problem - the 0.9.8 openssl library version seems not to be compatible with CloudFlare SSL

The Apple-supplied OpenSSL libraries have been deprecated for years and should not be used.

https://developer.apple.com/library/content/documentation/Security/Conceptual/cryptoservices/SecureNetworkCommunicationAPIs/SecureNetworkCommunicationAPIs.html#//apple_ref/doc/uid/TP40011172-CH13-SW3

That means you should not use Indy, Synapse, or FPC's HTTP client unless you include a newer version of the OpenSSL libraries in your app bundle (may require changes to HTTP client code).

Here's my suggestion: Follow Apple's advice and use their URL Loading System instead when accessing https sites. See the ns_url_request.pas unit in nsunits-src.zip here. It uses Apple's Foundation framework classes.

https://macpgmr.github.io

Note that the error you cite is likely not due to the age of the OpenSLL libraries, so it's possible that using Apple's frameworks will not work either. Handshake failures usually mean a problem between the client and server agreeing on what protocol version to use.

[Remy Lebeau]

New problem - the 0.9.8 openssl library version seems not to be compatible with CloudFlare SSL

Which EXACT version of OpenSSL 0.9.8 are you using?  SNI support (and support for TLS extensions in general) was added in 0.9.8f, and even then it was disabled by default unless OpenSSL was compiled with the "enable-tlsext" option.  CloudFlare may be rejecting the handshake if SNI is not being used.

[MISV]

New problem - the 0.9.8 openssl library version seems not to be compatible with CloudFlare SSL

The Apple-supplied OpenSSL libraries have been deprecated for years and should not be used.

https://developer.apple.com/library/content/documentation/Security/Conceptual/cryptoservices/SecureNetworkCommunicationAPIs/SecureNetworkCommunicationAPIs.html#//apple_ref/doc/uid/TP40011172-CH13-SW3

That means you should not use Indy, Synapse, or FPC's HTTP client unless you include a newer version of the OpenSSL libraries in your app bundle (may require changes to HTTP client code).

Here's my suggestion: Follow Apple's advice and use their URL Loading System instead when accessing https sites. See the ns_url_request.pas unit in nsunits-src.zip here. It uses Apple's Foundation framework classes.

https://macpgmr.github.io

Note that the error you cite is likely not due to the age of the OpenSLL libraries, so it's possible that using Apple's frameworks will not work either. Handshake failures usually mean a problem between the client and server agreeing on what protocol version to use.

Thanks for the link - I may very well go that way since i may in future also need ios compatible code

[Phil]

I may very well go that way since i may in future also need ios compatible code

Correct. ns_url_request.pas will work on iOS. Indy, Synapse and FPC's HTTP clients will NOT work on iOS with https sites since iOS does not include OpenSSL.

Note that if you need to work with a SOAP server, for example, via the Web Service Toolkit, you can use ns_url_request.pas with WST too. WST includes ns_http_protocol.pas (analogous to its indy_http_protocol.pas, etc.). See the ndfd library used in the example apps here to see how easy it is to conditionally switch between HTTP clients with WST (see file NdfdForecast.pas):

https://macpgmr.github.io/MacXPlatform/PascalDynLibs_3.html

You can also use ns_url_request.pas to post form data to a server.

[Remy Lebeau]

Indy, Synapse and FPC's HTTP clients will NOT work on iOS with https sites since iOS does not include OpenSSL.

Indy statically links to OpenSSL on iOS.  Static-link .a files for OpenSSL are available at https://indy.fulgan.com/SSL/.

[Phil]

Indy statically links to OpenSSL on iOS.  Static-link .a files for OpenSSL are available at https://indy.fulgan.com/SSL/.

Yes, per Apple's recommendation in the link above, you can do that on both iOS and OS X. Apple does suggest using a known version. I can't tell what version these are - the archive files in OpenSSLStaticLibs.7z are dated April 21, 2014. Maybe they don't get much love.

Static linking will add considerably to the size of the app's executable, depending on how many of the 5 architectures from the archive are linked in. Currently, 4 of the 5 architectures would probably be needed, 2 for the Simulator app (32 and 64 bit) and 2 for the iOS native device app (32 and 64 bit). Plus some bloat from Indy code.

If the app only needs to send an HTTP request or work with a SOAP server via WST, then that might be overkill. In contrast, using a Foundation-framework based client won't link in any additional code since everything the client code uses is already on the iOS device or Mac.

[MISV]

Unfortunately I can not execute a call to CStringCreateWithCString without running into trouble... 

Made a new topic for it: https://forum.lazarus.freepascal.org/index.php/topic,37423.0.html