Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Michel]

[...]
> From that point, the only logical conclusion that can be drawn is that 
> select() is for non-blocking I/O only. 
[...]

Ouahhh, it looks to me as an over-simplistic conclusion ! 
select() was not designed and written with future TLS state machine 
implementation in mind.

But maybe I shoudn't relaunch a debate...

:-)

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Thomas J. Hruska]

On 10/9/2017 7:49 AM, Jakob Bohm wrote:

On 09/10/2017 16:43, Thomas J. Hruska wrote:

On 10/9/2017 7:29 AM, Jakob Bohm wrote:

I suggest you find a good authoritative source for your claim
that select() should not be used with blocking sockets.


http://man7.org/linux/man-pages/man2/select.2.html

Section BUGS:

"Under Linux, select() may report a socket file descriptor as "ready 
for reading", while nevertheless a subsequent read blocks. This could 
for example happen when data has arrived but upon examination has 
wrong checksum and is discarded.  There may be other circumstances in 
which a file descriptor is spuriously reported as ready.  Thus it may 
be safer to use O_NONBLOCK on sockets that should not block."



Authoritative enough for you?


That must be a recent change then.  But certainly that is a bug
in Linux select, not in programs relying on the (long time)
documented correct behavior.


The OpenSSL layer over TCP/IP complicates matters more across ALL 
platforms:  SSL_read() may need to write (and SSL_write() may need to 
read).  Even if the socket has data to read according to select(), if 
the respective write end is full (or vice versa for SSL_write()), then 
the call WILL block when using blocking sockets.


You can't resolve the above issue with select() or any other function 
UNLESS you switch to non-blocking socket descriptors.  From that point, 
the only logical conclusion that can be drawn is that select() is for 
non-blocking I/O only.  Then the documented "bug" in Linux becomes a 
misunderstanding of what select() is actually intended for across all 
platforms:  Preventing spurious CPU usage for non-blocking I/O. 
select() is just a notification that MAYBE you can read or MAYBE you can 
write, but there is no guarantee of either succeeding.


--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Michel]

Hi Thomas,

As mentioned previously, I do NOT "want to block" or "hack" with OpenSSL
state machine. 
And again, I agree with you that non-blocking socket programming is best and
more flexible.

I just wanted to understand your point and it is now clear for me since I
read the BUGS section of http://man7.org/linux/man-pages/man2/select.2.html.
Thanks for this, I was not aware of that, I learned something today.
:-)

However I don't think this is a "common misunderstanding of select()" as it
is a *BUG* [hopefully] of only select() under linux.
Not a design implementation of *select() and friends* (pselect, poll, epoll,
...) on every other systems.
And on this matter, I don't believe that code relying on interface
documentation is *bad code* by nature, and - IMHO - a bug should be fixed
rather than killing everything around (kind of terrorism programming ? ;-).

Anyway, thanks to have shared your opinion and advices with me.

Regards,

Michel.


-Message d'origine-
De : openssl-users [mailto:openssl-users-boun...@openssl.org] De la part de
Thomas J. Hruska
Envoyé : lundi 9 octobre 2017 15:32
À : openssl-users@openssl.org
Objet : Re: [openssl-users] Graceful shutdown of TLS connection for blocking
sockets

On 10/9/2017 1:32 AM, Michel wrote:
>> With blocking sockets, you just loop back around and repeat the same 
>> call
> if either of those messages are returned by SSL_get_error(). No 
> select() required.
> 
> Yes, you have to repeat the same call, but select() is still usefull, 
> especially with blocking sockets.

And leads to incorrect code and weird blocking scenarios.  Been there, done
that.  You're using select() wrong.  If you want to block, then block and
don't try to hack around it.  Otherwise use non-blocking.

This common misunderstanding of select() is precisely why calling it with a
blocking descriptor should trigger an exception that kills the application.
Doing so would bring a quick end to a lot of bad code.

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Jakob Bohm]

On 09/10/2017 16:43, Thomas J. Hruska wrote:

On 10/9/2017 7:29 AM, Jakob Bohm wrote:

