SSL_CTX_set_options not working for SSL_OP_NO_TLSv1_1

[Jahn, Gerhard]

Hello,

I'm usinng OpenSSL 1.0.1c in my Server application.
This application can be configured to disallow accepting certain SSL/TLS 
protocols.

If only TLS1.2 shall be allowed, the application calls

meth=(SSL_METHOD*) SSLv23_server_method();
OpenSSLctx=SSL_CTX_new(meth);

.

SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_SSLv2);  // never use SSL2

if (!allowed_ssl3)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_SSLv3);

if (!allowed_tls1)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1);

if (!allowed_tls11)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1_1);

if (!allowed_tls12)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1_2);



In the case where:

 allowed_ssl3 = allowed_tls1 = allowed_tls11 = FALSE   and  allowed_tls12 = 
TRUE

I'd expect that I cannot establish a TLS11  connection, but it does

Same is true if only SSLv3  or TLSv10 is allowed.

Am I doing something wrong?


Mit freundlichen Grüßen/Regards



Gerhard Jahn
Tel.: +49 (89) 636-44657
Tel.: +49 (211) 399 22891
Fax: +49 (89) 636-45860
mailto:gerhard.j...@atos.net
Otto-Hahn-Ring 6
81739 München, Deutschland
Germany
atos.net



Atos IT Solutions and Services GmbH
Geschäftsführung: Winfried Holz, Udo Littke;  Vorsitzender des Aufsichtsrats: 
Charles Dehelly;
Sitz der Gesellschaft: München, Deutschland; Registergericht: München, HRB 
184933.

Atos IT Solutions and Services GmbH, Legal Form: Limited Liability Company 
[GmbH];
Managing Directors: Winfried Holz, Udo Littke; Chairman of the Supervisory 
Board: Charles Dehelly;
Registered Office: Munich, Germany; District Court: Munich, HRB 184933.



inline: ATT84871 1.jpginline: ATT97807 2.jpg

RE: SSL_CTX_set_options not working for SSL_OP_NO_TLSv1_1

[Jahn, Gerhard]

 
your system. Thank you.




From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Erik Tkal
Sent: Friday, August 31, 2012 10:01 PM
To: openssl-users@openssl.org
Subject: RE: SSL_CTX_set_options not working for SSL_OP_NO_TLSv1_1

Hi Gerhard,

I have been playing with those options myself and your scenario should work.  
Try using s_server –no_ssl2 –no_ssl3 –no_tls1 –no_tls1_1 in conjunction with 
s_client –tls1_1.  This sets exactly the options you indicate and it fails to 
connect.

It’s not clear from your code, but make sure you are setting those options on 
the SSL_CTX before you create an SSL session from that context.

  Erik


Erik Tkal
Juniper OAC/UAC/Pulse Development


From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Jahn, Gerhard
Sent: Friday, August 31, 2012 5:33 AM
To: 'openssl-users@openssl.org'
Subject: SSL_CTX_set_options not working for SSL_OP_NO_TLSv1_1


Hello,

I'm usinng OpenSSL 1.0.1c in my Server application.
This application can be configured to disallow accepting certain SSL/TLS 
protocols.

If only TLS1.2 shall be allowed, the application calls

meth=(SSL_METHOD*) SSLv23_server_method();
OpenSSLctx=SSL_CTX_new(meth);

…..

SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_SSLv2);  // never use SSL2

if (!allowed_ssl3)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_SSLv3);

if (!allowed_tls1)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1);

if (!allowed_tls11)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1_1);

if (!allowed_tls12)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1_2);

….

In the case where:

 allowed_ssl3 = allowed_tls1 = allowed_tls11 = FALSE   and  allowed_tls12 = 
TRUE

I'd expect that I cannot establish a TLS11  connection, but it does

Same is true if only SSLv3  or TLSv10 is allowed.

Am I doing something wrong?


Mit freundlichen Grüßen/Regards

