Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:36

    rlebeau on master

    Minor tweak to last pull reques… (compare)

  • 00:29

    rlebeau on master

    fix compiling issues for IdStac… Merge pull request #273 from Bi… (compare)

  • 00:29
    rlebeau closed #273
  • 00:27
    rlebeau commented #275
  • 00:26

    rlebeau on master

    Defining HAS_PRawByteString for… (compare)

  • 00:19

    rlebeau on master

    Define PRawByteString for older… Merge pull request #275 from Bi… (compare)

  • 00:19
    rlebeau closed #275
  • Dec 10 22:05
    Bi0T1N commented #274
  • Dec 10 21:36
    Bi0T1N commented #275
  • Dec 10 21:31
    Bi0T1N synchronize #275
  • Dec 10 19:25
    rlebeau commented #275
  • Dec 10 19:21
    rlebeau commented #275
  • Dec 10 14:50
    TommySlokky commented #274
  • Dec 10 14:39
    TommySlokky commented #274
  • Dec 10 14:37
    TommySlokky commented #274
  • Dec 10 12:00
    Bi0T1N commented #274
  • Dec 10 11:56
    Bi0T1N commented #274
  • Dec 10 11:44
    Bi0T1N opened #275
  • Dec 09 15:15
    TommySlokky edited #274
  • Dec 09 15:11
    TommySlokky opened #274