I suggest you find a good authoritative source for your claim
that select() should not be used with blocking sockets.


http://man7.org/linux/man-pages/man2/select.2.html

Section BUGS:

"Under Linux, select() may report a socket file descriptor as "ready 
for reading", while nevertheless a subsequent read blocks. This could 
for example happen when data has arrived but upon examination has 
wrong checksum and is discarded.  There may be other circumstances in 
which a file descriptor is spuriously reported as ready.  Thus it may 
be safer to use O_NONBLOCK on sockets that should not block."



Authoritative enough for you?


That must be a recent change then.  But certainly that is a bug
in Linux select, not in programs relying on the (long time)
documented correct behavior.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Thomas J. Hruska]

On 10/9/2017 7:29 AM, Jakob Bohm wrote:

I suggest you find a good authoritative source for your claim
that select() should not be used with blocking sockets.


http://man7.org/linux/man-pages/man2/select.2.html

Section BUGS:

"Under Linux, select() may report a socket file descriptor as "ready for 
reading", while nevertheless a subsequent read blocks.  This could for 
example happen when data has arrived but upon examination has wrong 
checksum and is discarded.  There may be other circumstances in which a 
file descriptor is spuriously reported as ready.  Thus it may be safer 
to use O_NONBLOCK on sockets that should not block."



Authoritative enough for you?

--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Jakob Bohm]

On 09/10/2017 15:31, Thomas J. Hruska wrote:

On 10/9/2017 1:32 AM, Michel wrote:
With blocking sockets, you just loop back around and repeat the same 
call

if either of those messages are returned by SSL_get_error(). No select()
required.

Yes, you have to repeat the same call, but select() is still usefull,
especially with blocking sockets.


And leads to incorrect code and weird blocking scenarios.  Been there, 
done that.  You're using select() wrong.  If you want to block, then 
block and don't try to hack around it.  Otherwise use non-blocking.


This common misunderstanding of select() is precisely why calling it 
with a blocking descriptor should trigger an exception that kills the 
application.  Doing so would bring a quick end to a lot of bad code.



The system documentation (at least on Linux) isn't just silent
about how select behaves with blocking sockets.  It is
*explicitly* written to describe how it works with blocking
sockets (but is mostly silent about non-blocking sockets).
(My copy is marked as being from Linux man-pages project version
3.74).

I suggest you find a good authoritative source for your claim
that select() should not be used with blocking sockets.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Thomas J. Hruska]

On 10/9/2017 1:32 AM, Michel wrote:

With blocking sockets, you just loop back around and repeat the same call

if either of those messages are returned by SSL_get_error(). No select()
required.

Yes, you have to repeat the same call, but select() is still usefull,
especially with blocking sockets.


And leads to incorrect code and weird blocking scenarios.  Been there, 
done that.  You're using select() wrong.  If you want to block, then 
block and don't try to hack around it.  Otherwise use non-blocking.


This common misunderstanding of select() is precisely why calling it 
with a blocking descriptor should trigger an exception that kills the 
application.  Doing so would bring a quick end to a lot of bad code.


--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl FIPS 186-4 Patch

[murugesh pitchaiah]

Hi,

Thanks for the comment.

I know that openSSL is not 186-4 compliant. That is why I am looking
for anybody have the patch for the same.

I see there are some works in Fedora:
http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.1.0-fips.patch

Thanks,
Murugesh P.

On 10/6/17, Salz, Rich via openssl-users  wrote:
> ➢ This FIPS186-4 is not just about SHA. It basically about the key
> generation parameters. Especially I am looking for RSA key generation
> parameters wrt FIPS 186-4.
>
> I do not know how you got the opinion that OpenSSL has 186-4 support. It
> does not.  Perhaps other people have written patches.  If you find them, ask
> them to share with us (
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Michel]

> With blocking sockets, you just loop back around and repeat the same call
if either of those messages are returned by SSL_get_error(). No select()
required.

Yes, you have to repeat the same call, but select() is still usefull,
especially with blocking sockets.

Regards,

Michel.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users