On 02/05/2024 11:52, Rahul Shukla wrote:
Thank you for the quick reply, Matt !!
Is my understanding correct thatif the buffer is empty and SSL_peek() is
invoked while trying to process more records, only application data gets
placed into that buffer?
Technically, the internal buffer is
Thank you for the quick reply, Matt !!
Is my understanding correct that if the buffer is empty and SSL_peek() is
invoked while trying to process more records, only application data gets
placed into that buffer?
--Rahul
On Thu, May 2, 2024 at 12:33 PM Matt Caswell wrote:
>
>
> On 0
On 02/05/2024 06:19, Rahul Shukla wrote:
Hi All,
As per the OpenSSL doc :
/
/
/"SSL_peek_ex() and SSL_peek() are identical to SSL_read_ex() and
SSL_read() respectively except no bytes are actually removed from the
underlying BIO during the read, so that a subsequent call to
SSL_re
Hi All,
As per the OpenSSL doc :
*"SSL_peek_ex() and SSL_peek() are identical to SSL_read_ex() and
SSL_read() respectively except no bytes are actually removed from the
underlying BIO during the read, so that a subsequent call to SSL_read_ex()
or SSL_read() will yield at least the same
Hi all,
Is SSL_peek() safe to use? I don't see it "advertised" as such, via
man-pages, but I do see the following in the 1.0.1c changelog:
Fix SSL_peek:
Both ssl2_peek and ssl3_peek, which were totally broken in earlier
releases, have been re-implemented by renami
0x828b008, buf=0xb53c,
len=1, peek=1) at s3_lib.c:3265
#7 0x08095e44 in ssl3_peek (s=0x828b008, buf=0xb53c, len=1) at
s3_lib.c:3290
#8 0x0807923b in SSL_peek (s=0x828b008, buf=0xb53c, num=1) at ssl_lib.c:969
#9 0x001657b6 in net_on_input (peer=0x82856d0) at net.c:308
[...]
(gdb)
> Actually before closing a TLS connection I need to make sure that no
> pending data is present on the that socket. So, calling SSL_peek would
> tell if this is the case or not.
No, it won't. Okay, you call SSL_peek, and there's no pending data.
Now, you're about to c
David Schwartz wrote:
>
>
>> Hi,
>> Can anyone tell me if SSL_peek is a blocking or non-blocking call ?
>
> It can be either.
>
>> When I use it inside my code, then the program blocks on this fuction
>> call
>> where there is no data on the
> Hi,
> Can anyone tell me if SSL_peek is a blocking or non-blocking call ?
It can be either.
> When I use it inside my code, then the program blocks on this fuction call
> where there is no data on the socket.
If you're using blocking socket calls, that's what will h
vne
Sent: Wednesday, October 08, 2008 4:26 PM
To: openssl-users@openssl.org
Subject: non-blocking version of SSL_peek
Hi,
Can anyone tell me if SSL_peek is a blocking or non-blocking call ?
When I use it inside my code, then the program blocks on this fuction call
where there is no data on the
Hi,
Can anyone tell me if SSL_peek is a blocking or non-blocking call ?
When I use it inside my code, then the program blocks on this fuction call
where there is no data on the socket.
The reason I want to use this call is that before closing the SSL connection
by using 'SSL_shutdown',
> > Consider a 'select' followed by a 'read' in another thread. Is
> > that the operation that shouldn't block or are the 'select' and
> > the 'read' unrelated?
> If the read was started (called) after the select finished
> (returned), then this read (and only this read) is the subsequent
> opera
Hi again :)
* David Schwartz wrote on Mon, Sep 03, 2007 at 17:36 -0700:
> > sorry, seems I'm unable to get it (I read it several times :)).
>
> 2) The application calls 'write', expecting it to block until
> all the data can be written.
yes, we already talked about. I still think that this appli
> sorry, seems I'm unable to get it (I read it several times :)). I
> think the select could (if needed) store some flag (associated
> with some fd) to remember that it returned that read must not
> block by guarantee. Maybe some list including all fds where
> select returned this. Any OS function
* David Schwartz wrote on Thu, Aug 30, 2007 at 13:44 -0700:
> > If the first byte (or any part of the buffer) could be
> > written instantly or (e.g. if no select returned ready before
> > :)) after some amount of time waited, write should return to
> > give the calling application the control.
>
> This is acceptable for Perl, but not for C :-) Even if most
> people would want a write contradicting its man page, I'd still
> consider it wrong :)
I don't follow you.
> > If you tried to write two bytes, why would you want to wait
> > until the first one could be written but not wait until t
* David Schwartz wrote on Wed, Aug 29, 2007 at 08:07 -0700:
> > > > and a blocking write should return as soon as at
> > > > least one byte has been written.
> > >
> > > No. A blocking write should block until all the requested data cen be
> > > written.
> >
> > ahh, interesting. Why should it?
>
> Actually, this page says:
> "A descriptor shall be considered ready for reading when a
> call to an input function with O_NONBLOCK clear would not
> block, whether or not the function would transfer data
> successfully."
Right, that is a hypothetical concurrent read.
> Is that not to say that
On Wed, Aug 29, 2007 at 08:07:04AM -0700, David Schwartz wrote:
> > Yes, and additionally, there may be implementations supporting a
> > select function but at the same time not even conforming the
> > standard, I think such `TCP stacks' exist.
> > BTW, which standard would it be, `4.4BSD'?
>
> I'
> Hi!
>
> * David Schwartz wrote on Tue, Aug 28, 2007 at 08:56 -0700:
> > > I think it is important to note that a blocking read usually
> > > should return if one single byte is available (even if more had
> > > been requested)
> >
> > Correct.
> >
> > > and a blocking write should return as soon
Hi!
* David Schwartz wrote on Tue, Aug 28, 2007 at 08:56 -0700:
> > I think it is important to note that a blocking read usually
> > should return if one single byte is available (even if more had
> > been requested)
>
> Correct.
>
> > and a blocking write should return as soon as at
> > least o
> David Schwartz wrote:
> > That is not only not implemented by any known implementation but quite
> > literally impossible. Please tell me what implementation
> > guarantees that a
> > TCP 'write' after a 'select' hit for writability will not block.
> This is no use, your asking me for reference
David Schwartz wrote:
That is not only not implemented by any known implementation but quite
literally impossible. Please tell me what implementation guarantees that a
TCP 'write' after a 'select' hit for writability will not block.
This is no use, your asking me for references and I'm asking y
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Steffen DETTMER
> Sent: Tuesday, August 28, 2007 2:11 AM
> To: openssl-users@openssl.org
> Subject: Re: SSL_peek vs. SSL_pending...
>
>
> I think it is important to note t
> This topic has been covered before on this list. I do not share David's
> beliefs on this matter, the select() readability and writability
> indicators are indeed sticky.
>
> That is they never disappear unless the application permits them too.
That is not only not implemented by any known imp
Darryl Miles wrote:
Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
Hello,
> Steffen DETTMER wrote:
> > this is an interesting topic. I hope it is OK to bother again
> > even if off-topic.
>
> This topic has been covered before on this list. I do not share David's
> beliefs on this matter, the select() readability and writability
> indicators are indeed sticky.
Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
That is they never
Hi,
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
* Yves Rutschle wrote on Mon, Aug 27, 2007 at 16:10 +0200:
> On Sat, Aug 25, 2007 at 12:47:57AM -0700, David Schwartz wrote:
> > > Yes? If so, the above paragraph or something similar
> > > should be documented
On Sat, Aug 25, 2007 at 12:47:57AM -0700, David Schwartz wrote:
> > Yes? If so, the above paragraph or something similar should be
> > documented somewhere important (e.g. the manpages).
>
> That's one way to put what I'm saying. I agree it needs to be repeated more
> often, that's one of the rea
> Hmm...interesting. Essentially what you are saying is "If one thinks
> they need to use select() on a blocking socket, use non-blocking sockets
> instead. And only when non-blocking sockets are insufficient, use
> select() (i.e. to avoid a CPU-eating polling type of situation without
> sacrifi
David Schwartz wrote:
David Schwartz wrote:
Which part of "For other sockets, readability means that queued data
is
available for reading such that a call to recv, WSARecv,
WSARecvFrom, or
recvfrom is _guaranteed not to block_." do you not understand?
It means a hypothetical concurrent call
> David Schwartz wrote:
> >> Which part of "For other sockets, readability means that queued data
> >> is
> >> available for reading such that a call to recv, WSARecv,
> >> WSARecvFrom, or
> >> recvfrom is _guaranteed not to block_." do you not understand?
> > It means a hypothetical concurrent
David Schwartz wrote:
Which part of "For other sockets, readability means that queued data is
available for reading such that a call to recv, WSARecv, WSARecvFrom, or
recvfrom is _guaranteed not to block_." do you not understand?
It means a hypothetical concurrent call, not a future actual call
> Which part of "For other sockets, readability means that queued data is
> available for reading such that a call to recv, WSARecv, WSARecvFrom, or
> recvfrom is _guaranteed not to block_." do you not understand?
It means a hypothetical concurrent call, not a future actual call.
There is simply
David Schwartz wrote:
MSDN Library documents select() as being exactly as I describe:
http://msdn2.microsoft.com/en-us/library/ms740141.aspx
(See the description of when readfds returns).
So now that the matter you describe has been cleared up, answer the
question.
You misunderstand the docu
> MSDN Library documents select() as being exactly as I describe:
>
> http://msdn2.microsoft.com/en-us/library/ms740141.aspx
>
> (See the description of when readfds returns).
>
> So now that the matter you describe has been cleared up, answer the
> question.
You misunderstand the documentation.
David Schwartz wrote:
What I want to know is how do I tell OpenSSL that it is okay to do some
processing of socket data but not block even with blocking sockets?
You are asking for the impossible. There is no way to be sure a socket
operation will not block other than to set the socket non-bloc
> What I want to know is how do I tell OpenSSL that it is okay to do some
> processing of socket data but not block even with blocking sockets?
You are asking for the impossible. There is no way to be sure a socket
operation will not block other than to set the socket non-blocking. Much
code has
IF SSL_pending() returns a value > 0, call SSL_read().
What I want to know is how do I tell OpenSSL that it is okay to do some
processing of socket data but not block even with blocking sockets?
According to the docs, SSL_peek() seems like it is identical to
SSL_read() except it doesn't rem
y forward progress, you try to do anything
that that forward progress might have made possible. If you make further
forward progress in that process, you again retry. You only stop when
everything you might be able to do is determined to be impossible.
> After every SSL_peek()/SSL_read() do I try to
Mikhail Kruk wrote:
After every SSL_peek()/SSL_read() do I try to issue a new SSL_write()
and if there is movement I consider it cleared ?
You don't need SSL_peak/SSL_read. SSL_write will do the reading that it
wants to do.
Hmm.. I believe that any of SSL_peek()/SSL_read() or SSL_
r and only select for read.
Every time select tells you that the socket is readable you try calling
SSL_write again. It will either succeed or it will return WANT_READ again,
in which case you keep waiting for more data... and then call SSL_write
again.
> After every SSL_peek()/SSL_re
blem scenario is pretty much solved.
What concerned me was I don't actually want to read any data while I am
bulk writing data, hence SSL_peek(). But if I'm not reading data full
stop I dont have a problem. And if I am reading data thats okay because
my application can deal with new da
rt my SSL_write() again,
because the WANT_READ condition that is stopping SSL_write() from taking
any more data has cleared ?
After every SSL_peek()/SSL_read() do I try to issue a new SSL_write()
and if there is movement I consider it cleared ?
The problem here is how to detect when I can drive my
On 6/22/06, David Schwartz <[EMAIL PROTECTED]> wrote:
> I would like OpenSSL to be an efficient approach and elegant solution
> but the more I look the less happy I'm becoming.
I find bio pairs elegant, but your point is well taken.
DS
BIO pairs are very nice if you use them e
write() again, but this time I get back WANT_READ.
Okay, so now you OpenSSL has to read some data before it can write.
> So now I can't drive my next SSL_write() from the O/S writable
> indication, because I'd end up in a tight loop, until the read data came
> in and I did a
gt;> for data to arrive. This means temporally ignoring the operating
> >> systems indication I may write data (which was previously driving my
> >> SSL_write() operations). So I'm guessing I can call SSL_peek() to clear
> >> that situation, that function doesn't ap
means temporally ignoring the operating
systems indication I may write data (which was previously driving my
SSL_write() operations). So I'm guessing I can call SSL_peek() to clear
that situation, that function doesn't appear documented but exists and
I'm guessing it will allow the
ng
> systems indication I may write data (which was previously driving my
> SSL_write() operations). So I'm guessing I can call SSL_peek() to clear
> that situation, that function doesn't appear documented but exists and
> I'm guessing it will allow the read side t
SSL_peek() there isn't much documentation about this one.
My situation is this:
* I'm using full non-blocking IO.
* My application's main task in the moment is sending bulk data, a lot
of data (enough to cause flow control bottleneck).
* My application is not interested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello
I wonder if anyone can clarify the use of SSL_peek() and SSL_read() for me.
I'm using SSL_peek() to look at a SSL session and look at the waiting data,
but when I request a particular number of bytes from it with SSL_read() i hit
pro
I'm trying to use SSL_peek() in the same way as I use recv( , ,
,MSG_PEEK), but when I ask SSL_read() to read only the first x bytes, I
only get the first x bytes, as expected, and then I lose all the data in
the queue after that.
Is this the normal behaviour, due to the way the packets a
On Mon, Mar 19, 2001 at 01:54:46PM -0500, ackka ackka wrote:
> [...] When looking into this more I found that the infinite loop is caused
> on a SSL_peek call.
Please try the beta for OpenSSL 0.9.6a (available from ftp.openssl.org
or one of the mirrors, http://www.openssl.org/
Dan Kegel <[EMAIL PROTECTED]>:
> Bodo Moeller:
>> Dan Kegel <[EMAIL PROTECTED]>:
>>> I just realized I have to accept either SSLV2 or SSLV3 (or TLS)
>>> connections, so I switched from SSLv3_server_method() to
>>> SSLv23_server_method(). But oops,
Bodo Moeller wrote:
>
> Dan Kegel <[EMAIL PROTECTED]>:
>
> > I just realized I have to accept either SSLV2 or SSLV3 (or TLS)
> > connections, so I switched from SSLv3_server_method() to
> > SSLv23_server_method(). But oops, that doesn't support SSL_peek(
> Hey, all.
> I am running into a problem with reading from a connection until a
> newline is encountered.
> I am unable to get a clear idea just what SSL_peek() is intended to do,
> which is probably the cause of my problem.
Just read it all into a buffer. If you go
Hey, all.
I am running into a problem with reading from a connection until a
newline is encountered.
I am unable to get a clear idea just what SSL_peek() is intended to do,
which is probably the cause of my problem.
I need to read from a socket, up to n bytes or until the first instance
of &#x
My next roadblock is in making sure that my SSL_peek() calls take
nonblocking sockets into account.
I understand the way SSL_read and SSL_write work, but what is the best
way to make SSL_peek work correctly when the underlying socket is
nonblocking?
TIA
Lou
Title: SSL_peek problem
Hello All,
I am facing one peculiar problem with openssl-0.9.4 and i am stuck with it for the past several days.. The problem is, I am doing SSL_write() sending some data of size 40 bytes.. At the other end i read this data using SSL_read and also doing SSL_peek
60 matches
Mail list logo
