Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 26 16:38
    DavidIzadaR edited #389
  • Nov 26 16:37
    DavidIzadaR edited #389
  • Nov 26 15:50
    DavidIzadaR edited #389
  • Nov 26 15:49
    DavidIzadaR opened #389
  • Nov 24 13:12
    DavidIzadaR commented #377
  • Nov 24 13:11
    DavidIzadaR commented #377
  • Nov 23 13:20
    DavidIzadaR commented #377
  • Nov 23 13:05
    DavidIzadaR commented #377
  • Nov 22 17:28
    evgeny-k commented #388
  • Nov 19 20:34
    rlebeau commented #388
  • Nov 19 20:34
    rlebeau commented #388
  • Nov 19 20:33
    rlebeau commented #388
  • Nov 18 10:15
    evgeny-k commented #388
  • Nov 17 18:40

    rlebeau on TIdHTTP-Helper

    #254 Adding class helper for TI… (compare)

  • Nov 17 18:01
    rlebeau commented #388
  • Nov 15 19:23
    rlebeau assigned #377
  • Nov 15 19:18
    rlebeau commented #377
  • Nov 15 09:49
    evgeny-k commented #388
  • Nov 13 18:16
    michaelJustin commented #377
  • Nov 13 17:53
    michaelJustin commented #377
