the new version works like a charm.
encrpytion and authentication works as expected.
i cannot provide the logs anymore, because they are deleted automatically.
anyways , i'll keep an eye on the logs , cause my isp billed me 39〓 for
btw tcprelay:// over an encrypted master now works , it didn't in all the
previous versions , dont know why
lovely greetz fly out through the world :-)
firstname.lastname@example.org (Yutaka Sato)
Bitte antworten an
Re: delegate security flaw [Virus checked]
In message <_A3552@delegate-en.ML_> on 10/18/06(22:10:15) I wrote:
|you email@example.com wrote:
| |but in fact it is !. can i provide you with some logs to investigate
| |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
MASTER + STLS=fsv.
STLS=fcl <-----+ +---- MASTER=host:port STLS=fsv
FCL=sslway <---+ +---- MASTER=host:port FMD=sslway
9 9 Yutaka Sato <firstname.lastname@example.org> http://delegate.org/y.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