Remy Lebeau
@rlebeau
@icegood MOST binary-oriented protocols want multi-byte integers to be transmitted in network byte order, so AConvert defaults to True to ensure outgoing integers are sent in network byte order, and incoming integers are returned in host byte order. But, there are some protocols that don't specify/require network byte ordering. AConvert is provided as an option for those cases where integers are not transmitted in network byte order. Yes, that is rare, but such protocols do exist.
@mezen that is typically true. However, to be more accurate, you are not limited to just OpenSSL, any SSL IOHandler will do, OpenSSL is just the default provided by Indy. And while all Indy TCP clients will create and assign a default non-SSL IOHandler object for you if one is not already assigned, there is currently only one component, TIdHTTP, that will actually create a default SSL IOHandler object for you.
Sergey
@icegood
hi again. Is $ENDIAN_BIG defined in delphi or indy?
The problem on why i ask is how correctly pass WideString type?
Sergey
@icegood
Hmm, i found smth strange in OpenSSL (not for fix just knowledge sharing). If i wait more 20 sec right before call of SSL_connect(fSSL) in TIdSSLSocket.Connect i do obtain SSL_ERROR_SYSCALL.
@rlebeau , i read both http://stackoverflow.com/questions/35987485/eidosslconnecterror-error-connecting-with-ssl-eof-was-observed
and your comment in TIdSSLSocket.Connect regarding that but my case is not in negotiation. Actually if i omit that time delay then connection is OK!
Remy Lebeau
@rlebeau
@icegood ENDIAN_BIG and ENDIAN_LITTLE are defined by the FreePascal compiler. The Delphi compiler does not define endianess conditionals, so Indy manually defines ENDIAN_LITTLE for Delphi. Either way, you don't need to worry about endianess to work with WideString (or UnicodeString in D2009+). Indy deals with endianness internally when needed.
Remy Lebeau
@rlebeau
@icegood why are you making Indy wait 20s before letting it call SSL_connect()? Maybe you are encountering an error due to the default 30s timeout assigned by TIdSSLIOHandlerSocketOpenSSL.OpenEncodedConnection()
Sergey
@icegood
No, Remy. I'm just waiting in debugger
Jeroen Wiert Pluimers
@jpluimers
@rlebeau the thing here is that the other ends are embedded devices with firmwares that sometimes are not that well implemented. Solving this has been suspended until I've worked around https://plus.google.com/+JeroenPluimers/posts/Nze9sDEFb7S but I will get back on it later.
Sergey
@icegood
@rlebeau I don't actually see how Indy works with WideString. The only way i see that there is an overriden version of TIdIOHandler.Write for type=string. But i have rather old version of Delphi with 1-byte sring, so i wonder how in such a system Indy would know how correctly deal while writting WideString?
Remy Lebeau
@rlebeau
@icegood my point is, by making Indy wait before it calls SSL_connect(), you are delaying the SSL/TLS handshake, and the underlying socket, or even the other party, may time out and fail the connection, which will then be reported by OpenSSL when it finally tries to finish the handshake.
@icegood Indy uses (Wide|Unicode)String internally when converting strings <-> bytes. TIdIOHandler has a DefStringEncoding property, and Write(String) has an optional AByteEncoding parameter (defaulting to DefStringEncoding if not specified), to control (Wide|Unicode)String <-> bytes conversions. In pre-Unicode versions of Delphi and FreePascal where String=AnsiString, TIdIOHandler also has a DefAnsiEncoding property, and Write(String) has an optional ASrcEncoding parameter (defaulting to DefAnsiEncoding if not specified), to control the Ansi charset/codepage used for AnsiString <-> (Wide|Unicode)String conversions.
Remy Lebeau
@rlebeau
@jpluimers that does not change what I said earlier. Regardless of client implementation, an HTTP server has final say over how HTTP keep-alives are used. An HTTP server is not required to honor a keep-alive request from a client, period. So there is no reason that you cannot set TIdHTTPServer.KeepAlive=False even if the clients are using HTTP 1.1. If the server closes a connection after sending a response, and the clients are not smart enough to reconnect on their next request, that is their own fault, not the server's.
Jeroen Wiert Pluimers
@jpluimers
The problem is that if we send the response, then immediately disconnect, some clients do not process the response and resend their same request.
Remy Lebeau
@rlebeau
@jpluimers Then that is on them, not the server. But whatever. You have buggy clients. If you must use KeepAlive=True, then setting the connection's ReadTimeout is about all you can do for now to close the connection after a few extra seconds of waiting.
Ludwig Behm
@lbehm
Is there any way to access the SSL_CTX of a TIdServerIOHandlerSSLOpenSSL and then also use it with SSL_CTX_set_options() from C++ (Berlin)?
Trying to "improve" my HTTPS server after @mezen mentioned it...
Remy Lebeau
@rlebeau
TIdServerIOHandlerSSLOpenSSL and TIdSSLIOHandlerSocketOpenSSL both have an SSLContext property which contains the SSL_CTX, but it is protected, so you will have to define an accessor class to reach it, eg: class TIdSSLContextAccess : public TIdSSLContext { public: __property SSL_CTX* Handle = {read=fContext}; }; ... SSL_CTX_set_options(static_cast<TIdSSLContextAccess*>(IOHandler->SSLContext)->Handle, ...);
Ludwig Behm
@lbehm
and is there a way to access SSL_CTX_set_options? isn't in the hpp header files
Remy Lebeau
@rlebeau
SSL_CTX_set_options() is just a macro around SSL_CTX_ctrl(). You would have to access it from the OpenSSL SDK directly, not from Indy's headers
Ludwig Behm
@lbehm
okay... any hints how to do that?
Remy Lebeau
@rlebeau
Um, add the relavant #include statements to your C++ code for the OpenSSL header files, and link to the OpenSSL DLL. Just like accessing any other DLL function
Ludwig Behm
@lbehm
of course... nervermind^^
adbjn
@adbjn
New to this forum. I have a problem installing Indy 10 for Delphi 2010 (Delphi 2010 came with RAD Studio). I will try to describe the problem in as few words as possible. To install the version of Indy I am using I have removed everything related to Indy that came with Delphi. That is, everyting related to Indy in the C:\Program Files (x86)\Embarcadero\RAD Studio\7.0\bin, lib and source directories. I have then copied a downloaded version of Indy to the three folders C:\Program files (x86)\Embarcadero\RAD Studio\7.0\source\Indy\Indy10\Core, Protocols and System and added all three paths to the Library Paths setting. I then build the downloaded IndySystem140.bpl, IndyCore140.bpl, IndyProtocols140.bpl, dclIndyCore140.bpl and dclIndyProtocols140.bpl, in that order. This works fine. I get the problem even with just two projects using Indy. The first one builds fine. The second one builds too. However, when I go back to build the first one again I get the error "[DCC Fatal Error] IndyCore140.dpk(91): F2051 Unit IdContext was compiled with a different version of IdGlobal.IdDisposeAndNil". If I rebuild the 5 Indy BPLs it works once more to build my two projects, but after both of my projects have been built the same situation occurs again. That is, the first project cannot build and gives me that error message. I don't know where to start searching for the solution to the problem. Neither IdContext.dcu nor IdGlobal.dcu seem to get recompiled after the BPLs were first built so I don't get why it complains about the versions not matching. The Indy version was downloaded at 2015-12-28 and it HAS worked fine before, however on this new computer I am setting up I cannot get it to work without this frustrating problem. I am reluctant to use a different version of Indy if I don't really really have to. The version from 2015-12-28 has been very stable. It is used in a very critical system that just HAS to work. Any suggestions for how to resolve this would be extremely appreciated.
adbjn
@adbjn
Just checked again and IdGlobal does get recompiled but not IdContext. So, after the second project gets built they no longer have the same time stamp. Is this the problem? I thought Delphi was supposed to recompile everything that needed to be recompiled so this situation should never happen?
adbjn
@adbjn
I resolved the problem by rebuilding ONLY IndyCore140.bpl instead of all five Indy BPLs. After I do this I can then rebuild the two projects any number of times with no error messages. I have no idea why this fixed the problem though, but would love to know...
Sergey
@icegood

