Hi,

Sorry for the late reply,

I can't see any "half_duplex" in the logs.

We are using delegate to protect telnet clients with ssl,  we are 
using/starting delegate as following

dg9_0_4.exe -P8039 ADMIN="jback@ekm..fi" SERVER=telnet://192.168.10.30 
FCL="sslway" RELIABLE="*"  AUTHORIZER="localhost/21"

Below are the captured Encrypted Alert that delegate does not understand, 
when delegate receive this alert it should close the connection.

I belive the Encrypted Alert are same as FIN ACK packet only that it is 
encrypted.

No.     Time        Source                Destination           Protocol 
Info
     35 2.038906    192.168.111.23        212.213.51.60         SSLv3 
Encrypted Alert

Frame 35 (77 bytes on wire, 77 bytes captured)
    Arrival Time: Feb 17, 2006 10:24:19.675898000
    Time delta from previous packet: 0.079622000 seconds
    Time since reference or first frame: 2.038906000 seconds
    Frame Number: 35
    Packet Length: 77 bytes
    Capture Length: 77 bytes
    Protocols in frame: eth:ip:tcp:ssl
Ethernet II, Src: 192.168.111.23 (00:03:94:02:b0:d5), Dst: 192.168.111.1 
(00:90:7f:00:02:be)
    Destination: 192.168.111.1 (00:90:7f:00:02:be)
    Source: 192.168.111.23 (00:03:94:02:b0:d5)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.111.23 (192.168.111.23), Dst: 
212.213.51.60 (212.213.51.60)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 63
    Identification: 0x0012 (18)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x42d6 [correct]
        Good: True
        Bad : False
    Source: 192.168.111.23 (192.168.111.23)
    Destination: 212.213.51.60 (212.213.51.60)
Transmission Control Protocol, Src Port: 1025 (1025), Dst Port: https 
(443), Seq: 616, Ack: 1634, Len: 23
    Source port: 1025 (1025)
    Destination port: https (443)
    Sequence number: 616    (relative sequence number)
    Next sequence number: 639    (relative sequence number)
    Acknowledgement number: 1634    (relative ack number)
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 1500
    Checksum: 0x5345 [correct]
Secure Socket Layer
    SSLv3 Record Layer: Encrypted Alert
        Content Type: Alert (21)
        Version: SSL 3.0 (0x0300)
        Length: 18
        Alert Message: Encrypted Alert