[cid:788453208@03092012-3200]
Gerhard Jahn
Tel.: +49 (89) 636-44657
Tel.: +49 (211) 399 22891
Fax: +49 (89) 636-45860
mailto:gerhard.j...@atos.net
Otto-Hahn-Ring 6
81739 München, Deutschland
Germany
atos.net
[cid:788453208@03092012-3207]


Atos IT Solutions and Services GmbH
Geschäftsführung: Winfried Holz, Udo Littke;  Vorsitzender des Aufsichtsrats: 
Charles Dehelly;
Sitz der Gesellschaft: München, Deutschland; Registergericht: München, HRB 
184933.

Atos IT Solutions and Services GmbH, Legal Form: Limited Liability Company 
[GmbH];
Managing Directors: Winfried Holz, Udo Littke; Chairman of the Supervisory 
Board: Charles Dehelly;
Registered Office: Munich, Germany; District Court: Munich, HRB 184933.



inline: image001.jpginline: image002.jpg

RE: SSL_CTX_set_options not working for SSL_OP_NO_TLSv1_1

[Jahn, Gerhard]

Hi Erik,

I noticed that I'm using version 1.0.1a in my app and version 1.0.1b for the 
s_client

I have updated both to 1.0.1c and everything works fine now.

Thanx.


Mit freundlichen Grüßen/Regards



Gerhard Jahn
Tel.: +49 (89) 636-44657
Fax: +49 (89) 636-45860
mailto:gerhard.j...@atos.net
Otto-Hahn-Ring 6
81739 München, Deutschland
Germany
atos.net





Geschäftsführer: Christian Oecking (Vorsitzender), Martin Bentler, 
Rainer-Christian Koppitz, Thomas Zimmermann;
Sitz der Gesellschaft: München, Deutschland; Registergericht: München, HRB 
184933
Seit 1. Juli 2011 gehört Siemens IT Solutions and Services GmbH zu AtoS.
Since July 1st, 2011 Siemens IT Solutions and Services GmbH belongs to AtoS.

Wichtiger Hinweis: Diese E-Mail und etwaige Anlagen enthalten 
firmenvertrauliche Informationen. Sollten Sie diese E-Mail irrtümlich erhalten 
haben, benachrichtigen Sie uns bitte durch Antwort-Mail und löschen Sie diese 
E-Mail nebst Anlagen von Ihrem System. Vielen Dank.
Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.




From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Erik Tkal
Sent: Friday, August 31, 2012 10:01 PM
To: openssl-users@openssl.org
Subject: RE: SSL_CTX_set_options not working for SSL_OP_NO_TLSv1_1

Hi Gerhard,

I have been playing with those options myself and your scenario should work.  
Try using s_server –no_ssl2 –no_ssl3 –no_tls1 –no_tls1_1 in conjunction with 
s_client –tls1_1.  This sets exactly the options you indicate and it fails to 
connect.

It’s not clear from your code, but make sure you are setting those options on 
the SSL_CTX before you create an SSL session from that context.

  Erik


Erik Tkal
Juniper OAC/UAC/Pulse Development


From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Jahn, Gerhard
Sent: Friday, August 31, 2012 5:33 AM
To: 'openssl-users@openssl.org'
Subject: SSL_CTX_set_options not working for SSL_OP_NO_TLSv1_1


Hello,

I'm usinng OpenSSL 1.0.1c in my Server application.
This application can be configured to disallow accepting certain SSL/TLS 
protocols.

If only TLS1.2 shall be allowed, the application calls

meth=(SSL_METHOD*) SSLv23_server_method();
OpenSSLctx=SSL_CTX_new(meth);

…..

SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_SSLv2);  // never use SSL2

if (!allowed_ssl3)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_SSLv3);

if (!allowed_tls1)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1);

if (!allowed_tls11)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1_1);

if (!allowed_tls12)
   SSL_CTX_set_options(OpenSSLctx, SSL_OP_NO_TLSv1_2);

….

In the case where:

 allowed_ssl3 = allowed_tls1 = allowed_tls11 = FALSE   and  allowed_tls12 = 
TRUE

I'd expect that I cannot establish a TLS11  connection, but it does

Same is true if only SSLv3  or TLSv10 is allowed.

Am I doing something wrong?


Mit freundlichen Grüßen/Regards

[cid:483035708@03092012-320E]
Gerhard Jahn
Tel.: +49 (89) 636-44657
Tel.: +49 (211) 399 22891
Fax: +49 (89) 636-45860
mailto:gerhard.j...@atos.net
Otto-Hahn-Ring 6
81739 München, Deutschland
Germany
atos.net
[cid:483035708@03092012-3215]


Atos IT Solutions and Services GmbH
Geschäftsführung: Winfried Holz, Udo Littke;  Vorsitzender des Aufsichtsrats: 
Charles Dehelly;
Sitz der Gesellschaft: München, Deutschland; Registergericht: München, HRB 
184933.

Atos IT Solutions and Services GmbH, Legal Form: Limited Liability Company 
[GmbH];
Managing Directors: Winfried Holz, Udo Littke; Chairman of the Supervisory 
Board: Charles Dehelly;
Registered Office: Munich, Germany; District Court: Munich, HRB 184933.



inline: image001.jpginline: image002.jpg

RE: C API to determine OpenSSL version?

[Jahn, Gerhard]

Hi Charles,


I'm using

SSLeay_version(SSLEAY_VERSION)

in my app. 

This returns a human readable string containing the OpsnSSL version like:

OpenSSL 1.0.1c 10 May 2012


Mit freundlichen Gr??en/Regards 
-

Gerhard Jahn
Tel.: +49 (89) 636-44657
Tel.: +49 (211) 399 22891
Fax: +49 (89) 636-45860 
mailto:gerhard.j...@atos.net 
Otto-Hahn-Ring 6
81739 M?nchen, Deutschland
Germany
www.atos.net

Atos IT Solutions and Services GmbH
Gesch?ftsf?hrung: Winfried Holz, Udo Littke;  Vorsitzender des Aufsichtsrats: 
Charles Dehelly; 
Sitz der Gesellschaft: M?nchen, Deutschland; Registergericht: M?nchen, HRB 
184933. 

Atos IT Solutions and Services GmbH, Legal Form: Limited Liability Company 
[GmbH]; 
Managing Directors: Winfried Holz, Udo Littke; Chairman of the Supervisory 
Board: Charles Dehelly; 
Registered Office: Munich, Germany; District Court: Munich, HRB 184933. 

 

 -Original Message-
 From: owner-openssl-us...@openssl.org 
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Charles Mills
 Sent: Tuesday, September 04, 2012 11:23 PM
 To: openssl-users@openssl.org
 Subject: C API to determine OpenSSL version?
 
 Is there a C-callable function that an application may call 
 to determine the version of the OpenSSL library with which it 
 is linked?
 
 Thanks,
 
 Charles 
 
 
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 
 __
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

[Jahn, Gerhard]

Ad:  The "correct" answer is that if you get SSL_ERROR_SYSCALL then the 
connection has failed and you shouldn't use that connection any more.

This somehow contradicts the description of returncode <0 on SSL_connect which 
says that

<0

The TLS/SSL handshake was not successful, because a fatal error occurred 
either at the protocol level or a connection failure occurred.
The shutdown was not clean. It can also occur of action is need to continue the 
operation for non-blocking BIOs.
Call SSL_get_error() with the return value ret to find out the reason.

If SSL_ERROR_SYSCAL would always mean connection failure, why then any action 
to continue the operation.
So we're getting SSL_connect() = -1 and we call SSL_get_error() returning 5  as 
advised
Then as SSL_get_error() says

SSL_ERROR_SYSCALL

  Some non-recoverable I/O error occurred. The OpenSSL error queue may 
contain more information on the error.
  For socket I/O on Unix systems, consult errno for details

