Article delegate-en/3556 of [1-5107] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: delegate security flaw [Virus checked]
20 Oct 2006 01:05:55 GMT (Yutaka Sato)
The DeleGate Project


In message <_A3552@delegate-en.ML_> on 10/18/06(22:10:15) I wrote:
 |In message <_A3551@delegate-en.ML_> on 10/18/06(22:02:11)
 |you wrote:
 | |but in fact it is !. can i provide you with some logs to investigate this, 
 | |or you can setup a simple scenario on your own an
 | |see it actually happen . no offense, but for the time beeing i have to 
 | |switch to stunnel until this is fixed !
 |Hmm... it is very starange. Are you using dynamically linked version of
 |SSL libraries (which has become the standard of DeleGate/9) instead of
 |the obsoleted sslway as the external command ?
 |Anyway, the log will be appreciated of course.

I still cannot figure out the case in which SERVER=delegate with STLS=fcl
does accept and connect to the target server even when SSL with the client
is failed, so your example and/or log showing the case is appreciated.

I did release DeleGate/9.2.5 this morning in which I think FCL=sslway has
come to never accept clients connecting with MASTER + FSV=sslway.  Instead,
it accepts clients to connect it with MASTER + FMD=sslway.  It acts in the
compatible way with STLS=fcl so that it accepts clients connecting with

    SERVER=delegate             SERVER=xxxx

    STLS=fcl <-----+      +---- MASTER=host:port STLS=fsv
    FCL=sslway <---+      +---- MASTER=host:port FMD=sslway

  9 9   Yutaka Sato <>
 ( ~ )  National Institute of Advanced Industrial Science and Technology
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]