Re: [openssl-users] Version negotiation failure failure?

[Viktor Dukhovni]

> On Aug 31, 2018, at 9:14 PM, Jordan Brown  
> wrote:
> 
> We're trying to nail down error reporting for TLS version mismatches, and 
> we're seeing a couple of puzzling behaviors.
> 
> First, and most puzzling... assume these two command lines:
> 
> $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1

This disables TLS 1.0 on the server, and if SSL 3.0 is supported at compile 
time,
leaves the server willing to do SSL 3.0 or TLS 1.1 and up.

> $ openssl s_client -connect zel.us.oracle.com:4433 -tls1

This configures the client to do TLS 1.0 only via the version-specific
TLS1_client_method(), which DOES NOT support version negotiation.  It
is NOT equivalent in some subtle ways to:

  $ openssl s_client -connect zel.us.oracle.com:4433 -no_ssl3 -no_tls1_1 
-no_tls1_2

That said, in either case the client sends "TLS 1.0" is its "maximum" protocol
version in its TLS client HELLO (the TLS 1.0 protocol does not support sending
a supported version list).

> That is, I have a server that won't accept TLSv1.0, and a client that will 
> only accept TLSv1.0.

No, more precisely, you have a version-flexible server, that does not accept 1.0
and a *fixed-version* client that only supports 1.0.

What happens at that point depends on whether SSL 3.0 has been disabled on the 
server,
or not.  If SSL 3.0 is not disabled on the server (at compile time or by other 
means),
then seeing TLS 1.0 as the client's max version, the server will respond with 
SSL 3.0.
The client however, is not in a negotiating mood, and it will send a handshake 
failure
alert:

  SSL_connect:SSLv3 write client hello A
  SSL3 alert write:fatal:handshake failure
  SSL_connect:error in SSLv3 read server hello A
  140735512441800:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version 
number:s3_pkt.c:365:

and on the server side you'll see:

  SSL_accept:before/accept initialization
  SSL_accept:SSLv3 read client hello A
  SSL_accept:SSLv3 write server hello A
  SSL_accept:SSLv3 write key exchange A
  SSL_accept:SSLv3 write server done A
  SSL_accept:SSLv3 flush data
  SSL_accept:SSLv3 read client certificate A
  SSL3 alert read:fatal:handshake failure
  SSL_accept:failed in SSLv3 read client key exchange A
  ERROR
  140735512441800:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:s3_pkt.c:1498:SSL alert number 40

If, on the other hand, you *also* disable SSL 3.0 on the server, then seeing
a maxim version or TLS 1.0 from the client, but with TLS 1.0 disabled the
server wants SSL 3.0, but that's also unavailable.  For better or worse,
OpenSSL is unable with respond with a TLS 1.0 alert (TLS 1.0 is off), nor
SSL 3.0, so it simply fails:

  SSL_accept:before/accept initialization
  SSL_accept:error in SSLv2/v3 read client hello A
  ERROR
  140735512441800:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown 
protocol:s23_srvr.c:643:
  shutting down SSL

The client's view of this is:

  SSL_connect:before/connect initialization
  SSL_connect:SSLv3 write client hello A
  SSL_connect:failed in SSLv3 read server hello A
  140735512441800:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake 
failure:s3_pkt.c:659:

You might argue that would should be able to send a TLS 1.0 fatal alert even
with TLS 1.0 disabled, but that's not how the OpenSSL 1.0.x code works.  It
does not select explicitly disabled protocols for sending alerts, nor does
it select protocol versions higher than the client's limit.

In OpenSSL 1.1.x, with its more modern rewritten state machine, the behaviour 
is closer to
what you expected.  Server reports:

  SSL_accept:before SSL initialization
  SSL_accept:before SSL initialization
  SSL3 alert write:fatal:protocol version
  SSL_accept:error in error
  ERROR
  140735512441728:error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported 
protocol:../openssl/ssl/statem/statem_srvr.c:1655:

