Fastream Technologies wrote:
> Dear Arno,
>
> I have written the below code after your suggestion and wish to get
> your feedback before uploading as a beta:
I can't say whether it's OK or not. Just make sure that all your
TSslxxxx objects in that thread are assigned a SslContext created
in the same thread context. No TSslxxxx object must be assigned a
SslContext created in a different thread context. With such a design
you are on the safe side. If that doesn't help to fix the AV there
must be still something else going wrong.
--
Arno Garrels
>
> void __fastcall ReverseProxyClientThread::Execute() // multiple worker
> client objects, both TSslHttpCli's and THttpConnections are in the
> context
> of this
> {
> //---- Place thread code here ----
> FreeOnTerminate = true;
>
> initSSLContexes();
>
> while(!Terminated)
> messagePump();
>
> destroySSLContexes();
> }
> //---------------------------------------------------------------------------
> void __fastcall ReverseProxyClientThread::initSSLContexes(void)
> {
> sslContextList = new TList();
>
> TSslContext *HTTPSSLContext;
> EncryptionSettings *encryptionSettings;
>
> lockCriticalSection(serverThread->SNIContainer->CS);
>
> for(int i = 0; i < serverThread->SNIContainer->SNIDomains->Count; ++i)
> {
> HTTPSSLContext = new TSslContext(NULL);
> sslContextList->Add(HTTPSSLContext);
>
> encryptionSettings =
> (EncryptionSettings*)serverThread->SNIContainer->SNIDomains->Objects[i];
> // contains different SNI domains' configuration data--protected by
> the SNIContainer->CS critical section
>
> HTTPSSLContext->SslVerifyPeer = false;
> HTTPSSLContext->SslVerifyDepth = 9;
> HTTPSSLContext->SslOptions << sslOpt_MICROSOFT_SESS_ID_BUG <<
> sslOpt_NETSCAPE_CHALLENGE_BUG <<
> sslOpt_NETSCAPE_REUSE_CIPHER_CHANGE_BUG <<
> sslOpt_SSLREF2_REUSE_CERT_TYPE_BUG <<
> sslOpt_MICROSOFT_BIG_SSLV3_BUFFER << sslOpt_SSLEAY_080_CLIENT_DH_BUG
> << sslOpt_TLS_D5_BUG << sslOpt_TLS_BLOCK_PADDING_BUG,
> sslOpt_TLS_ROLLBACK_BUG << sslOpt_NO_SSLv2 <<
> sslOpt_NETSCAPE_CA_DN_BUG <<
> sslOpt_NO_SESSION_RESUMPTION_ON_RENEGOTIATION <<
> sslOpt_NETSCAPE_DEMO_CIPHER_CHANGE_BUG;
> HTTPSSLContext->SslVerifyPeerModes << SslVerifyMode_PEER;
> HTTPSSLContext->SslSessionCacheModes << sslSESS_CACHE_SERVER;
> HTTPSSLContext->SslCipherList = "ALL:!ADH:!DES:RC4:@STRENGTH";
> HTTPSSLContext->SslVersionMethod = sslV23_SERVER;
> HTTPSSLContext->SslSessionTimeout = 300;
> HTTPSSLContext->SslSessionCacheSize = 20480;
>
> HTTPSSLContext->SslCertFile = encryptionSettings->certFile;
> HTTPSSLContext->SslPrivKeyFile = encryptionSettings->privateKey;
> HTTPSSLContext->SslCAFile = encryptionSettings->CAFile;
> HTTPSSLContext->SslCAPath = encryptionSettings->CAPath;
>
> HTTPSSLContext->SslOptions >> sslOpt_NO_SSLv2 >> sslOpt_NO_SSLv3 >>
> sslOpt_NO_TLSv1;
>
> if(!encryptionSettings->useSSLv2)
> HTTPSSLContext->SslOptions = TSslOptions() << sslOpt_NO_SSLv2;
> if(!encryptionSettings->useSSLv3)
> HTTPSSLContext->SslOptions = TSslOptions() << sslOpt_NO_SSLv3;
> if(!encryptionSettings->useTLSv1)
> HTTPSSLContext->SslOptions = TSslOptions() << sslOpt_NO_TLSv1;
>
> HTTPSSLContext->SslSessionCacheModes = TSslSessCacheModes() <<
> sslSESS_CACHE_SERVER << sslSESS_CACHE_NO_INTERNAL_LOOKUP <<
> sslSESS_CACHE_NO_INTERNAL_STORE;
> HTTPSSLContext->SslOptions << sslOpt_CIPHER_SERVER_PREFERENCE;
>
> try
> {
> HTTPSSLContext->InitContext();
> }
> catch(Exception &e)
> {
> }
> }
>
> releaseCriticalSection(serverThread->SNIContainer->CS);
> }
> //---------------------------------------------------------------------------
> void __fastcall ReverseProxyClientThread::destroySSLContexes(void)
> {
> for(int i = sslContextList->Count - 1; i >= 0; --i)
> delete (TSslContext*)sslContextList->Items[i];
>
> delete sslContextList;
> }
> //---------------------------------------------------------------------------
>
> This seems okay to me but maybe you have something to say!
>
> Best Regards,
>
> SZ
>
> On Sat, Dec 4, 2010 at 5:17 PM, Fastream Technologies
> <ga...@fastream.com>wrote:
>
>> Hello,
>>
>> On Sat, Dec 4, 2010 at 3:55 PM, Arno Garrels <arno.garr...@gmx.de>
>> wrote:
>>
>>> Fastream Technologies wrote:
>>>> Dear Arno,
>>>>
>>>> On Sat, Dec 4, 2010 at 2:11 PM, Arno Garrels <arno.garr...@gmx.de>
>>>> wrote:
>>>>
>>>>> Fastream Technologies wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have received the below report from a tester. What could be the
>>>>>> cause of it, any idea?
>>>>>
>>>>> From the stack trace it looks like the exception is raised
>>>>> in TComponent.RemoveFreeNotifications of the CtrlSocket.
>>>>>
>>>>> Is the SslContext or an IcsLogger instance shared across multiple
>>>>> threads? If so, they might have been destroyed by another thread
>>>>> yet?
>>>>>
>>>>> Do you make sure that all threads are finished before you exit the
>>>>> application?
>>>
>>>> We do not use IcsLoggers as NO_DEBUG_LOG is defined. We have
>>>> TSslContext objects defined in the listener thread which has many
>>>> worker threads with THttpConnection's and TSslHttpCli's inside.
>>>> This exception is not thrown when the program is exiting and when
>>>> the worker threads are destructed. We have separate thread,
>>>
>>> The VCL and its component notification system is not thread-safe,
>>> that's likely the cause of the AV. Change your code to use one
>>> instance of TSslContext per thread, that should resolve it (I
>>> remember I claimed that TSslContext was thread-safe some years
>>> back, but did not take component notification into account, sorry).
>>>
>>> --
>>> Arno Garrels
>>>
>>
>>
>> The site that is having problems is NOT using SSL at all. In their
>> case there is just a listener SSL port with no traffic (but has a
>> TSslContext) and some TSslHttpCli's which connect to HTTP web
>> server--does your advice still apply?
>>
>> 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