Hi, Remy!
How do i properly migrate from Indy9 next code:

AHashMessageDigest5 := TIdHashMessageDigest5.Create;
Result := AHashMessageDigest5.HashValue(AStream); (T4x4LongWordRecord)

i don't see any implementations of HashValue anymore as i saw it in Indy9...

Remy Lebeau
@rlebeau
@icegood the base TIdHash class has public HashStream() and HashSteamAsHex() methods, eg: Result := AHashMessageDigest5.HashStream(AStream); where Result is a TIdBytes, or Result := AHashMessageDigest5.HashStreamAsHex(AStream); where Result is a String.
Sergey
@icegood

Hello, Remy. Here is my results of migration from Indy9 to Indy10 of secured email via different hosts.

Preconditions:
1) Port is hardcoded to 465
2) services to check : mailtrap.io and smtp.gmail.com
3) In our application user can manually choose which type of SSL to use. By default it is OpenSSLv23 i.e. negotiation to choose version is allowed.
Results:
Indy 9 code worked under that settings for both mailtrap.io and smtp.gmail.com.
smtp.gmail.com negotiated with client to TlSv1

under Indy10 negotiation with mailtrap.io works fine
with smtp.gmail.com negotiation doesn't work (why it doesn't negotiated to TlS at all?) but after applying 'magic line'
AIdSMTP.UseTLS := utUseImplicitTLS;
smtp.gmail.com became to understand application in negotiation mode too and negotiation is resolved to TLSv1.2.

Now the question is : is it reliable to left this line provided end user would have own mail server settings?
And why negotiation didn't work without that line?