0000  00 90 7f 00 02 be 00 03 94 02 b0 d0 00 00 00 0X   ..............E.
0010  00 3f 00 12 00 00 00 00 0X d6 c0 a8 6f 17 d4 d5   .?....@.B...o...
0020  33 3c 04 01 01 bb 00 11 82 68 c4 39 3b e1 50 18   3<.......h.9;.P.
0030  05 dc 53 45 00 00 15 03 00 00 12 60 4a 6d f2 86   ..SE.......`Jm..
0040  0f 41 71 64 ab c2 16 fb 44 88 29 2f 81            .Aqd....D.)/.


Best regards

Johan

"Yutaka Sato" <pficabdyi-mxhgu47cb33w.ml@delegate.org> wrote in message 
news:<_A3111@delegate-en.ML_>...
> Hi,
> 
> In message <_A3108@delegate-en.ML_> on 01/25/06(16:03:03)
> you peqgabdyi-kq6kwqtmbghg.ml@delegate.org wrote:
>  |We are running Delegate 9.0.5/6 on windows 2003 server.
>  |
>  |It looks like when the delegate application receive a "SSL shutdown 
alert" 
>  |it does not handle it correct and the sessions stays up in the server 
for 
>  |30 seconds(minimun tcp_wait time in windows), because of that delegate 
are 
>  |unable to set up a new session from the same client within the 30 
seconds.
>  |
>  |(Ehereal log fragment)
>  |                   Sender          Destination
>  |33    13.500888    10.1.1.x        212.213.51.x    TCP    1026 > https 
[ACK] Seq=613 Ack=1529 Win=1500 Len=0 
>  |34    13.520005    212.213.51.x    10.1.1.x        SSLv3  Application 
Data 
>  |35    13.523312    10.1.1.x        212.213.51.x    TCP    1026 > https 
[ACK] Seq=613 Ack=1586 Win=1500 Len=0 
>  |36    13.875400    10.1.1.x        212.213.51.x    SSLv3  Encrypted 
Alert 
>  |37    13.921090    212.213.51.x    10.1.1.x        TCP    https > 1026 
[FIN  ACK] Seq=1586 Ack=636 Win=65512 Len=0 
>  |38    13.923773    10.1.1.x        212.213.51.x    TCP    1026 > https 
[FIN  ACK] Seq=636 Ack=1587 Win=1500 Len=0 
>  |39    13.965846    212.213.51.x    10.1.1.x        TCP    https > 1026 
[ACK] Seq=1587 Ack=637 Win=65512 Len=0 
>  |
>  |If I have understod the SSL protocol right, the delegate server need 
to 
>  |send an ack for the encrypted alert or do nothing with it (that works 
>  |also), now it starts to shutdown the session by it self and the client 
and 
>  |delegate failes to shutdown the sessions and both ends.
>  |
>  |Is this a known "feature" and are there any solution for it? 
>  |I really need this problem solved asap because it is a major problem 
for 
>  |us.
> 
> If you are using DeleGate as a HTTP proxy for SSL-Tunneling, and
> if you see "not half_duplex ?" in your logfile of DeleGate, you will be
> able to escape the problem by specifying as this:
> 
>   REMITTABLE=+,ssltunnel
> 
> DeleGate as a proxy for SSL-Tunneling tries to block non HTTPS/SSL
> (non half-duplex) communication by default.  But the Alert type
> record can be sent in non half-duplex order.  So I made DeleGate to
> detect the packet and pass it through.  The detection is done simply
> seeing the first octet of a record is 0x15 or not.  It might not
> match in your case.  So I'd like to see the binary dump of your
> "Encrypted Alert" packet.
> 
> If you are using DeleGate as a HTTPS origin server or a HTTPS gateway,
> it is another problem.  I need a little more information about your
> configuration parameters of DeleGate and the client program.
> 
> Cheers,
> Yutaka
> --
>   D G   Yutaka Sato <pfqcabdyi-kq6kwqtmbghg.ml@delegate.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
> 
> 
> Subject: Re: [DeleGate] fix for "non-half-dup CONNECT" (Re: 
Delegate9.0.3pre14Win32Http??)
> From: ptarqbth4-kq6kwqtmbghg.ml@delegate.org (Yutaka Sato)
> On 06/22/05(15:43) I wrote in <_A12985@delegate.ML_>
> <URL:http://www.delegate.org/mail-lists/delegate/12985>:
>  |+ static int toBeBroken(int fdc,int fdv[]){
>  |+   unsigned char b[4];
>  |+   int rcc;
>  |+   int fi;
>  |+   int fd;
>  |+ 
>  |+   if( !IsAlive(fdv[0]) )
>  |+           return 0;
>  |+   if( !IsAlive(fdv[1]) )
>  |+           return 0;
>  |+   for( fi = 0; fi < 2; fi++ ){
>  |+           fd = fdv[fi];
>  |+           rcc = recv(fd,b,1,MSG_PEEK);
>  |+           syslog_ERROR(
>  |+           "## EXIT relaysx: not half_duplex ? [%d] 
%d[%X]\n",fd,rcc,b[0]);
>  |+ 
>  |+           if( b[0] == 0x15 ){ /* SSL_RT_ALERT */
>  |+                   syslog_ERROR(
>  |+                   "## relaysx: thru SSL ALERT [%d] 
%d[%X]\n",fd,rcc,b[0]);
>  |+                   return 0;
>  |+           }
>  |+           rcc = recv(fd,b,4,MSG_PEEK);
>  |+           syslog_ERROR(
>  |+           "## EXIT relaysx: not half_duplex ? [%d] 
%d[%X][%X][%X][%X]\n",
>  |+                   fd,rcc,b[0],b[1],b[2],b[3]);
>  |+   }
>  |+   return 1;
>  |+ 
}-------------------------------------------------------------------------------
Johan Bäck
Network Manager

Oy EKM Service Ab
Bangatan 10 - 10600 Ekenäs -Finland
Tel: 000-000 0001 Fax: 000-000 0001
GSM: 000-000 0001
e-mail: peqgabdyi-mxhgu47cb33w.ml@delegate.org

http://www.ekm.fi
http://www.surfnet.fi