These are chat archives for IndySockets/Indy

11th
Oct 2016
Walter Prins
@ByteJuggler
Oct 11 2016 08:52
@rlebeau It seems it's HTTPS related. I installed wireshark and changed the protocol to http to enable easy capture. Surprisingly the Berlin build then worked, and I confirmed that the underlying requests made by Berlin and Seattle were byte identical (over http, sans the obvious things like cookie values and datetimes and whatnot) by capturing the conversation and comparing/diffing. I've never stripped SSL with wireshark so now it's going to be trying to figure out why using https with Seattle works but using https with Berlin Indy does not. (Was there any SSL related changes between Seattle and Berlin?)
Walter Prins
@ByteJuggler
Oct 11 2016 09:39
Actually, scratch that byte identical comment (i.r.o HTTP), not quite accurate. There are 1 difference perhaps worth noting -- The Seattle request has "Accept-Encoding: identity" which the Berlin is lacking... not sure what that does/means or whether it's relevant, but it's a difference.
Walter Prins
@ByteJuggler
Oct 11 2016 10:17
@rlebeau Ok, I've dove into the source code to track down where the (lack of) Accept-Encoding: identity difference comes from. -- Change by yourself on 1/1/2015 ;) I then patched the code and put it back to test -- this (perhaps as expected) did not make any difference. The wireshark traces now are pretty much identical in respect of the underlying requests... :( Moving on...
Walter Prins
@ByteJuggler
Oct 11 2016 15:54
@rlebeau For reference, here's log output (TIdLogFile assigned as Interceptor) for Seattle and Berlin The error message is basically: "HTTP hostname and TLS SNI hostname mismatch" with description: "The request's Host header does not match the request's TLS SNI Host header." Any ideas why this might be different between Seattle and Berlin?
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 16:25
Hi
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 16:35
I'm having a big problem with indy delphi library and windows 10 latest release
I can not have a succesful tls or ssl connection
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 16:40
The exception that I always get is Connection Closed Gratefully
Kudzu
@czhower
Oct 11 2016 16:49
Read the FAQ.
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 17:01
can you provide me a link I read a lot of forums but I can not find anything relate it
all I know is the reason of the exception
Kudzu
@czhower
Oct 11 2016 17:21
If you even simplyi google it, the answer will literlaly smack you in the head.
Or if you simply look at the comment immediatelyi above where teh exception is raised in the code. The one with the dozens of !!!!
Remy Lebeau
@rlebeau
Oct 11 2016 17:38
@ByteJuggler If you use TIdLog instead of Wireshark, you can log HTTPS requests before they are encrypted and HTTPS responses after they are decrypted.
Kudzu
@czhower
Oct 11 2016 17:42
@clust3rsekt0r I'm not trying to be rude - but this is a case of you literally have not looked at all for this answer. If you did, it would land on you.
Remy Lebeau
@rlebeau
Oct 11 2016 17:43
@ByteJuggler as for the SNI mismatch, if you look in IdSSLOpenSSL.pas, the TIdSSLIOHandlerSocketOpenSSL.OpenEncodedConnection() method sets the SNI hostname based on the URI being requested (TIdHTTP assigns the IOHandler's URIToCheck property) so it should match the HTTP Host header.
@clust3rsekt0r Connection Closed Gracefully means the other party closed the connection on their end. There are many reasons for why that could be happening. Which Indy component(s) are you trying to use SSL/TLS with? One common reason for a server to close an SSL/TLS connection is that the client likely has not been configured properly to interact with the server's SSL/TLS port correctly.
Kudzu
@czhower
Oct 11 2016 17:59
read the comment in the source in indy right at the exception
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 17:59
Thanks for your reply, I just make want to make this simple I don't want to go inside the library because I know the problem is not on the library, windows 10 anniversary update after that my app can not send more emails and all the exceptions from Indy is time out and Close connection Gracefully
The exception means that the outside server is closing the connection
but that's not true same program running in windows 7 and everything runs fine
So please I keep an open mind here this is not a dev problem this is a OS vs Library problem and I wanna know if all of you first are using windows 10 latest updates and your apps whatever app you have are using Indy to send emails and if you are able to send emails with that configuration, or if you know because I research an research until I discover this channel but there is no issue presented until now maybe I'm the first, I know almost all the APPs running on Delphi are running in old OS like windows XP
Kudzu
@czhower
Oct 11 2016 18:04
No. I REPEAT. READ THE COMMENT.
You are literally going out of your way not to find the answer.
I'm not going to load up Delphi to cut and paste it for you.
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 18:05
Kudzu do you have windows 10 latest update in your dev machine ?
Kudzu
@czhower
Oct 11 2016 18:05
And just about any google search of that error + Indy would bury you in the answer.
It doesnt matter what I have. You should listen to what I've told you. I'm done trying to help you as you are going out of your way to ignore the answer.
or are you only getting this on SSL and you cant' establish a connection at all?
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 18:07
I can not stablish a connection at all my program works just fine until windows 10 anniversary update comes to play
Kudzu
@czhower
Oct 11 2016 18:07
ok thats a differnet issue then - I misundersrtood you
Id check your firewalls.
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 18:08
My firewalls are ok I'm able to telnel the SMTP connection succesful through windows
in fact the connection is success on netstat but ofr some reason suddenly close
Kudzu
@czhower
Oct 11 2016 18:08
Is this SSL only or plain connection?
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 18:08
and I got different exceptions if I use TLS I get Connection Close Gracefully
if I use SSL I get time Out
The plain connection is sucessful in some cases internal mail server but for gmail does not work either but I know some ISP block 25 ports
yahoo does not work either
Kudzu
@czhower
Oct 11 2016 18:10
I have 10 AU on all PCs here.. and many Indy apps.. no issues here.
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 18:10
Latests updates I mean anniversary update ?
Kudzu
@czhower
Oct 11 2016 18:10
yes. I have 10 AU on all PCs here.
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 18:11
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
Oct 11 2016 18:12
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
Oct 11 2016 18:12
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
Oct 11 2016 18:13
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
Oct 11 2016 18:14
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
Oct 11 2016 18:14
@rlebeau - any ideas besides fw?
Alain Abrahan
@clust3rsekt0r
Oct 11 2016 18:15
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
Oct 11 2016 18:16
What AV and fw do you have/
Remy Lebeau
@rlebeau
Oct 11 2016 18:44
@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
Oct 11 2016 19:02
IPSEC could interfere as well, but thats not usually an issue on the desktop OSes
Walter Prins
@ByteJuggler
Oct 11 2016 21:00
@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
Oct 11 2016 21:18
@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
Oct 11 2016 22:03
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
Oct 11 2016 22:10
@czhower Oh man. My sympathies... :( Wishing you all the very best.
Kudzu
@czhower
Oct 11 2016 22:10
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
Oct 11 2016 22:11
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
Oct 11 2016 22:12
@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
Oct 11 2016 22:16
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
Oct 11 2016 22:18
@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
Oct 11 2016 22:21
@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
Oct 11 2016 22:28
@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
Oct 11 2016 22:29
@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
Oct 11 2016 22:37
@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
Oct 11 2016 22:43
@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
Oct 11 2016 22:58
@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).