Alain Abrahan
@clust3rsekt0r
I read your comment I know what the exception means I read the indy doc otherwise I was not able to use it in first place
Kudzu
@czhower
I wrote " x = 4;" and compiler says error!? Why?
so you are the first person in probably a decade that taht twas NOT the issue that I've talked to.
Alain Abrahan
@clust3rsekt0r
no no problem that's not my problem ok thanks for let me know that you have apps running in windows 10 using that library
Kudzu
@czhower
@rlebeau - any ideas besides fw?
Alain Abrahan
@clust3rsekt0r
no no Idea at all I get back to the beginning if I have a solution believe me I'm going to post it all over internet also here
:)
Kudzu
@czhower
What AV and fw do you have/
Remy Lebeau
@rlebeau
@clust3rsekt0r What is the EXACT configuration you are using for SMTP? What values have you assigned to the properties? If telnet can get through, there is no reason why Indy can't get through, unless your anti-virus/firewall is blocking your app.
Kudzu
@czhower
IPSEC could interfere as well, but thats not usually an issue on the desktop OSes
Walter Prins
@ByteJuggler
@rlebeau Thanks for the responses, please if you haven't yet, have a look at the logs I've posted/linked in my message at 16:54 (which was captured with TIdLogFile), which is where I got the SNI mismatch message from. (Edit: https://gist.github.com/ByteJuggler/500b5a5e70730474184b7315b9c38f1f and https://gist.github.com/ByteJuggler/5c3b8889c341dbbc8550e654cf35824d ) That said, thanks for the suggestions, I'll got trace/track into TIdSSLIOHandlerSocketOpenSSL.OpenEncodedConnection() and check out if and how Seattle and Berlin acts differently. (And I'll go log/trace the headers, which unfortunately isn't currently being logged by TIdLogFile as interceptor in the TIdHTTTP object.) Thanks again for your attention, it is appreciated.
Walter Prins
@ByteJuggler
@czhower Apologies if this is a strange question: Are you the real kudzu and is things going better with you? Last I read you were in some Bulgarian prison?! If things are better then I'm very happy! :)
Kudzu
@czhower
Yes its me. No change except I got out of Bulgaria in late 2009 - and got home in 2010 and have been stuck here since 2010. US stil chasing me and I'm basically a prisoner on a small island.
edit: Tiny island.
Walter Prins
@ByteJuggler
@czhower Oh man. My sympathies... :( Wishing you all the very best.
Kudzu
@czhower
thanks
My brother just passed the bar last week and will be alicensed lawyer in a few months in the very state where this whacko judge was.
Still going to be several years minimum before Im free though.
Walter Prins
@ByteJuggler
Kind of ironic. I take it this is still fallout from your ex (or am I misremembering?)
(I mean, the whole US chasing you)
Anyway, sorry I don't want to clutter up the chat with perhaps off-topic stuff. Just happy to see you're around. :)
Remy Lebeau
@rlebeau
@ByteJuggler I don't know which version of Indy shipped with Berlin Update 1, but in Seattle and Berlin RTM, the OpenSSL IOHandler set the SNI host to be the server that it is physically connected to, which in your case is the proxy, not the HTTPS server. That was changed in a later revision. Since TIdHTTP would be negotiating SSL/TLS with the HTTPS server, not with the proxy, the SNI host is now set to be the target HTTPS server, as if the proxy didn't exist. You can verify that using Wireshark to see the details of the SSL/TLS handshake and TIdLog to see the HTTP headers. The two host values should match. Unless the proxy is altering the handshake, which it shouldn't be.
Kudzu
@czhower
Yes, all from my ex who was been caught lying on the stand numerous times and is wanted in a different state.. but she will never leave the protection of her state...
She also owes me about $50,000 in back child support.
Walter Prins
@ByteJuggler
@rlebeau Thanks. For the record, I must admit I'm somewhat green on this stuff, so apologies if I am asking what might be obvious questions. In respect of TIdLog -- I've already attached an instance of TIdLogFile to Interceptor of TIdHTTP, this logged what I posted before but excluded headers. Have I missed something/should I use some other component or add some code to log the headers as the default logging doesn't seem to capture this? Also I've looked at the SSL handshake with Wireshark, it seems fine as far as it goes, I also used Fiddler to inspect it in some more detail and it seemed OK.
Remy Lebeau
@rlebeau
@ByteJuggler attaching a TIdLog... component will log everything that Indy sends/receives over the socket. If by "headers" you mean the SSL/TLS handshake, then no, it will not log that, since Indy is not the one sending/receiving that data, OpenSSL is internally. That is why I said to use Wireshark to see the handshake data (including the SNI data), and TIdLog to see the HTTP data after SSL/TLS is active.
@ByteJuggler between those two logs, if you can verify that the SNI hostname being transmitted by OpenSSL in the SSL/TLS handshake matches the hostname being transmitting by Indy in the HTTP Host header, then the fault has to be on the other end, either in the proxy or the webserver itself.
Remy Lebeau
@rlebeau
@ByteJuggler but, if they don't match (though they should), then the fault would be on Indy. But I haven't heard of anyone having problems with SNI rejections since I added logic to take proxies into account. Since I don't know which version shipped with Berlin Update 1, you might try downloading the latest SVN revision of Indy and see if the problem still occurs.
Walter Prins
@ByteJuggler
@rlebeau OK... I'll dig some more, your comments are very helpful, thanks again. (But to add, I suppose the key problem I have is that this code, and service, and proxy has worked correctly and undisturbed for many years using previous versions of Delphi/Indy, and I'm going to have a hard time convincing either the network guys where I'm working, never mind the remote company who's service is being consumed, that there's a problem with their stuff given that I'm the one using a new dev environment and now I'm having a failure. It seems obvious from that perspective that the problem must somehow be with my tool and not with the proxy or the remote service. But we'll see, I'll inspect/compare the relevant headers tomorrow when I'm back at work and hopefully find out what is what...)
I'll look into the latest version of Indy, thanks for suggesting this...
This message was deleted
Remy Lebeau
@rlebeau
@ByteJuggler SNI support is a relatively new feature added earlier this year (see this), so it would not have affected earlier versions. I have a hard time believing it is mismatching, though. If you want to, you can send me the Wireshark capture and TIdLog log to look at.
@ByteJuggler yes, that is the SVN info. The nightly download would be the easiest option.
Walter Prins
@ByteJuggler
@rlebeau I might take you up on that offer, thanks for the interest. I guess it is conceivable that there's some bug in the service provider's setup that is being exposed by the change (SNI support) in Indy, somehow, perhaps. (One other thing I've not actually done yet [on the todo list] is to cut the proxy out of the loop to eliminate it [or not] as being [part of] the problem. Watch this space...)
Remy Lebeau
@rlebeau
@ByteJuggler using the latest SVN version, connecting directly to www.textmagic.com and not a proxy, I am not getting an SNI mismatch error unless I force the IOHandler (via debugger) to use a bad SNI host. Otherwise, if I just let TIdHTTP do its job normally, I do not get the SNI error (but since I don't have a user/pass on TM, I get a different error instead).
Ludwig Behm
@lbehm
@clust3rsekt0r wich ssl versions does the server support? and wich does your client support? Test the server with openssl s_client and try all the -tls* / -ssl switches
It may be the case that some doesn't accept ssl2/ssl3 anymore.
Walter Prins
@ByteJuggler
@rlebeau Did a test today cutting out the proxy server, which then passed. So it seems there's some issue with the proxy setup that doesn't matter with older Delphi code but is exposed with newer SNI code for reasons unknown. The following seems perhaps related: http://www.squid-cache.org/mail-archive/squid-users/201406/0335.html And further: http://wiki.squid-cache.org/Features/SslPeekAndSplice I'll follow this up with the network guys here... That said, is it possible to easily instruct Indy to disable the SNI support (or remove the header) to essentially revert to the older behaviour in the meantime?
Remy Lebeau
@rlebeau
@ByteJuggler unfortunately no. SNI usage is hard-coded, so you would have to alter and recompile Indy to disable use of SNI. Indy does not initiate an SSL/TLS handshake until after a proxy has established a connection to the HTTPS server
Walter Prins
@ByteJuggler
@rlebeau Hi. I got around to trying the latest Indy (nightly) with Delphi Berlin 10.1 Update 1 as you suggested. It seems this fixes the issue I've been having (!), as the same failing test now is passing...(!) This implies however that the version of Indy shipping with Berlin has some SNI handling flaw somehow that has been fixed subsequently in Indy. Does that sound plausible? (As far as I'm aware there's been no further attempts from the network people here to fix this issue, but I will double check.)
Walter Prins
@ByteJuggler
@rlebeau BTW, I notice Indy seems to put stuff (.dcu's) in places that's arguably not ideal by default (e.g alongside .pas files) which means that "Build"ing projects needlessly pulls in source files when not strictly required and means you can't have separate debug and release precompiled .dcu's as is customary in most other packages. Also the instructions seem slightly out of date and also I noted there were another package or two in Berlin which failed to load after disabling/uninstalling the pre-installed Indy (Embarcadero EMS edge components - no idea what this is). Would you be interested in patches for some or all of the above things? (I made some notes whilst doing this including adding packages for Berlin into the project tree, updating package versions to 240 as required, I could tidy up my notes and changes and submit these if there's interest. It's not rocket science, but it may save others a bit of tedium?)
EricKing1
@EricKing1
Hello, glad to see Indy is still moving forward. I used delphi extensively years ago and now picking it back up. Unfortunately, I don't have the latest version it's a bit pricey for personal use. So that said, I have delphi 7 and I downloaded the most recent version from the nightly downloads and had to build and install. Had a few issues occur. Does the current version of indy work with delphi 7 and do the demos work correctly. Example: Opened the FTP demo and tried to compile it gave me a FTP.OnWork has an incompatible parameter list prompt. Not sure if I should be attempting to update the Indy?
Walter Prins
@ByteJuggler
@rlebeau Just as further confirmation, I've now reverted my Berlin install to the original Indy installation and the test is now failing again which implies Berlin 10.1 update 1 as shipped contains some issue in its version of Indy, which is fixed in the Indy nightly as of this writing. I think for the time being I'll try to track down the relevant change and patch just the required unit in the default Berlin install...
Walter Prins
@ByteJuggler
@EricKing1 Can't really help, D7 very old now, except to note there's a "Fulld7.bat" file present in the latest code which implies support (still) for D7, and that the FTP client demo compiles without issue on my Delphi 10.1 (Berlin) install. I'd therefore guess that there must still be a mismatch between the installed components (parameter lists) and what the Demo app you're opening expects/specifies, assuming there's not some kind of problem in the sourcetree. Make sure you've truly complete hidden/removed/renamed all vestiges of any preinstalled Indy (.bpl's, .dcu's, .dcp's...), then make sure you install the new Indy from scratch. (BTW the Delphi 10.1 Starter edition is currently available free, though it may be too limited for what you're doing...)
EricKing1
@EricKing1
Thanks for the feedback, I will check the starter addition and try your suggestions.
Walter Prins
@ByteJuggler
@rlebeau For reference, this is the code in the Berlin that breaks, and the fix in the current Indy head that fixes it: http://i.imgur.com/M9AYESu.png
@rlebeau Thanks again for your suggestions & advice. Appreciate it.
Kudzu
@czhower
Looks like it was a bug fix then.
Walter Prins
@ByteJuggler
@czhower Yeah. The slightly perplexing thing is that this all used to work (though perhaps by accident) in Seattle, and was failing in the latest and greatest (Berlin 10.1, Update 1). It didn't help that there are multiple moving parts here and each could've been at fault, potentially [client code, Indy code, proxy server, proxy setup, remote HTTPS site setup]. All's green now so I'm happy. :) (Digression: Today also ported forward our set of internal patches to Delphi Berlin. The oldest of these is from 2007, complete with QC and patch. Frustratingly none of these got fixed between Seattle and Berlin. That said, and to be fair, lest I sound too negative, the quality in recent releases has been substantially better and a number of our internal patches has become redundant in recent prior versions. I've also not reported all the issues we've patched yet, which obviously makes it less likely that they might be fixed. -- Some are kind of hard to put together a SSCCE for.)
Remy Lebeau
@rlebeau
@ByteJuggler yes, I know Indy's installation procedures aren't the best they coud be. I haven't had a chance to even create packages for Berlin yet. And I am in the process of reorganzing Indy's entire tree structure to better streamline everything. Eventually, I want to get Indy into Embarcadero's GetIt package manager, but I don't feel the current structure is well suited for that yet. BTW, can you look in Indy's IdVers.inc file in the Berlin Update 1 shipped version and confirm the version number so I can tag it in SVN? Is that rev 6469?