and client sees:

  SSL_connect:before SSL initialization
  SSL_connect:SSLv3/TLS write client hello
  SSL3 alert read:fatal:protocol version
  SSL_connect:error in error
  140735512441728:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert 
protocol version:../openssl/ssl/record/rec_layer_s3.c:1528:SSL alert number 70

-- 
Viktor.

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

Re: [openssl-users] Version negotiation failure failure?

[Jordan Brown]

And of course I remember just after hitting Send:  Thanks!

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] Version negotiation failure failure?

[Jordan Brown]

On 9/10/2018 1:42 PM, Kurt Roeckx wrote:
> I can not reproduce this in 1.0.1, 1.0.2, 1.1.0 or 1.1.1. I believe
> this was fixed in all branches. I've tried 1.0.2o too, and I still get
> the alert back. 

Interesting.  My attempts were on Solaris x86[*].  I'll have to try
other platforms.

[...later...]

With the Cygwin server (1.0.2n), I get different behavior.

The server says:

4294956672:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:s3_pkt.c:1500:SSL alert number 40

where you might recall the Solaris server said:

1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported
protocol:s23_srvr.c:605:

The client (either Solaris or Cygwin) says:

1:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:365:

which is perfect.

Time to go figure out why our OpenSSL server is misbehaving.

[*] As you might infer from my signature below, I work for Oracle in
the Solaris group.  My immediate organization is primarily concerned
with our Solaris-based storage products.  (That's not quite
accurate, but you don't want to know about our org chart.)

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] Version negotiation failure failure?

[Kurt Roeckx]

On Fri, Aug 31, 2018 at 06:14:25PM -0700, Jordan Brown wrote:
> We're trying to nail down error reporting for TLS version mismatches,
> and we're seeing a couple of puzzling behaviors.
> 
> First, and most puzzling... assume these two command lines:
> 
> $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1
> 
> $ openssl s_client -connect zel.us.oracle.com:4433 -tls1
> 
> That is, I have a server that won't accept TLSv1.0, and a client that
> will only accept TLSv1.0.
> 
> On the server side I see
> 
> 1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported
> protocol:s23_srvr.c:605:
> 
> which makes perfect sense.  On the client side I see
> 
> 4294956672:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl
> handshake failure:s3_pkt.c:659:
> 
> which isn't as good, but is still sort of sensible.  But when I look at
> the packets exchanged, I see that the client sends a Client Hello, and
> the server responds with an ACK and then a FIN-ACK, with no data.  It
> just hangs up the phone.  This seems to violate RFC 5246 section E.1: 
> "If server supports (or is willing to use) only versions greater than
> client_version, it MUST send a "protocol_version" alert message and
> close the connection.".  Where's my protocol version alert?
> 
> Of course my real case does not involve the sample client and server -
> it involves my own clients and servers - but I seem to see the same
> behavior with several servers (notably including the Apache httpd).
> 
> This looks like it's the same as
> https://rt.openssl.org/Ticket/Display.html?id=2777 .  I'm using 1.0.2o. 
> (But I don't see anything relevant-looking in the 1.0.2p changes.)  I've
> seen similar behavior from 1.0.2o-fips.

I can not reproduce this in 1.0.1, 1.0.2, 1.1.0 or 1.1.1. I
believe this was fixed in all branches. I've tried 1.0.2o too, and
I still get the alert back.

> And then, on the client side...
> 
> SSL_connect returns zero.  Exactly how that failure differs from a
> less-than-zero error is not clear, but OK.  The docs say to call
> SSL_get_error().  SSL_get_error() returns 5, SSL_ERROR_SYSCALL.  (That
> seems a little strange, since I don't think there's any system call
> errors here.)  The docs say to consult the error queue and errno. 
> ERR_peek_last_error( ) returns zero.  Errno is zero.  It failed, but
> nobody will tell me why.

I assume that it returns SSL_ERROR_SYSCALL because something is
not properly setting an error, and SSL_get_error() returns
SSL_ERROR_SYSCALL when it doesn't know what else to return.
If the peer just closes the connection, you should have gotten
SSL_ERROR_SSL. I assume read() returned 0 because of EOF, which is
not an error for read() so it does not set errno, but OpenSSL
should have set an error instead.


Kurt

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

Re: [openssl-users] Using Windows system certficate store for server authentication

[Jakob Bohm]

On 08/09/2018 20:00, Viktor Dukhovni wrote:

On Sat, Sep 08, 2018 at 01:44:50PM +, Salz, Rich via openssl-users wrote:


OpenSSL does not use *any* certificate store, on any platform, it is up to the 
applications to do what they need.

More precisely, OpenSSL does not bundle any trusted certificates
with the upstream source.  OpenSSL does use $OPENSSLDIR/cert.pem
and $OPENSSL/certs/ as the default CAfile and CApath respectively
via the:

SSL_CTX_set_default_verify_paths()

function.  These can also be specified via the SSL_CERT_FILE and
SSL_CERT_DIR environment variables.  Applications can specify
additional or alternative CAfile or CApath locations.

IIRC the upstream OpenSSL code does not include an interface to the
Windows Active Directory certificate store.  This may be available
from third parties.

Please note there is no "Active Directory certificate store" for
trusted CAs.

There are however at least 3 similarly named things:

- A per user/machine local CryptoAPI Certificate Store for trusted CAs,
 known intermediary CAs and known extra-bad certs (CA or EE).  This may
 or may not be accessible via the "capi" engine. Alternatively, a script
could be written in a Microsoft language (such as VBScript or
 PowerShell)to automatically keep an /etc/ssl/certs format copy of that
 data.

- An Active Directory certificate store describing mappings between
 trusted end entity certificates and kerberos accounts (such as
 "f...@bar.example.com == specific cert, HTTP/baz.examplecom==some other
 cert).  This can be accessed via LDAP but would be wholy in the
 application domain from an OpenSSL perspective (e.g. an Apache mod_ssl
 config mapping client certs to accounts via LDAP).

- An Active Directory certificate store for Microsoft's Enterprise CA
 software.  This is wholy internal to that non-OpenSSL CA software,
 although some of that data (such as revocation checking) may be
 available via LDAP.

Rule of thumb: Active Directory ~ Microsoft LDAP Directory


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] FIPS mode on Windows

