Jump to content

Search the Community

Showing results for tags 'openssl'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Delphi Questions and Answers
    • Algorithms, Data Structures and Class Design
    • VCL
    • FMX
    • RTL and Delphi Object Pascal
    • Databases
    • Network, Cloud and Web
    • Windows API
    • Cross-platform
    • Delphi IDE and APIs
    • General Help
    • Delphi Third-Party
  • C++Builder Questions and Answers
    • General Help
  • General Discussions
    • Embarcadero Lounge
    • Tips / Blogs / Tutorials / Videos
    • Job Opportunities / Coder for Hire
    • I made this
  • Software Development
    • Project Planning and -Management
    • Software Testing and Quality Assurance
  • Community
    • Community Management

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Delphi-Version

Found 9 results

  1. shineworld

    TCP/IP Server with OpenSSL TLS 1.2

    After finishing and testing the configuration to have TLS 1.2 on TIdFTPServer I was asked to add OpenSSL and TLS 1.2 also on the API server (based on TIdTCPServer TCP/IP communication). Unfortunately when I set Active to True, and IdSSLOpenSSL.InitContext is called, in the CiperList settings step it always returns error = 1 and I don't understand what I am doing wrong: if StatusInfoOn then begin SSL_CTX_set_info_callback(fContext, InfoCallback); end; //if_SSL_CTX_set_tmp_rsa_callback(hSSLContext, @RSACallback); if fCipherList <> '' then begin {Do not Localize} error := SSL_CTX_set_cipher_list(fContext, {$IFDEF USE_MARSHALLED_PTRS} M.AsAnsi(fCipherList).ToPointer {$ELSE} PAnsiChar( {$IFDEF STRING_IS_ANSI} fCipherList {$ELSE} AnsiString(fCipherList) // explicit cast to Ansi {$ENDIF} ) {$ENDIF} ); end else begin // RLebeau: don't override OpenSSL's default. As OpenSSL evolves, the // SSL_DEFAULT_CIPHER_LIST constant defined in the C/C++ SDK may change, // while Indy's define of it might take some time to catch up. We don't // want users using an older default with newer DLLs... (* error := SSL_CTX_set_cipher_list(fContext, {$IFDEF USE_MARSHALLED_PTRS} M.AsAnsi(SSL_DEFAULT_CIPHER_LIST).ToPointer {$ELSE} SSL_DEFAULT_CIPHER_LIST {$ENDIF} ); *) error := 1; end; Server code: https://pastebin.com/z82zhGyQ I am using the latest Indy sources from the git repository. I thank you in advance for any suggestions Best Regards Silverio
  2. Arnaud Bouchez

    ANN: mORMot 2.2 stable release

    With this new year, it was time to make a mORMot 2 release. We went a bit behind the SQlite3 engine, and we added some nice features. 😎 Main added features: - OpenSSL 3.0/3.1 direct support in addition to 1.1 (with auto-switch at runtime) - Native X.509, RSA and HSM support - mget utility (wget + peer cache) Main changes: - Upgraded SQLite3 to 3.44.2 - Lots of bug fixes and enhancements (especially about cryptography and networking) - A lot of optimizations, so that we eventually reached in top 12 ranking of all frameworks tested by TFB https://github.com/synopse/mORMot2/releases/tag/2.2.stable 🙂
  3. You may have noticed that the OpenSSL 1.1.1 series will reach End of Life (EOL) next Monday... Most sensible options are to switch to 3.0 or 3.1 as soon as possible. But we also discovered that switching to OpenSSL 3.0 could led into big performance regressions... so which version do we need to use? 😮 I just published a blog article about this, and also how we tried to leverage any incompatibility issue within the mORMot OpenSSL layer: https://blog.synopse.info/?post/2023/09/08/End-Of-Live-OpenSSL-1.1-vs-Slow-OpenSSL-3.0
  4. Ian F

    OpenSSL fails to Load

    Moving My application to D 11.2 Android 13 and android 64 bit on a Pixel 4 XL. get a message that openSSL fails to load Have put libcrypto.so and libssl.so for OpenSSL 1.0.2g Android\Android\armeabi-v7a in deployment to .\assets\internal\ ( this worked on the Android32 bit app D 10.4) these were downloaded from the indy sockets/ Openssl binarys using IdSSLOpenSSLHeaders.WhichFailedToLoad() I get the result "Failed to load /data/user/0/com.embarcadero.<MyApp>/files/libcrypto.so." Tried dropping them in the above directory but ended with the same result not clear if I have the wrong versions of the *.so files ( I think the pixel processor is armabi-V8) or whether I am placing the files in the wrong folder at Deployment have found some notes in my search's that perhaps I Should " statically build OpenSSL directly into your app binary" if this is necessary can anyone point me to some notes on how to achive this thanks in advance Ian
  5. Milan Vydareny

    Indy, OpenSSL, DataSnap on Android

    The difficulties when trying to use OpenSSL filters on a DataSnap application with an Android client have numbers of entries in various forums that go back a number of years. To summarize the problem: 1. Create a DataSnap server that specifies a filter of RSA, in my case using Delphi 11 Update 2, running on a Windows server as a service. 2. Create a DataSnap client that is deployed to an Android device, in my case a Samsung SD-9 with an ARM64-v8a instruction set running Android 10 3. The client application crashes because it is unable to load a required OpenSSL module. I have tried a number of solutions that are discussed in various places but nothing works for me. My question is: Does anyone know of a RECENT posting that provides a workable solution to getting an RSA filter to work with DataSnap/Indy/Firemonkey on an Android device? My current understanding that the root cause of the problem is probably the failure of Indy to remain current with Google's erratic development habits, that has deprecated OpenSSL in favor of a branch called Boring. Has this been addressed effectively by anyone? If not, are there any plans to do so? Thanks in advance, Milan
  6. danielKishlakov

    Indy OpenSSL static linking

    Hi) I need to statically link an existing Delphi app that uses Indy for networking with OpenSSL 1.0.2u. From the Indy code itself and some online resources I can see that Indy is capable of somehow statically linking with OpenSSL. But given Delphi can't link .lib files I try to figure out how do I build OpenSSL in a single object file so I can link it to the project. By now I've managed to compile it into a single obj by #including all the relevant source files into a single file. I made it compile by ifdefing certain structs in the code, got rid of macro redefinition warnings, solved the case insensitive linking issues and finally linked it to the project. But now I keep getting very weird errors, like e.g. call to CRYPTO_free yields access violation error and such. So obviously what I'm doing is more of a hack and it's probably wrong. I know that there has to be a way of doing it properly, could someone please direct me to the way it's supposed to be done. System: Windows 10 x64, RAD Studio Tokyo 10.2, I compile OpenSSL with MSVC for x64
  7. Two new zips for Win32 and Win64 versions of OpenSSL 1.1.1i can now be downloadable from the Wiki at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp . The latest 1.1.1 DLLs are also included in the ICS distribution SVN and overnight zip. There are two security fixes, one rated high relating to decryption using SM2 (which standard ICS does not offer) and rated moderate relating to ASN.1 strings used in X509 certificates and the confusing conversion between fixed length strings and C null terminated strings that may cause a crash, this was mainly a problem display certificate content. YuOpenSSL has a new version with OpenSSL 1.1.1l. Angus
  8. Hi there, I had some time to check out the great OpenSsl library from Grijjy / @Allen@Grijjy, and I found that its working even without binding any libraries to it. The original FMX sample showed some issues, so I just created a brand new Rx10.4.1 project and moved the main unit to it. Beside the Grijjy Foundation, I've put no static linked files yet in the deployment, to check this library out step-by step. Of coarse for Win32 I need the enclosed DLL's in the EXE folder, that's no surprise. It puzzled me that for Android and iOS, as well as for Macos, I don't need to add any library at all to the library tree/deployment Even in Allens post, there is the note, I've misinterpreted that it should be added directly to the projects library tree, or by deployment manager or some other hacky means: Also Embarcadero has notes about OpenSsl, Which leads to the conclusion at least iOS would need some external download of static libraries. In the libraries const section, I can spot the different static/dynamic names, but where and do they bind to ? const {$IF Defined(WIN32)} LIB_CRYPTO = 'libcrypto-1_1.dll'; LIB_SSL = 'libssl-1_1.dll'; _PU = ''; {$ELSEIF Defined(WIN64)} LIB_CRYPTO = 'libcrypto-1_1-x64.dll'; LIB_SSL = 'libssl-1_1-x64.dll'; _PU = ''; {$ELSEIF Defined(ANDROID64)} LIB_CRYPTO = 'libcrypto-android64.a'; LIB_SSL = 'libssl-android64.a'; _PU = ''; {$ELSEIF Defined(ANDROID32)} LIB_CRYPTO = 'libcrypto-android32.a'; LIB_SSL = 'libssl-android32.a'; _PU = ''; {$ELSEIF Defined(IOS)} LIB_CRYPTO = 'libcrypto-ios.a'; LIB_SSL = 'libssl-ios.a'; _PU = ''; {$ELSEIF Defined(MACOS32)} LIB_CRYPTO = 'libssl-merged-osx32.dylib'; { We unify LibSsl and LibCrypto into a common shared library on macOS } LIB_SSL = 'libssl-merged-osx32.dylib'; _PU = '_'; {$ELSEIF Defined(MACOS64)} LIB_CRYPTO = 'libcrypto-osx64.a'; LIB_SSL = 'libssl-osx64.a'; _PU = ''; {$ELSEIF Defined(LINUX)} LIB_CRYPTO = 'libcrypto.so'; LIB_SSL = 'libssl.so'; _PU = ''; {$ELSE} {$MESSAGE Error 'Unsupported platform'} {$ENDIF} I've put my test code as a wrapper around the original code, basically just adding the new project files. It seems the magic happens, because the libraries were sitting all side-by-side to the calling unit. The OpenSSL_Api unit find these local files in the same folder, and is able to bind them correctly. I didn't know that this is possible, I thought they have to be in the same project folder, and at least cross-platform make another hazzle to bind depending on the OS. Good to know that its enough to provide library+unit together, that gives much more room to cleanup libraries. I've put my wrapper code enclosed for testing, while the originally library files from Grijjy should be placed in the Src folder. The missing files you can get from here. I hope Allen don't mind. T381_GrijjySsl.zip
  9. note: We have seen these issues with multiple versions of the OpenSSL binaries, including the ones bundled with ICS 8.64. Please consider the following code snippet: var s := TSslContext.Create(nil); try s.SslCALines.Text := sslRootCACertsBundle(); try s.InitContext(); except on e: exception do ShowMessage(e.Message); end; finally s.Free(); end; This snippet works on most machines, but we have a few machines at client sites, where this code raises an exception: 'Error reading info file "Lines"'. (We haven't figured out yet why these specific machines have this issue). This exception is raised on OverbyteIcsWSocket.pas:14667 (ICS 8.64). InfoStack := PStack(f_PEM_X509_INFO_read_bio(InBIO, nil, nil, nil)); if not Assigned(InfoStack) then raise ESslContextException.CreateFmt('Error reading info file "%s"', [FileName]); Apparently the call to f_PEM_X509_INFO_read_bio() failed, but no information is give why, so we've added some calls to f_ERR_get_error() to see what is going wrong, and then it turns out the call to f_PEM_X509_INFO_read_bio() sets the error code 151580774 (get_header_and_data). To find out which of the hard coded certificates returned by sslRootCACertsBundle() were making this error happening, we've passed each of the certificates (sslRootCACerts001, sslRootCACerts002, etc) one by one to an TSSLContext to see which ones failed. This showed 2 interesting things: There is a 'typo' in sslRootCACerts009 and sslRootCACerts011: 'AGAT/3B+XxFNSRuzFVJ7yVTav52Vr2ua2J7p8eRDjeIRRDq/r72DQnNSi6q7pynP' + #13#10 + '9WQcCk3RvKqsnyrQ/39/2n3qse0wJcGE2jTSW3iDVuycNsMm4hH2Z0kdkquM++v/' + #13#10 + 'eu6FSqdQgPCnXEqULl8FmTxSQeDNtGPPAUO6nIPcj2A781q0tHuu2guQOHXvgR1m' + #13#10 + '0vdXcDazv/wor3ElhVsT/h5/WrQ8' + #13#10; sslRootCACerts010 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + and 'S0Zj/gA0QHDBw7mh3aZw4gSzQbzpgJHqZJx64SIDqZxubw5lT2yHh17zbqD5daWb' + #13#10 + 'QOhTsiedSrnAdyGN/4fy3ryM7xfft0kL0fJuMAsaDk527RH89elWsn2/x20Kk4yl' + #13#10 + '0MC2Hb46TpSi125sC8KKfPog88Tk5c0NqMuRkrF8hey1FGlmDoLnzc7ILaZRfyHB' + #13#10 + 'NVOFBkpdn627G190' + #13#10; sslRootCACerts012 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + (the END CERTIFICATE line is part of the wrong constant), which isn't a problem when you call sslRootCACertsBundle() since all constants are concatenated, but which shows up if you try to use these certificates separately. More interestingly, one these specific machines there seems to be an issue with sslRootCACerts033 and sslRootCACerts034. This is sslRootCACerts033: # X509 SSL Certificate # Subject Common Name: GlobalSign # Subject Organisation: GlobalSign # Subject Organisation Unit: GlobalSign Root CA - R2 # GlobalSign Root R2 SHA1 • RSA • 2048 # Issuer: Self Signed # Expires: 15/12/2021 -----BEGIN CERTIFICATE----- MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1 MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8 eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG 3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO 291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7 TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg== -----END CERTIFICATE----- When processing this certificate on these specific machines OpenSSL gives this error, unless: - I remove one of the • in the 5th line from the top. (As long as there is only 1 • in the file it's ok, as soon as I add a 2nd • anywhere in the header the error returns) - I add a CRLF at the bottom of the file The same thing applies to sslRootCACerts034. I realize that this is probably a bug in OpenSSL itself, but it might be wise to remove the •'s from the hard coded certificates to work around this issue. Curious if anyone can shed some light on the cause of this 🙂 Merijn
×