chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] tcp-shutdown


From: Seth Alves
Subject: Re: [Chicken-hackers] tcp-shutdown
Date: Thu, 26 Jul 2012 08:02:13 -0700


Okay, this that sense.  As zbigniew says, with a normal (non-ssl) tcp 
connection, close-output-port causes the "FIN".

I'm seeing things that claim that older versions of ssl used "FIN" (which 
allowed for a type of attack) and newer ones use a "close notify alert", which 
is part of the ssl protocol.

Search for "TCP uses a FIN segment" in

  http://www.linuxjournal.com/node/4822/print

and see

  http://www.openssl.org/docs/ssl/SSL_shutdown.html#

So it seems like what I want should be possible.  I'll do some more digging.

Thanks!

    -seth



On Thu, Jul 26, 2012 at 5:40 AM, Thomas Chust <address@hidden> wrote:
> Seth Alves wrote:
>> [...]
>> I have some code that uses the openssl egg.  I'm not able to find a way
>> (as a client) to send eof to the server.
>> [...]
>
> Hello Seth,
>
> you can shutdown the entire SSL connection by closing both the input and
> output ports connected to the peer. However there is no way to shutdown
> only the sending or receiving end of a connection like it is possible
> with BSD sockets.
>
> I you close only one of the ports of an SSL connection, the access to
> that channel from Scheme becomes impossible but nothing really changes
> on the lower abstraction layers.
>
> This is not simply due to my laziness when creating the OpenSSL egg but
> because I don't know of any safe way to partially shutdown an SSL
> connection. To my knowledge the OpenSSL API and the SSL protocol itself
> only support shutting down the entire SSL session and not signalling end
> of stream on either the input or output channel.
>
>> [...]
>> I can do something like
>>
>>   (tcp-shutdown (ssl-port->tcp-port (cadr ssl-sock)) 1)
>> [...]
>
> This is definitely not safe and may lead to data loss. The problem is
> that any sort of SSL communication, be it receiving or sending data, may
> trigger features like key renegotiation that would not be possible if
> one direction of the underlying network transport was disabled. Hence,
> if you just disable the underlying TCP output channel, your SSL peer
> will probably see an end of stream on its input channel, but she might
> not be able to send any more data back to you either!
>
> I would suggest implementing the necessary end of stream signalling in a
> higher level protocol on top of SSL.
>
> Ciao,
> Thomas
>
>
> --
> When C++ is your hammer, every problem looks like your thumb.
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]