Article delegate-en/334 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A306@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: SSLWAY difficulties
10 Mar 1999 03:35:35 GMT ysato@etl.go.jp (Yutaka Sato)


On 02/26/99(14:18) I wrote in <_A306@delegate-en.ML_>
 |Note that you can omiit "-ac" or "-co" option for sslway when you call
 |sslway in FCL or FSV.

I noticed that this is not true for the sslway.exe in the binary
distribution of DeleGate till 5.8.8.  I've not updated the binary
after I made the extension in 5.6.5.  Use sslway.exe in 5.9.0 or
later if you use compiled version of sslway.

On 02/26/99(17:00) you "LAIDMAN,Jeremy" <pf4aqbdyi-m6tzzuem6vvr.ml@ml.delegate.org> wrote
in <_A310@delegate-en.ML_>
 |Thankyou for your reply.
 |
 |>   % delegated -P443 \
 |>        SERVER=https MOUNT="/* https://server/*" \
 |>        FCL=sslway FSV=sslway

Also I should have said that I tested this on *WindowsNT* with "-v"
option and with sslway.exe and {client,server}-{cert,key}.pem at
the current directory, using Netscape Navigator 3.0.3Gold[ja] and
Netscape Communicator 4.5[en] on WindowsNT.
After DeleGate/5.9.0, in the same environment, I can do this like:

> set ADMIN=ysato@etl.go.jp
> dg5_9_0 -v -P443 SERVER=https://server FCL=sslway FSV=sslway

This time I noticed that the connection to the server was not made
at the first time when I did dialogue with the browser to check new
certification (This problem must be fixed).  From next time, after
I completed the certification, SSL relay seems work smoothly. I can
see SSLway accept SSL connection from the client and connect to the
server, putting access log and making use of cache locally.

 |I tried this but it didn't work.  I'm testing under Win98.\

Oh...
The external filters, especially bi-directional ones like FCL/FSV on
Windows95/98 are in so incomplete status and I cannot recommend
using it.  Many problems, beside this one, seems have been caused by
the strange behavior of duplicated handles of WinSock between
(spawned) processes on Win95/98.  The problem seems that a TCP
connection is never disconnected (reset) if a socket duplicated and
closed in some order... 
I've tried to avoid the problem but failed, and I'm not sure if I
can fix it before Win95/98 will be replaced by Windows 2000 ...

Cheers,
Yutaka
--
Yutaka Sato <ysato@etl.go.jp> http://www.etl.go.jp/~ysato/   @ @ 
Computer Science Division, Electrotechnical Laboratory      ( - )
1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan            _<   >_

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