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

Calendars

  • Community Calendar

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 3 results

  1. 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
  2. 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
  3. 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
×