Remy Lebeau
@rlebeau
@icegood You must set UseTLS appropriately, as that governs how SSL/TLS is used during the SMTP session. UseTLS=utNoTLSSupport is the default, it means no SSL/TLS is used. UseTLS=utUseImplicitTLS performs an SSL/TLS handshake as soon as the socket is connected, before any SMTP traffic is exchanged. UseTLS=utUseExplicitTLS connects the socket initially unsecure and then issues an SMTP STARTTLS comand to perform a handshake only if the server advertises support for that. Indy 9 did not support STARTTLS at all. Indy 10 does. So you have to specify which mode to use. Not all servers support STARTTLS, but those that do offer it for legacy clients so they don't have to use SSL/TLS if they don't want to. GMail supports both modes. Port 465 is SMTP's implicit SSL port, port 587 is the explicit TLS port.
Justin
@klsyzzz
hi there, I'm trying to use Indy for SMTP and getting error 'SSL Negotiation failed', I think one before this is 'Could not Load SSL Library', can you please helep
Justin
@klsyzzz
nevermind, I figured out, I downloaded the dlls for openssl-1.0.2k-x64_86-win64, after replaced with openssl-1.0.2k-i386-win32 it works ok
our application is 32bit but my dev environment is 64 so I was assuming I should use the 64 bit, turns out it's not
Remy Lebeau
@rlebeau
@klsyzzz you have to batch the bitness of your compiled executable, not your development environment. A 32bit executable can only use 32bit DLLs. A 64bit executable can only use 64bit DLLs
Justin
@klsyzzz
@rlebeau Thank you very much
also can you tell me what's the difference between openssl-1.0.2k-i386-win32 and openssl-1.0.2j-i386-win32 ? they all listed in the server, are they just different build built on different time?
Kudzu
@czhower
they are based on the openssl releases, so check their release notes.
Justin
@klsyzzz
oh. didn't know that
does that means I need to update openssl as well ?
I didn't recall I installed openssl, just using Indy lib from Delphi install
Remy Lebeau
@rlebeau
@klsyzzz openssl-1.0.2k-i386-win32 = OpenSSL 1.0.2k for Windows 32bit, openssl-1.0.2j-i386-win32 = OpenSSL 1.0.2j for Windows 32bit, openssl-1.0.2k-x64_86-win64 = OpenSSL 1.0.2k for Windows 64bit. They are just different builds of different releases of OpenSSL
Justin
@klsyzzz
how do I find out which openssl on my pc, the Indy package come with Delphi 10.2 berlin install
Remy Lebeau
@rlebeau
OpenSSL is a standalone library. There can be multiple versions installed on a PC. Look at the DLL's version info properties in Windows Explorer. In your code, you can find out which version of OpenSSL is being used by your app by calling Indy's OpenSSLVersion() wrapper function in the IdSSLOpenSSL unit.
Justin
@klsyzzz
i see, thank you very much
sorry one more question, do we need to include OpenSSL dlls for deployment to client's pc which runs our delphi application?
as we don't need to deploy any Indy lib to client PC
Remy Lebeau
@rlebeau
@klsyzzz OpenSSL is a separate library, so yes, you need to deploy it (or, if encryption export laws get in your way, have the user download it from OpenSSL's website), unless it is already installed on the PC (if so, you can use Indy's IdOpenSSLSetLibPath() function to point to it), or if you are compiling for iOS devices (Indy compiles OpenSSL statically on that platform). Indy itself is compiled directly into your app (unless you enable runtime packages, in which case you would then have to deploy those)
Justin
@klsyzzz
thank you very much Remy
mezen
@mezen

But pls consider https://www.openssl.org/source/license.html, for example

    1. Redistributions in binary form must reproduce the above copyright
  • notice, this list of conditions and the following disclaimer in
  • the documentation and/or other materials provided with the
  • distribution.

    1. Redistributions of any form whatsoever must retain the following
  • acknowledgment:
  • "This product includes software developed by the OpenSSL Project
  • for use in the OpenSSL Toolkit (http://www.openssl.org/)"

    1. All advertising materials mentioning features or use of this software
  • must display the following acknowledgement:
  • "This product includes cryptographic software written by
  • Eric Young (eay@cryptsoft.com)"
  • The word 'cryptographic' can be left out if the rouines from the library
  • being used are not cryptographic related :-).
Hmpf, gitter broken my format :-\