We call  ERR_print_errors_fp(stderr) which gives no output.
We inspect errno which indicates EWOULDBLOCK or EAGAIN
This seems to happen rarely (once per hundreds of SSL_Connect) and as we're 
currently treating any SSL_ERROR_SYSCALL
as bogus and terminate the connection (SSL_shutdown+Socketclose)
As our server runs "forever" and has high load we see a lot of such 
"SSL_Connect errors in our Logs"
Additionally it seems to happen more frequently when connecting to a remote 
host rather than when connecting to a server co-located
I have experienced the same behavior with SSL_read/SSL_write where we also get 
SSL_ERROR_SYSCALL and find that errno is EWOULDBLOCK
But in these cases we "know" what to do (wait for readable when it appears in 
SSL_read and wait for writeable when in SSL_write)
Therefore we have the feeling that same blocking happens during 
SSL_connect?
GJ

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Matt Caswell
Sent: Friday, September 07, 2018 11:24 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == 
EWOULDBLOCK



On 07/09/18 09:16, Jahn, Gerhard wrote:
> Hi,
>
> We are using OpenSSl 1.0.2n in our server running on LINUX.
> We call SSL_connect() on async socket (after TCP connect completion)
> to establish a secure connection.
> According to DOC SSL_get_error(() has to be called if SSL_connect()
> returns <=0
>
> We do not understand what to do if SSL_get_error(() returns
> SSL_ERROR_SYSCALLand errno is EWOULDBLOCK If SSL_get_error returns
> SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to
> do... (we set the socket descriptor either in the readfds or writefds
> and call select to wait until the socket becomes readable or writeable
> (or times-out) But when EWOULDBLOCK is indicated, we do not know
> whether to wait for readable/writeable.. (setting both might be an
> idea but could easily lead to a live-loop as we suppose that the
> handshake either waits for a read or for a write but not both...

That's quite a surprising result. Possibly intervening code somewhere between 
the sys call and where you check errno has changed its value?

The "correct" answer is that if you get SSL_ERROR_SYSCALL then the connection 
has failed and you shouldn't use that connection any more.
Have you checked the openssl error stack for any reported issues?

Matt



>
> Any ideas?
> Thanks
>
> Mit freundlichen Grüßen/Best regards,
> *
> **Gerhard Jahn*
>
> Identity and Access Management
>
> Phone:  +49 (211) 399-33276
> Phone:  +49 (211) 399-22891
> Email: _gerhard.jahn@atos.net_ <mailto:gerhard.j...@atos.net>
> Otto-Hahn-Ring 6
> 81739 München, Germany
> de.atos.net
>
> Atos Information Technology GmbH; Geschäftsführung: Winfried Holz, Udo
> Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft:
> München; Registergericht: München, HRB 235509.
>
> Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche
> Informationen, die ausschließlich für den Empfänger bestimmt sind.
> Sollten Sie diese E-Mail irrtümlich erhalten haben, benachrichtigen
> Sie bitte unverzüglich den Absender per Antwort-Mail und löschen Sie
> diese E-Mail nebst Anlagen von Ihrem System. Da die Integrität
> innerhalb des Internets nicht zu gewährleisten ist, kann die Atos
> Gruppe für die Inhalteder Nachricht kein Haftung übernehmen. Obwohl
> der Absender anstrebt ein virusfreies Computernetzwerk
> sicherzustellen, kann der Absender nicht gewährleisten, dass diese
> E-Mail virusfrei ist und wird damit keine Haftung bei Schäden auf
> Grund einer Virusübermittlung übernehmen.
>
> This e-mail and the documents attached are confidential and intended
> solely for 

[openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

[Jahn, Gerhard]

Hi,

We are using OpenSSl 1.0.2n in our server running on LINUX.
We call SSL_connect() on async socket (after TCP connect completion) to 
establish a secure connection.
According to DOC SSL_get_error(() has to be called if SSL_connect() returns <=0

We do not understand what to do if SSL_get_error(() returns SSL_ERROR_SYSCALL 
and errno is EWOULDBLOCK
If SSL_get_error returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty 
clear what to do...
(we set the socket descriptor either in the readfds or writefds and call select 
to wait until the socket becomes readable or writeable (or times-out)
But when EWOULDBLOCK is indicated, we do not know whether to wait for 
readable/writeable..
(setting both might be an idea but could easily lead to a live-loop as we 
suppose that the handshake either waits for a read or for a write but not 
both...

Any ideas?
Thanks

Mit freundlichen Grüßen/Best regards,

Gerhard Jahn

Identity and Access Management

Phone:  +49 (211) 399-33276
Phone:  +49 (211) 399-22891
Email: gerhard.j...@atos.net
Otto-Hahn-Ring 6
81739 München, Germany
de.atos.net
 [cid:231545806@16122011-2476]
Atos Information Technology GmbH; Geschäftsführung: Winfried Holz, Udo Littke; 
Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: München; 
Registergericht: München, HRB 235509.

Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche Informationen, 
die ausschließlich für den Empfänger bestimmt sind. Sollten Sie diese E-Mail 
irrtümlich erhalten haben, benachrichtigen Sie bitte unverzüglich den Absender 
per Antwort-Mail und löschen Sie diese E-Mail nebst Anlagen von Ihrem System. 
Da die Integrität innerhalb des Internets nicht zu gewährleisten ist, kann die 
Atos Gruppe für die Inhalte der Nachricht kein Haftung übernehmen. Obwohl der 
Absender anstrebt ein virusfreies Computernetzwerk sicherzustellen, kann der 
Absender nicht gewährleisten, dass diese E-Mail virusfrei ist und wird damit 
keine Haftung bei Schäden auf Grund einer Virusübermittlung übernehmen.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Atos group liability cannot be triggered for the 
message content. Although the sender endeavors to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.




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

RE: SSL_get_error() crash (shortened)

[Jahn, Gerhard]

Hello,

We're using OpenSSl 1.1.1b on WIN64 and are facing a (rare but strange) 
core-dump when doing the following:

After successful TLS1.3 handshake we're calling SSL_read() to get the first 2 
Bytes of PDU data from the new connection (ASN.1 TAG + length).
SSL_read() returns 0
According to OpenSSL 1.1.1 documentation:

For SSL_read() and SSL_peek() the following return values can occur:
<= 0

  The read operation was not successful, because either the connection was 
closed, an error occurred or action must be taken by the calling process. Call 
SSL_get_error(3) 
with the return value ret to find out the reason.

We follow and call SSL_get_error() which crashes with debugger output (only 
topmost frame is shown here)

LIBSSL!SSL_get_error(struct ssl_st * s = 0x`05be9a00, int i = )+0x18c [d:\data\openssl\64\openssl-1.1.1b\ssl\ssl_lib.c @ 
3560]

The OpenSSL source at this reported line looks like:

   if ((s->shutdown & SSL_RECEIVED_SHUTDOWN) &&
(s->s3->warn_alert == SSL_AD_CLOSE_NOTIFY))
return SSL_ERROR_ZERO_RETURN;

when we inspect the session "s" in the debugger, we find that s->shutdown == 3 
and s->s3 == NULL which finally causes the crash

It looks like a bug in OpenSSL???

So far it happened only once in our LAB (after some hours of heavy SSL load 
testing with thousands of SSL connections created/deleted)
we're currently not able to reproduce it.
Any comments/ideas/fixes would be appreciated..



Gerhard Jahn
Senior Developer IAM - AITs GER BDS CySP DIRX PDM
T +49 (0) 211 399 33276
T +49 (0) 211 399 22891
gerhard.j...@atos.net
Atos Information Technology GmbH
Otto-Hahn-Ring 6
81739 Munich, Germany
atos.net/de
 << OLE Object: Picture (Device Independent Bitmap) >>


Atos Information Technology GmbH
Managing Directors: Ursula Morgenstern, Udo Littke; Chairman of the Supervisory 
Board: Eric Grall; Registered office: Munich; Commercial register of the local 
court of Munich, HRB 235509