Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 02 17:36
    rlebeau edited #392
  • Dec 01 19:05
    rlebeau opened #392
  • Dec 01 19:05
    rlebeau labeled #392
  • Dec 01 19:05
    rlebeau milestoned #392
  • Dec 01 19:05
    rlebeau labeled #392
  • Dec 01 01:43
    rlebeau edited #181
  • Nov 30 15:37
    webaddicto commented #390
  • Nov 30 15:27
    webaddicto commented #390
  • Nov 30 14:10
    dhewg commented #299
  • Nov 30 13:32
    mezen synchronize #299
  • Nov 29 19:27
    rlebeau edited #391
  • Nov 29 19:27
    rlebeau labeled #391
  • Nov 29 19:27
    rlebeau labeled #391
  • Nov 29 19:27
    rlebeau opened #391
  • Nov 29 18:59
    rlebeau closed #377
  • Nov 29 18:58
    rlebeau commented #377
  • Nov 29 18:50

    rlebeau on master

    Fix #301 broke IdFTP in Active … Merge pull request #389 from Da… (compare)

  • Nov 29 18:50
    rlebeau closed #389
  • Nov 29 18:48
    rlebeau commented #390
  • Nov 29 18:47
    rlebeau commented #390
Alain Abrahan
@clust3rsekt0r
yahoo does not work either
Kudzu
@czhower
I have 10 AU on all PCs here.. and many Indy apps.. no issues here.
Alain Abrahan
@clust3rsekt0r
Latests updates I mean anniversary update ?
Kudzu
@czhower
yes. I have 10 AU on all PCs here.
Alain Abrahan
@clust3rsekt0r
ok you see that's all I need to know you should, and just one thing you should have more patient, this is not a fighting chat this is a help chat
so is not my intention to fight with you, was you who do not understand my comment I totally understand yours
Kudzu
@czhower
Im sorry I misunderstood your message - but I cant tell you how many ppl ask "how to get rid of conn closed gracefully" - have you read the commetn to know what im talking about?
99.9999% of the time the users never read teh comment, never searched, never read teh FAQ and the answer for other users is right there.
its liek asking something like this about Delpjhi
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?)