Re: [twsocket] SSL OnSslVerifyPeer vs. OnSslHandshakeDone event
Arno
Once again thanks for the help.
I will only implement the OnHandshakeDone event then.
I have one final question though.
When using the TSslWSocket in both client and server application, will the Root
cert always be sent before the
Certificate e.g. two handshake done events with root cert first and cert second
?
Best regards
Kurt
-Oprindelig meddelelse-
Fra: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] På vegne
af Arno Garrels
Sendt: 8. september 2010 15:22
Til: ICS support mailing
Emne: Re: [twsocket] SSL OnSslVerifyPeer vs. OnSslHandshakeDone event
Kurt,
> I'm a bit puzzled about what the exact purpose of the HandshakeDone
> event is then.
>
>
>
> Is it to verify that the SSL connection is now complete with(out)
> errors ?
>
When it triggers without error the certificate chain verification
completed successfully. In case of option SslVerifyPeer is set it
is the your responsibility to do a PostConnectionCheck.
If the SslSession was reused or SslVerifyPeer isn't set this
check is not required of course.
>
> And why is the certificate sent along as a param in this event too ?
The peer certificate object is required for the PostConnectionCheck,
it also has a property VerifyResult which should be X509_V_OK in case
of ErrCode = 0.
PeerCert.PostConnectionCheck();
If PostConnectionCheck failed and you set var Disconnect to TRUE
and the connection will be closed delayed. Do not call Close.
Description of PostConnectionCheck:
{ Now to the PostConnectionCheck, a very important security check!
Our application will be vulnerable if we do not check the peer
certificate beyond verification of the chain. Nothing prevents an
attacker from getting his own certificate signed by one of our trusted
CAs and then hijacking all our sessions. We thward this kind of
masquerade by tying the certificate to some information unique to the
machine. In SSL this information is one or multiple full qualified
domain names (FQDN) also called DNS names stored in certificate's
commonName field(s) of the subjectName field. Since X.509v3 the
subjectAltName extension allows to hold the FQDN as well as other
identifying information such as the IP address.
We use function PostConnectionCheck to perform these checks for us. }
>
>
> Is it safe to handle just one of these events, and if not what to
> check for in each ?
Yes, it's safe to only handle OnSslHandshakeDone.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
Arno Garrels wrote:
> The DLL names are globally writable typed constants, set their values
> before the OpenSSL libraries are loaded.
Is there any advantage to use writable typed constants like
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
instead of
var GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
?
Both seems to work but I try to avoid the first one whenever possible because
it can break multi-threading when not used properly. For example I had a
commercial component that contained code like this to save some code lines:
procedure SomeProc();
{$J+} // enable writeable consts
const
Buffer : array[0..31] of byte = (0, 0, ..., 0);
{$J-} // disable writeable consts
begin
// read and write to Buffer like it's a variable
end;
which caused problems when the procedure is used by different threads
simultaneously because all instances read and write to the same block in
memory.
I know this is not a problem with ICS but I wonder why writable consts are
used/preferred at all.
Regards,
Tobias
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
Tobias Rapp wrote:
> Arno Garrels wrote:
>> The DLL names are globally writable typed constants, set their values
>> before the OpenSSL libraries are loaded.
>
> Is there any advantage to use writable typed constants like
>
> const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
>
> instead of
>
> var GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL';
There is no advantage IMO. According to the documentation they are
"in essence initialized variables"
and
"In early versions of Delphi and Object Pascal, typed constants were always
writeable, corresponding to the {$J+} state. Old source code that uses
writeable typed constants must be compiled in the {$J+} state, but for new
applications it is recommended that you use initialized variables and compile
your code in the {$J-} state."
>
> Both seems to work but I try to avoid the first one whenever possible
> because it can break multi-threading when not used properly. For
> example I had a commercial component that contained code like this to
> save some code lines:
>
> procedure SomeProc();
> {$J+} // enable writeable consts
> const
>Buffer : array[0..31] of byte = (0, 0, ..., 0);
> {$J-} // disable writeable consts
> begin
>// read and write to Buffer like it's a variable
> end;
>
> which caused problems when the procedure is used by different threads
> simultaneously because all instances read and write to the same block
> in memory.
Yes, but no problem in this case since you should write
the DLL names just once.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] 535 SSL handshake failed. Error #1
Svemu - Reparto Sviluppo wrote: > From: "Arno Garrels" >> It might be that the application loaded some incompatible >> OpenSSL libraries unless the full path and filenames are >> specified. >> >> try >>GSSLEAY_DLL_Name := ; >>GLIBEAY_DLL_Name := ; >>MySslContext.InitContext; // loads the libraries and initializes >> the SslContext >> except >>// Something went wrong, log and handle it. >> end;" > > > ok, tomorrow morning i try this. > i'm sure that in the folder of OverbyteIcsSslFtpTst.exe, the dll are > 0.9.8e and with ProcessMonitor.exe i see that they are loaded Not required if the image path is actually correct. > this morning i've see that if i use OverbyteIcsHttpsTst.exe from the > customer's pc, ssl work fine. > TSSLContext is different between ftp > and http? The xx_bug options are set in the HttpsTst demo. > >> As I understand, your customer uses your application rather >> than OverbyteIcsSslFtpTst.exe. If so, I would compare all >> SSL settings of your application with the demo settings. > > yes, my customer use my application but for this test, i use > OverbyteIcsSslFtpTst.exe on the customer's pc. Is it the _same_ OverbyteIcsSslFtpTst.exe? I'm asking because your client_hello size is 90 bytes however my test with the original OverbyteIcsSslFtpTst demo and OSSL 0.9.8e sent a 88 bytes client_hello, this looks like a different different option set in SslContext. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] SSL OnSslVerifyPeer vs. OnSslHandshakeDone event
Kurt Andersen wrote: > When using the TSslWSocket in both client and server application, > will the Root cert always be sent before the > Certificate e.g. two handshake done events with root cert first and > cert second ? There is only a single handshake done event regardless of how many certificates the server sends. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] 535 SSL handshake failed. Error #1
yes, my customer use my application but for this test, i use OverbyteIcsSslFtpTst.exe on the customer's pc. Is it the _same_ OverbyteIcsSslFtpTst.exe? No, i've compiled OverbyteIcsSslFtpTst and OverbyteIcsSslFtpTst and i make a test. now i've copy SslContext from HTTP and past into Ftp but i've already the error. at the end i past the log. I'm asking because your client_hello size is 90 bytes however my test with the original OverbyteIcsSslFtpTst demo and OSSL 0.9.8e sent a 88 bytes client_hello, this looks like a different different option set in SslContext. can you send me your compiled demo and dll? i hope that i can solve the problem because i need to work on ssl layer. best regards daniele barbato PS: i send you an email. 12.29.18.266 ! HighLevelAsync 0 12.29.18.276 TWSocket will connect to xx:21 12.29.18.306 00A7A350 TryToSend 232 12.29.18.306 00A7A350 TriggerDataSent 232 12.29.18.547 >|220-- Welcome to Pure-FTPd [privsep] [TLS] --| 12.29.18.547 >|220-You are user number 73 of 80 allowed.| 12.29.18.547 >|220-Local time is now 12:29. Server port: 21.| 12.29.18.547 >|220-IPv6 connections are also welcome on this server.| 12.29.18.547 >|220 You will be disconnected after 20 minutes of inactivity.| 12.29.18.557 ! HighLevelAsync 0 12.29.18.557 00A7A350 PutDataInSendBuffer 232 len 10 [1] 12.29.18.557 00A7A350 TryToSend 232 12.29.18.557 00A7A350 TryToSend 232 12.29.18.557 00A7A350 TriggerDataSent 232 12.29.18.667 >|234 AUTH TLS OK.| 12.29.18.667 00A7A350 StartSslHandshake 232 12.29.18.867 00A7A350 InitSSLConnection 232 12.29.18.867 00A7A350 BIO_ctrl(sslbio, BIO_C_SET_SSL, BIO_NOCLOSE, 0x11952B0) = 1 [2] 12.29.18.867 ICB> SSL_CB_HANDSHAKE_START 12.29.18.867 ICB> SSL_connect: before/connect initialization 12.29.18.867 ICB> SSL_connect: SSLv2/v3 write client hello A 12.29.18.867 ICB> SSL_connect: error in SSLv2/v3 read server hello A 12.29.18.867 00A7A350 BIO_read(sslbio, 0x1, 0) = -1 [3] 12.29.18.867 00A7A350 BIO_should_retry(sslbio) = 1 [4] 12.29.18.867 00A7A350 TriggerEvent sslFdRead 232 12.29.18.867 00A7A350 TriggerEvent sslFdWrite 232 12.29.18.877 SslAsyncSelect 232, 1 FD_READ 12.29.18.877 00A7A350 TCustomSslWSocket.Do_FD_READ 232 12.29.18.877 00A7A350 BIO_ctrl_get_read_request(nbio) = 7 [5] 12.29.18.877 00A7A350 Winsock recv( 232, 0x12DD1C, 7, 0) = -1 [6] 12.29.18.877 00A7A350 TriggerEvents 232 SslState: SSL_ST_INIT // MayFD_Read=0 MayDoRecv=-1 MayFD_Write=-1 MaySslTryToSend=-1 bSslAllSent=0 bAllSent=-1 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 90 [7] 12.29.18.877 00A7A350 BIO_ctrl_get_write_guarantee(nbio) = 4096 [8] 12.29.18.877 SslAsyncSelect 232, 2 FD_WRITE 12.29.18.877 00A7A350 TCustomSslWSocket.Do_FD_WRITE 232 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 90 [9] 12.29.18.877 00A7A350 BIO_read(nbio, 0x12BD3C, 90) = 90 [10] 12.29.18.877 00A7A350 my_RealSend (0xE8, 1228092, 90) = 90 [11] 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 0 [12] 12.29.18.877 00A7A350 TriggerEvents 232 SslState: SSL_ST_INIT // MayFD_Read=0 MayDoRecv=-1 MayFD_Write=-1 MaySslTryToSend=-1 bSslAllSent=0 bAllSent=-1 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 0 [13] 12.29.18.877 00A7A350 BIO_ctrl_get_write_guarantee(nbio) = 4096 [14] 12.29.18.877 00A7A350 TCustomSslWSocket.Do_FD_WRITE 232 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 0 [15] 12.29.18.877 00A7A350 BIO_read(nbio, 0x12BD3C, 0) = 0 [16] 12.29.18.877 00A7A350 TriggerEvents 232 SslState: SSL_ST_INIT // MayFD_Read=0 MayDoRecv=-1 MayFD_Write=-1 MaySslTryToSend=-1 bSslAllSent=0 bAllSent=-1 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 0 [17] 12.29.18.877 00A7A350 BIO_ctrl_get_write_guarantee(nbio) = 4096 [18] 12.29.18.877 00A7A350 TCustomSslWSocket.Do_FD_WRITE 232 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 0 [19] 12.29.18.877 00A7A350 BIO_read(nbio, 0x12BD3C, 0) = 0 [20] 12.29.18.877 00A7A350 TriggerEvents 232 SslState: SSL_ST_INIT // MayFD_Read=0 MayDoRecv=-1 MayFD_Write=-1 MaySslTryToSend=-1 bSslAllSent=0 bAllSent=-1 12.29.18.877 00A7A350 BIO_ctrl_pending(nbio) = 0 [21] 12.29.18.877 00A7A350 BIO_ctrl_get_write_guarantee(nbio) = 4096 [22] 12.29.18.987 00A7A350 TCustomSslWSocket.Do_FD_READ 232 12.29.18.987 00A7A350 BIO_ctrl_get_read_request(nbio) = 7 [23] 12.29.18.987 00A7A350 Winsock recv( 232, 0x12DD38, 7, 0) = 7 [24] 12.29.18.987 00A7A350 BIO_write(nbio, 0x12DD38, 7) = 7 [25] 12.29.18.987 00A7A350 BIO_ctrl(nbio, BIO_CTRL_FLUSH, 0, 0x0) = 1 [26] 12.29.18.987 ICB> SSL3 alert read fatal unknown 12.29.18.987 ICB> SSL_connect: error in SSLv2/v3 read server hello A 12.29.18.987 00A7A350 BIO_read(sslbio, 0x1, 0) = -1 [27] 12.29.18.987 00A7A350 BIO_should_retry(sslbio) = 0 [28] 12.29.18.987 00A7A350 232 [29] error:14077447:SSL routines:SSL23_GET_SERVER_HELLO:reason(1095) 12.29.18.987 00A7A350 TriggerEvent sslFdClose 232 12.29.18.987 00A7A350 NetworkError #10053 12.29.18.987 SslAsyncSelect 232, 32 FD_CLOSE 12.29.18.987 00A7A350 TCustomSslWSoc
[twsocket] THttpServer POST
I'm putting together a basic web server for a small application to communicate with. I have the GET event working as intended, but am having difficulty with the POST event. The event fires, but I can't seem to work out where to find the POST data... I tried: ((THttpConnection *)Client)->ReceiveStr( ) and ((THttpConnection *)Client)->Params but both appear to be empty. Where would I find the actual posted data? Thanks, Dave -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] 535 SSL handshake failed. Error #1
Svemu - Reparto Sviluppo wrote: > can you send me your compiled demo and dll? Just sent my working binary by private mail. Please let us know how it works. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer POST
David Lewis wrote: > I'm putting together a basic web server for a small application to > communicate with. > > I have the GET event working as intended, but am having difficulty > with > the POST event. > > The event fires, but I can't seem to work out where to find the POST > data... > > I tried: ((THttpConnection *)Client)->ReceiveStr( ) and > ((THttpConnection *)Client)->Params but both appear to be empty. > > Where would I find the actual posted data? Have a look at the Delphi OverbyteIcsWebServ1 demo, it's Delphi however you get the idea for sure. On event OnPostDocument do some checks and prepare or allocate your receive buffer. OnPostedData is the event to Receive() data chunks and check for correct data length etc.. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] 535 SSL handshake failed. Error #1
- Original Message - From: "Arno Garrels" Just sent my working binary by private mail. Please let us know how it works. Hi Arno, now work fine, the problem was SslContext. Now i investigate for understand wich parameter can give me the error. Thank you for cooperation, best regards daniele barbato -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Multiple NICs question
Thanks! On Wed, Sep 8, 2010 at 4:34 PM, Lester wrote: > You can only have one default route out of your machine. You CAN make two > default routes, but the one with the lowest metric will win. If you have > two interfaces with the same metric, the first interface will win. If you > want to specifically route the traffic through the second interface, you > will have to add a static route to that interface. Do a ROUTE PRINT and > you'll see which interface is currently the defualt route. Example: > > Network DestinationNetmask Gateway Interface Metric > 0.0.0.0 0.0.0.0 192.168.200.254 192.168.200.212266 > > You can make specific traffic go via another route by using ROUTE ADD. > ROUTE -p ADD to make it permanent. > > Lester > > > On 08/09/2010 13:32, Fastream Technologies wrote: > >> Hello, >> >> I have a customer who wishes to use our ICS-based product to cache/proxy >> between connection in two different NICs with different IPs. The listening >> part is trivial. He says Winsock cannot automatically route the traffic to >> the second NIC outbound port when a public IP is destinated. I have no >> clue >> why! >> >> Is there something I am missing on this? >> >> Regards, >> >> SZ >> -- >> To unsubscribe or change your settings for TWSocket mailing list >> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket >> Visit our website at http://www.overbyte.be >> >> > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] THttpServer - How to handle unimplemented request methods
Hi everyone!
Is there any simple way to handle other than the GET, POST and HEADER
request methods,... as OPTIONS,...?
The way it is now, the THttpConnection.ProcessRequest procedure always
respond with a Answer501, not giving any chance to handle other methods.
I think a TriggerOnUnknownMethod event would be very useful.
procedure THttpConnection.ProcessRequest;
var handled:boolean;
...
if FMethod = 'GET' then
ProcessGet
else if FMethod = 'POST' then
ProcessPost
else if FMethod = 'HEAD' then
ProcessHead
else begin
TriggerOnUnknownMethod(handled);
if not handled then
begin
if FKeepAlive = FALSE then {Bjornar}
PrepareGraceFullShutDown;
Answer501; { 07/03/2005 was Answer404 }
end;
end;
TriggerBeforeAnswer; { V7.19 }
end;
By the way, the TriggerBeforeAnswer is used in what scenarios? From the
code above, it seems the answer has been delivered already.
Another thing that would be useful, if added to the code base of the
THttpConnection, is the possibility to send additional headers from the
THttpConnection.SendDocument, to define cache control, etc..
procedure THttpConnection.SendDocument(SendType : THttpSendType; const
aHeader:string='');
...
if FLastModified <> 0 then
Header := Header + 'Last-Modified: ' +
RFC1123_Date(FLastModified) + ' GMT' + #13#10;
if ContEncoderHdr <> '' then
Header := Header + ContEncoderHdr; { V7.20 }
if aHeader > '' then
Header := Header + aHeader
Header := Header + GetKeepAliveHdrLines + #13#10;
...
Regards,
Rui
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] 535 SSL handshake failed. Error #1
Svemu - Reparto Sviluppo wrote: > now work fine, the problem was SslContext. Good news. > Now i investigate for understand wich parameter can give me the error. Confusing and often misunderstood is property SslVersionMethod. In most cases, if not all, it should be set to one of the sslV23_XX options. The sslV23_XX options include all version methods including TLS v1. In order to disable a version, use SslOptions sslOpt_NO_XXX instead. > > Thank you for cooperation, You are welcome. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HTTPcli: source path question
Hello SZ! >You must parse the HTML for this. We use a Delphi HTML parser which I >downloaded from sourceforge for this but sometimes it raises an exception. >Search for that and if you cannot find it I will do my best to search it for >you in our projects... Actually I'm trying to extend Angus' Magenta Copy so HTML parsing is already implemented. Zvone, right! I'll take more intent look at the headers. Thanks to all for answers! -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
