Article delegate-en/4073 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:<_A4072@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: SSL Buffer_Underflow
18 Aug 2008 17:52:33 GMT feedback@delegate.org (Yutaka Sato)
The DeleGate Project


Hi,

In message <_A4072@delegate-en.ML_> on 08/19/08(01:43:25)
you =?ISO-8859-1?Q?Andr=E9_Egners?= <p4yhqbdyi-7pkjwoc346fr.ml@ml.delegate.org> wrote:
 |In our research group we are working on anonymity network and use an 
 |onion routing scheme which could be compared to TOR, therefore we chain 
 |SSL proxies. The error occurs while doing throughput measurements using 
 |a simple perl stream server (no ssl)[1] which shoves bytes to the client 
 |which connects through 3 chained proxies connected by CONNECT of HTTP.
 |Thus data needs to be decrypted when receiving on the client 
 |side...calling unwrap.
 |
 |Unfortunately this might be tough to reproduce, but there seems to be 
 |something wrong with closing the SSL connection since only the last 
 |packet seems to be too small.

I have no experience with Java but I saw the document saying:
<URL:http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#OperationStatus>
 > The possible overall statuses are represented by the SSLEngineResult.Status
 > enum. Some examples of this status include OK, which means that there was
 > no error, and BUFFER_UNDERFLOW, which means that the input buffer had
 > insufficient data, indicating that the application needs to obtain more
 > data from the peer (for example, by reading more data from the network),

It could be the result of shutdown procedure of SSL by DeleGate omitting
the final SSL message for the explicit shutdown of the connection.

<URL:http://java.sun.com/javase/6/docs/api/javax/net/ssl/SSLEngine.html>
 > A peer will signal its intent to close by sending its own closure handshake
 > message. After this message has been received and processed by the local
 > SSLEngine's unwrap()  call, the application can detect the close by calling
 > unwrap() and looking for a SSLEngineResult  with status "CLOSED", or if
 > isInboundDone() returns true.
*> If for some reason the peer closes the communication link without sending
*> the proper SSL/TLS closure message, the application can detect the
*> end-of-stream and can signal the engine via closeInbound() that there will
*> no more inbound messages to process.
 > Some applications might choose to require orderly shutdown messages from
 > a peer, in which case they can check that the closure was generated by a
 > handshake message and not by an end-of-stream condition.

It seems that the document above says you should use closeInbound() to
detect end-of-stream on the BUFFER_UNDERFLOW status.

The behavior of DeleGate can be changed but I think it seems not so odd
because I can see similar behavior on other HTTPS servers.
I'm not sure if it is equivalent to your "unwrap" but I can emulate a
SSL client with DeleGate as follows.

  % delegated -fv -vd TLSCONF=-vd -Fdget -h FSV=sslway https://server-name

I can easily find many HTTPS servers including Apache and IBM which act
like DeleGate as follows.

  % delegated -fv -vd TLSCONF=-vd -Fdget -h FSV=sslway https://www.sun.com
  ...
  Server: Sun-Java-System-Web-Server/7.0
  ...
  08/19 02:27:52.61 [11252] 0+1: ## SSLway S-C: 2902/2902 -> 2902
  08/19 02:27:52.61 [11252] 0+1: ## SSLway S-C EOF from the server
  08/19 02:27:52.61 [11252] 0+1: ## SSLway FSV S-C:31129/6 C-S:77/1
  08/19 02:27:52.61 [11252] 0+1: ## SSLway S>> shutdown from server: 2
  08/19 02:27:52.61 [11252] 0+1: ## SSLway S<< return shutdown to server
  08/19 02:27:52.61 [11252] 0+1: ## SSLway done
 
  % delegated -fv -vd TLSCONF=-vd -Fdget -h FSV=sslway https://www.att.com
  ...
  Server: IBM_HTTP_Server 
  ...
  08/19 02:29:28.67 [11267] 0+1: ## SSLway S-C: 254/254 -> 254
  08/19 02:29:28.67 [11267] 0+1: ## SSLway S-C EOF from the server
  08/19 02:29:28.67 [11267] 0+1: ## SSLway FSV S-C:493/2 C-S:77/1
  08/19 02:29:28.67 [11267] 0+1: ## SSLway S>> shutdown from server: 0
  08/19 02:29:28.67 [11267] 0+1: ## SSLway done

  % delegated -fv -vd TLSCONF=-vd -Fdget -h FSV=sslway https://www.nec.com
  ...
  Server: Apache
  ...
  08/19 02:43:29.53 [11351] 0+1: ## SSLway S-C: 1185/1185 -> 1185
  08/19 02:43:29.53 [11351] 0+1: ## SSLway S-C EOF from the server
  08/19 02:43:29.53 [11351] 0+1: ## SSLway FSV S-C:1185/1 C-S:77/1
  08/19 02:43:29.53 [11351] 0+1: ## SSLway S>> shutdown from server: 0
  08/19 02:43:29.59 [11351] 0+1: ## SSLway done

  % delegated -fv -vd TLSCONF=-vd -Fdget -h FSV=sslway https://www.delegate.org
  ...
  Server: DeleGate/9.8.4-pre3
  ...
  08/19 02:44:38.73 [11366] 0+1: ## SSLway S-C: 908/908 -> 908
  08/19 02:44:38.73 [11366] 0+1: ## SSLway S-C EOF from the server
  08/19 02:44:38.73 [11366] 0+1: ## SSLway FSV S-C:908/1 C-S:82/1
  08/19 02:44:38.73 [11366] 0+1: ## SSLway S>> shutdown from server: 0
  08/19 02:44:38.73 [11366] 0+1: ## SSLway done

Cheers,
Yutaka
--
  9 9   Yutaka Sato <y.sato@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

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