[Hubert Kario]

On Friday, 7 September 2018 20:18:38 CEST Alessandro Gherardi wrote:
> I'm running Windows 10.
> I downloaded the FIPS module sources
> from https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz and the
> OpenSSL sources from https://www.openssl.org/source/openssl-1.0.2p.tar.gz .
> I built both FIPS module and OpenSSL (following the instructions
> at https://www.openssl.org/docs/fips/UserGuide-2.0.pdf to make sure OpenSSL
> uses the FIPS module) using Visual Studio.

then that does sound like it does match the policy

>  > But please note that's not the only openssl FIPS module in existence
> 
> I wasn't aware that other OpenSSL FIPS modules exist. Are those modules also
> opensource? Are they all FIPS-certified? Do you have a recommendation for
> which one is the "best" to use?

the one we use in RHEL packages is different, and it is, of course, open 
source

I wouldn't say that there is a "best" one, if it does match your requirements, 
it should be good enough.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Matt Caswell]

On 10/09/18 09:05, Jahn, Gerhard wrote:
> 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.

I don't see any contradiction in the OpenSSL docs. All this says is that
if you get <=0 return code then you need to call SSL_get_error() to find
out what to do. If you get SSL_ERROR_SYSCALL then a *non-recoverable*
I/O error has occurred.

So, in my mind, the OpenSSL documentation is clear - you've got a
non-recoverable error and therefore you shouldn't continue.

If there is a contradiction it is between the OpenSSL docs which tell
you you have a non-recoverable error and the value of errno - which
suggests a recoverable error.

This is probably down to one of two things:

1) Something has caused the value of errno to change between when the
non-recoverable error occurred and when you're checking it

or

2) A bug in OpenSSL is incorrectly interpreting a recoverable error as a
non-recoverable one.

Matt


>  
> 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_ 
>> 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 

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_ 
> 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 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