Reg issue in alert message

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Reg issue in alert message

ramakrushna mishra
Hi,

I am facing an issue after openssl upgrade to 1.1.1. 
I have a odbc client with maximum version support up to TLSv1.2 and  my database is running with TLSv1.2,TLsv1.3. 

The handhake is failing and I am getting following contents on my BIO dump. 
"15 03 03 00 02 02 56" . 
If i have understood correctly this is for alert message and But I could not find any reference to alert description at ( https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )  corresponding to 56. 

So, Could you please help me figure out what does this correspond to ? 

Moreover I have following doubt. 

-- If my TLSv1.2 client does not handle the  "downgrade sentinel " present in server hello ( TLSv1.3 , will it create any problem ? 
-- In the above example client is receving error such as "SSL Handshake Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback]." ? Could you please help me to hint me about how to debug this ?

Thanks and Regards,
Ram Krushna

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Reg issue in alert message

Matt Caswell-2


On 22/10/2018 14:56, ramakrushna mishra wrote:

> Hi,
>
> I am facing an issue after openssl upgrade to 1.1.1. 
> I have a odbc client with maximum version support up to TLSv1.2 and  my
> database is running with TLSv1.2,TLsv1.3. 
>
> The handhake is failing and I am getting following contents on my BIO dump. 
> "15 03 03 00 02 02 56" . 
> If i have understood correctly this is for alert message and But I could
> not find any reference to alert description at (
> https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol ) 
> corresponding to 56.

56 hex == 86 decimal == inappropriate_fallback

i.e. this doesn't tell you any further information than you have below.

>
> So, Could you please help me figure out what does this correspond to ? 
>
> Moreover I have following doubt. 
>
> -- If my TLSv1.2 client does not handle the  "downgrade sentinel "
> present in server hello ( TLSv1.3 , will it create any problem ?

No, this should not be a problem.

> -- In the above example client is receving error such as "SSL Handshake
> Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> alert inappropriate fallback]." ? Could you please help me to hint me
> about how to debug this ?

What version of OpenSSL are you using for the client?

Is it possible for you to send me a wireshark trace of the failing
handshake?

In particular I am interested to see if the TLS_FALLBACK_SCSV
ciphersuite is present in the ClientHello (RFC 7507). The
TLS_FALLBACK_SCSV is only supposed to be sent if the client has already
attempted an earlier handshake that failed, and it is now trying a
downgraded protocol version. So, does the wireshark trace reveal the
client attempting an initial handshake that is failing for some other
reason, followed by a second attempt that fails with the inappropriate
fallback error?


Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

ramakrushna mishra
In reply to this post by ramakrushna mishra
Hi,

I am trying to upgrade openssl on solaris machine from 1.1.0e to 1.1.1b. 
The "uname -a " output from solaris is : 

SunOS  5.10 Generic_147147-26 sun4v sparc sun4v


The Configure and installation of openssl was successful.
But when i run "bin/openssl version" it fails with following error.

 "openssl version

ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found".


could you please anyone let me know what could be the problem ?


Thanks and regards,

Ram Krushna

Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

Dr. Matthias St. Pierre
My guess is that your binary is loading the system's shared libraries.
To find out whether this is the case, try

     ldd bin/openssl

If my assumption is correct, you might have to set the LD_LIBRARY_PATH explicitely.

HTH,
Matthias


On 15.03.19 09:43, ramakrushna mishra wrote:

> Hi,
>
> I am trying to upgrade openssl on solaris machine from 1.1.0e to 1.1.1b.
> The "uname -a " output from solaris is :
>
>     SunOS  5.10 Generic_147147-26 sun4v sparc sun4v
>
>
> The Configure and installation of openssl was successful.
> But when i run "bin/openssl version" it fails with following error.
>
>  "openssl version
>
> ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found".
>
>
> could you please anyone let me know what could be the problem ?
>
>
> Thanks and regards,
>
> Ram Krushna
>

Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

Dennis Clarke-2
On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> My guess is that your binary is loading the system's shared libraries.
> To find out whether this is the case, try
>
>     ldd bin/openssl
>
> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> explicitely.

Actually LD_LIBRARY_PATH is evil.

The correct way to do this is to compile with a RUNPATH set in the
output ELF files.

Building on Solaris is a real pain.

Dennis

Reply | Threaded
Open this post in threaded view
|

RE: Reg solaris support for openssl 1.1.1b

Ludwig, Mark
> From: Dennis Clarke, Friday, March 15, 2019 8:33 AM
>
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> > My guess is that your binary is loading the system's shared libraries.
> > To find out whether this is the case, try
> >
> >     ldd bin/openssl
> >
> > If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> > explicitely.
>
> Actually LD_LIBRARY_PATH is evil.
>
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.

Assuming you are in control of the destination systems' library locations, RUNPATH is desirable.

For an ISV, LD_LIBRARY_PATH is a necessary evil for application-delivered libraries.

> Building on Solaris is a real pain.

Compared with what?  This is how all Unices/*nix's work.

Best,
Mark Ludwig

Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

OpenSSL - User mailing list
In reply to this post by Dennis Clarke-2
On 15/03/2019 14:33, Dennis Clarke wrote:

> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> My guess is that your binary is loading the system's shared libraries.
>> To find out whether this is the case, try
>>
>>      ldd bin/openssl
>>
>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> explicitely.
> Actually LD_LIBRARY_PATH is evil.
>
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.
LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
testing
a newly compiled binary before installing the libraries to their final
locations, perhaps
on the same, perhaps on another machine.

P.S.
I don't known if the Solaris loader lets LD_LIBRARY_PATH override
RUNPATH as
presumed by the above answer.

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

Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

Dennis Clarke-2
On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:

> On 15/03/2019 14:33, Dennis Clarke wrote:
>> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>>> My guess is that your binary is loading the system's shared libraries.
>>> To find out whether this is the case, try
>>>
>>>      ldd bin/openssl
>>>
>>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>>> explicitely.
>> Actually LD_LIBRARY_PATH is evil.
>>
>> The correct way to do this is to compile with a RUNPATH set in the
>> output ELF files.
> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> testing
> a newly compiled binary before installing the libraries to their final
> locations, perhaps
> on the same, perhaps on another machine.
>
> P.S.
> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> RUNPATH as
> presumed by the above answer.

Yes it certainly does. Otherwise testing a new custom lib would be a
royal pain as opposed to just a pain.  Also most people still, after
twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
of breath trying to explain it after decades of watching folks skewer
themselves over and over and over ....

dc

Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

ramakrushna mishra
In reply to this post by ramakrushna mishra
Hi All,

Thanks for all your response.
I have tried to set LD_LIBRARY_PATH to the lib path of newly installed openssl and still "./openssl version" fails with the same reason.

There is another suggestion to "compile with a RUNPATH set in the
output ELF files.  " . Could anyone please provide more details about this and how to do it ? 

Thanks and Regards,
Ram Krushna
On Sat, Mar 16, 2019 at 6:20 AM <[hidden email]> wrote:
Send openssl-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
   5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)


----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Mar 2019 18:19:53 +0100
From: Jakob Bohm <[hidden email]>
To: [hidden email]
Subject: Re: Reg solaris support for openssl 1.1.1b
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 15/03/2019 14:33, Dennis Clarke wrote:
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> My guess is that your binary is loading the system's shared libraries.
>> To find out whether this is the case, try
>>
>>  ??? ldd bin/openssl
>>
>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> explicitely.
> Actually LD_LIBRARY_PATH is evil.
>
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.
LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
testing
a newly compiled binary before installing the libraries to their final
locations, perhaps
on the same, perhaps on another machine.

P.S.
I don't known if the Solaris loader lets LD_LIBRARY_PATH override
RUNPATH as
presumed by the above answer.

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



------------------------------
Message: 5
Date: Fri, 15 Mar 2019 20:49:30 -0400
From: Dennis Clarke <[hidden email]>
To: [hidden email]
Subject: Re: Reg solaris support for openssl 1.1.1b
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
> On 15/03/2019 14:33, Dennis Clarke wrote:
>> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>>> My guess is that your binary is loading the system's shared libraries.
>>> To find out whether this is the case, try
>>>
>>> ???? ldd bin/openssl
>>>
>>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>>> explicitely.
>> Actually LD_LIBRARY_PATH is evil.
>>
>> The correct way to do this is to compile with a RUNPATH set in the
>> output ELF files.
> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> testing
> a newly compiled binary before installing the libraries to their final
> locations, perhaps
> on the same, perhaps on another machine.
>
> P.S.
> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> RUNPATH as
> presumed by the above answer.

Yes it certainly does. Otherwise testing a new custom lib would be a
royal pain as opposed to just a pain.  Also most people still, after
twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
of breath trying to explain it after decades of watching folks skewer
themselves over and over and over ....

dc



------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 52, Issue 19
*********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

Dennis Clarke-2
On 3/19/19 4:38 AM, ramakrushna mishra wrote:
> Hi All,
>
> Thanks for all your response.
> I have tried to set LD_LIBRARY_PATH to the lib path of newly installed
> openssl and still "./openssl version" fails with the same reason.
>

right out of the ld man page we see the option -R passed to the linker :

     -R path
     -rpath path

         A colon-separated list of directories  used  to  specify
         library  search  directories  to  the runtime linker. If
         present and not NULL, the path is recorded in the output
         object  file  and passed to the runtime linker. Multiple
         instances of this option are concatenated together  with
         each path separated by a colon. See Directories Searched
         by the Runtime Linker in Linker and Libraries Guide.

         The use of a runpath  within  an  associated  object  is
         preferable  to  setting  global  search  paths  such  as
         through the LD_LIBRARY_PATH environment  variable.  Only
         the  runpaths  that  are  necessary  to find the objects
         dependencies should be recorded. ldd(1) can also be used
         to  discover  unused  runpaths  in dynamic objects, when
         used with the -U option.

         Various tokens can also be supplied with a runpath  that
         provide a flexible means of identifying system capabili-
         ties or an objects location. See Chapter 6, Establishing
         Dependencies  with  Dynamic String Tokens, in Linker and
         Libraries Guide. The $ORIGIN token is especially  useful
         in allowing dynamic objects to be relocated to different
         locations in the file system.


So that works. Alos there is a note about the dreaded :


     LD_LIBRARY_PATH

         A list  of  directories  in  which  to  search  for  the
         libraries specified using the -l option. Multiple direc-
         tories are separated by a colon.  In  the  most  general
         case,  this  environment variable contains two directory
         lists separated by a semicolon.

           dirlist1;dirlist2


         If ld is called with any number of occurrences of -L, as
         in:

           ld ... -Lpath1 ... -Lpathn ...


         then the search path ordering is:

           dirlist1 path1 ... pathn dirlist2 LIBPATH


         When the list of directories does not  contain  a  semi-
         colon, the list is interpreted as dirlist2.

         The LD_LIBRARY_PATH environment  variable  also  affects
         the runtime linkers search for dynamic dependencies.

         This environment variable can be specified with a _32 or
         _64   suffix.   This   makes  the  environment  variable
         specific, respectively, to 32-bit  or  64-bit  processes
         and  overrides  any non-suffixed version of the environ-
         ment variable that is in effect.


OKay good to know .. but ignore that for now.



     LD_OPTIONS

         A default set of options to  ld.  LD_OPTIONS  is  inter-
         preted by ld just as though its value had been placed on
         the command line, immediately following the name used to
         invoke ld, as in:

           ld $LD_OPTIONS ... other-arguments ...


OKay you need that.


     LD_RUN_PATH

         An alternative mechanism for specifying a runpath to the
         link-editor.  See the -R option. If both LD_RUN_PATH and
         the -R option are specified, -R supersedes.



Nice to know also.


So go back and recompile and set LD_RUN_PATH=/some/path/to/lib as well
as set LD_OPTIONS='-R/some/path/to/lib -L/some/path/to/lib ' and when
the link stage hits your output ELF files will have both a RUNPATH and
a RPATH set.  If you're using gcc you may also specify the option
-Wl,-rpath=/some/path/to/lib and you will get that passed to the linker.


dc
Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

ramakrushna mishra
In reply to this post by ramakrushna mishra
Hi All,

Thanks for your responses. 
I am able to build openssl 1.1.1 on my solaris and able to run "openssl version".
I followed the same procedure for openssl 1.1.1b and when I run "openssl version"  seeing the mentioned error. i.e 
"ld.so.1: openssl: fatal: relocation error: file openssl: symbol OPENSSL_sk_new_null: referenced symbol not found
Killed
".

So, How come it works with openssl 1.1.1 and not with 1.1.1b. 
I am using the same machine and same procedure to configure and install it. 
So, Is there anything different that need to be done for 1.1.1b version ? 

Thanks and Regards,
Ram Krushna
  

On Sat, Mar 16, 2019 at 6:20 AM <[hidden email]> wrote:
Send openssl-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
   5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)


----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Mar 2019 18:19:53 +0100
From: Jakob Bohm <[hidden email]>
To: [hidden email]
Subject: Re: Reg solaris support for openssl 1.1.1b
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 15/03/2019 14:33, Dennis Clarke wrote:
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>> My guess is that your binary is loading the system's shared libraries.
>> To find out whether this is the case, try
>>
>>  ??? ldd bin/openssl
>>
>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>> explicitely.
> Actually LD_LIBRARY_PATH is evil.
>
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.
LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
testing
a newly compiled binary before installing the libraries to their final
locations, perhaps
on the same, perhaps on another machine.

P.S.
I don't known if the Solaris loader lets LD_LIBRARY_PATH override
RUNPATH as
presumed by the above answer.

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



------------------------------
Message: 5
Date: Fri, 15 Mar 2019 20:49:30 -0400
From: Dennis Clarke <[hidden email]>
To: [hidden email]
Subject: Re: Reg solaris support for openssl 1.1.1b
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
> On 15/03/2019 14:33, Dennis Clarke wrote:
>> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
>>> My guess is that your binary is loading the system's shared libraries.
>>> To find out whether this is the case, try
>>>
>>> ???? ldd bin/openssl
>>>
>>> If my assumption is correct, you might have to set the LD_LIBRARY_PATH
>>> explicitely.
>> Actually LD_LIBRARY_PATH is evil.
>>
>> The correct way to do this is to compile with a RUNPATH set in the
>> output ELF files.
> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> testing
> a newly compiled binary before installing the libraries to their final
> locations, perhaps
> on the same, perhaps on another machine.
>
> P.S.
> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> RUNPATH as
> presumed by the above answer.

Yes it certainly does. Otherwise testing a new custom lib would be a
royal pain as opposed to just a pain.  Also most people still, after
twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
of breath trying to explain it after decades of watching folks skewer
themselves over and over and over ....

dc



------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 52, Issue 19
*********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Reg solaris support for openssl 1.1.1b

Dennis Clarke-2
On 3/26/19 12:38 AM, ramakrushna mishra wrote:

>     Hi All,
>
>
> Thanks for your responses. 
> I am able to build openssl 1.1.1 on my solaris and able to run "openssl
> version".
> I followed the same procedure for openssl 1.1.1b and when I run "openssl
> version"  seeing the mentioned error. i.e 
> "ld.so.1: openssl: fatal: relocation error: file openssl: symbol
> OPENSSL_sk_new_null: referenced symbol not found

Did you modify Configurations/10-main.conf ?



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional