Re: [openssl-users] DTLS server records repeated

[Matt Caswell]

On 21/02/18 21:38, Michael Richardson wrote:
> 
> I'm capturing from my DTLS client and server, with CoAP running on top.
> I've been debugging some ruby-level I/O buffering issues.
> I noticed this while capturing, and used tshark to get this print out.
> (I've added columns for port numbers)
> 
>   2  66.009171  ::2 35345 ::2  5684 DTLSv1.0 263 Client Hello
>   3  66.009494  ::2 5684 ::2  35345 DTLSv1.0 122 Hello Verify 
> Request
>   4  66.009798  ::2 35345 ::2  5684 DTLSv1.0 295 Client Hello
>   5  66.011771  ::2 5684 ::2  35345 DTLSv1.2 810 Server 
> Hello, Certificate, Server Key Exchange[Malformed Packet]

The Server Hello Done seems to be missing from this sequence. Perhaps
dropped somewhere en-route?

> 
>   6  67.037421  ::2 5684 ::2  35345 DTLSv1.2 148 Server Hello
>   7  67.037453  ::2 5684 ::2  35345 DTLSv1.2 562 Certificate
>   8  67.037468  ::2 5684 ::2  35345 DTLSv1.2 199 Server Key 
> Exchange[Malformed Packet]

The client is waiting for the Server Hello Done to arrive which seems to
have been dropped. Meanwhile the server is waiting for the client's
response to the flight of messages it just sent. After a timeout the
server retransmits its last flight (note the sudden increment in time
between the previous Server Key Exchange, and the second Server Hello).

> 
> And then things proceed, apparently just fine.
> 
>   9  67.037482  ::2 5684 ::2  35345 DTLSv1.2 87 Server Hello 
> Done
> 

This time the Server Hello Done has arrived.

>  10  67.037518  ::2 35345 ::2  5684 DTLSv1.0 295 Client Hello

This appears to be a retransmit on the client side. Probably the server
retransmit and the client retransmit crossed.

>  11  67.041860  ::2 35345 ::2  5684 DTLSv1.2 195 Client Key 
> Exchange, Change Cipher Spec, Encrypted Handshake Message

Now the client has received the Server Hello Done it was waiting for and
the handshake can proceed.

Matt

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Andy Polyakov]

>> And "the default for all v9 architectures is -xmemalign=8s".
> I'm getting confused.  Since I did not specify -xmemalign at all,

And not specifying -xmemalign is equivalent of specifying 8s in 64-bit
build such as one in question.

> why
> did the test fail with SIGBUS in the first place?  Seems like there
> should have been no alignment problem if the compiler is doing the right
> thing by default as you say.

Once again, objects on stack are *customarily* aligned at pointer size,
i.e. at 8 bytes in -xarch=v9 case, even if their declaration doesn't
imply corresponding guarantee. Or in other words, specifically in
context of this question, even though 'buf' is *not required* to be
aligned at 8 bytes by language standard, so far it was effectively
observed to be aligned anyway, at least on other RISC platforms. Now,
I'm *not* saying that we should *rely* on this custom, rather contrary,
we definitely should *not*. Question is what does the fact that it went
unnoticed till now mean. Or in more practical terms are there more such
dependencies that shouldn't be there? Because if possible, it would only
be appropriate to locate and eliminate them. In yet other words, mystery
is not why this specific test crashed on you, but rather what else can
crash (but doesn't for some reason).
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Norm Green]

On 2/21/2018 12:46 PM, Andy Polyakov wrote:

And "the default for all v9 architectures is -xmemalign=8s".
I'm getting confused.  Since I did not specify -xmemalign at all, why 
did the test fail with SIGBUS in the first place?  Seems like there 
should have been no alignment problem if the compiler is doing the right 
thing by default as you say.


Norm

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

[openssl-users] DTLS server records repeated

[Michael Richardson]

I'm capturing from my DTLS client and server, with CoAP running on top.
I've been debugging some ruby-level I/O buffering issues.
I noticed this while capturing, and used tshark to get this print out.
(I've added columns for port numbers)

  2  66.009171  ::2 35345 ::2  5684 DTLSv1.0 263 Client Hello
  3  66.009494  ::2 5684 ::2  35345 DTLSv1.0 122 Hello Verify 
Request
  4  66.009798  ::2 35345 ::2  5684 DTLSv1.0 295 Client Hello
  5  66.011771  ::2 5684 ::2  35345 DTLSv1.2 810 Server Hello, 
Certificate, Server Key Exchange[Malformed Packet]

The Hello/Verify/Hello makes complete sense.
tshark claims there is a malformed packet, but it seems to be the opinion
of wireshark/tshark 1.12.1, as 2.2.6 (on my desktop vs laptop)
has no problem with the packet.

But, why are the Server Hello, Certificate and ServerKeyExchange then
repeated in another three packets?  The sequence numbers in the DTLS header
seem to increment as well.  It's like some PMTU detector is getting confused
and trying to send again.

  6  67.037421  ::2 5684 ::2  35345 DTLSv1.2 148 Server Hello
  7  67.037453  ::2 5684 ::2  35345 DTLSv1.2 562 Certificate
  8  67.037468  ::2 5684 ::2  35345 DTLSv1.2 199 Server Key 
Exchange[Malformed Packet]

And then things proceed, apparently just fine.

  9  67.037482  ::2 5684 ::2  35345 DTLSv1.2 87 Server Hello 
Done

 10  67.037518  ::2 35345 ::2  5684 DTLSv1.0 295 Client Hello
 11  67.041860  ::2 35345 ::2  5684 DTLSv1.2 195 Client Key 
Exchange, Change Cipher Spec, Encrypted Handshake Message
 12  67.044257  ::2 5684 ::2  35345 DTLSv1.2 328 New Session 
Ticket, Change Cipher Spec, Encrypted Handshake Message
 13  67.044909  ::2 35345 ::2  5684 DTLSv1.2 135 Application 
Data
 14  67.056746  ::2 5684 ::2  35345 DTLSv1.2 111 Application 
Data

http://junk.sandelman.ca/junk/dtls1.pcap if you want to see more details.


--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Andy Polyakov]

> So really we could do all manner of nasty things here and watch all
> manner of performance results and cool coredumps and it would be fun to
> try.  However the option -xmemalign=8s will enforce "There should be no
> misaligned accesses in the program".

And "the default for all v9 architectures is -xmemalign=8s". Other
values are effectively for those who are lazy enough to fix broken code
taken from x86[_64]. Values other than 8s are also kind of "whole
application" things, i.e. it would be inappropriate to compile a
*library* [such as OpenSSL] with any other flag than -xmemalign=8s.
Which is why it *is* the default, has to be, so you don't have to
actually specify it. In other words assertion that not specifying
-xmemalign=8s is somehow wrong is not actually substantiated. Not
specifying it is perfectly appropriate. On related note OpenSSL is
periodically tested on RISC platforms and misalignment issues get ironed
out in time. [That's why I wondered how come it went unnoticed so far.]

Just in case for reference, default for 32-bit code is 8i. I assume that
it implies 4s, which would be consistent with expected RISC behaviour,
i.e. SIGBUS on register-sized loads/stores. Though there is ambiguity.
One would expect SIGBUG on double-precision floating point load/store
even on 32-bit system. So does 8i mean that it would actually tolerate
misaligned doubles?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 21/02/18 12:57 PM, Norm Green wrote:

On 2/21/2018 9:42 AM, Dennis Clarke wrote:

Which is correct way to do this on sparc systems.


Why do you say that?  We've been building OpenSSL on SPARC for the past 
7 years without that flag and it's worked just fine with only a few 
minor changes to the compile/link flags.


Norm



More simply ... there may be no code issue here at all.

This is a compiler issue.

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

Re: [openssl-users] Has client validated successfully?

[Jordan Brown]

On 2/20/2018 9:34 AM, J Decker wrote:
> Client does a verification and passes or fails, and via the SSL layer
> I can query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed
> certificate for verification.  If success, no action.
> If an actor lies in this scenario he answers
> lies *yes* and didn't, don't give him a means to actually verify. *noop*
> lies *no* but did, then give him the root cert he already has *noop*

Er... so I have my malicious MITM server serve up a certificate that the
client won't accept, and then helpfully provide it with my root
certificate so that it won't have any trouble talking to me?

There's a reason for the client to verify the server's certificate.  If
the client can't verify the server's certificate, then there's no reason
to believe that it's the right server and can be trusted.

Any certificate updates have to be protected by the previous
certificate.  If you've let the certificate lapse then you need some
kind of out-of-band verification.

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 21/02/18 12:57 PM, Norm Green wrote:

On 2/21/2018 9:42 AM, Dennis Clarke wrote:

Which is correct way to do this on sparc systems.


Why do you say that?  We've been building OpenSSL on SPARC for the past 
7 years without that flag and it's worked just fine with only a few 
minor changes to the compile/link flags.




The whole idea here is that openssl ( like a lot of things ) is supposed
to be portable code across a whack of platforms and while I can not
recall the dusty memories of why this option was invented way way back
in time I can at least quote the manual :


B.2.144 -xmemalign=ab

(SPARC) Use the -xmemalign option to control the assumptions that the
compiler makes about the alignment of data. By controlling the code
generated for potentially misaligned memory accesses and by controlling
program behavior in the event of a misaligned access, you can more
easily port your code to the SPARC platform.


Right ... like it says.

However what we are not saying here is what happens ( sig sig core dump
and halt ) when the system attempts to reach out and touch memory in an
icky way?  You must provide a value for both alignment and behavior :

  Alignment  Behavior
  1 at most 1 byte alignment.i Interpret access and continue exec
  2 at most 2 byte alignment.s Raise signal SIGBUS
  4 at most 4 byte alignment.f same as specifying i when the
   alignment is 1, 2, or 4,
   also same as s when a=8 or 16

  8 at most 8 byte alignment.
 16 at most 16 byte alignment.

So really we could do all manner of nasty things here and watch all
manner of performance results and cool coredumps and it would be fun to
try.  However the option -xmemalign=8s will enforce "There should be no
misaligned accesses in the program".

So sayeth the manual going back way way back in time and so sayeth ye
gray beard here from experience.  So I guess that is why I would say
this is the right way to do stuff.

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Norm Green]

On 2/21/2018 9:42 AM, Dennis Clarke wrote:

Which is correct way to do this on sparc systems.


Why do you say that?  We've been building OpenSSL on SPARC for the past 
7 years without that flag and it's worked just fine with only a few 
minor changes to the compile/link flags.


Norm

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 21/02/18 12:11 PM, Norm Green wrote:
> On 2/21/2018 8:42 AM, Dennis Clarke wrote:
>> Pretty sure I have done builds and tests. In fact I am certain of it.
>
> If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
> of your emails from yesterday) then you would not see the problem.
> -xmemalign=8s forces the compiler to use 8-byte alignment.

Which is correct way to do this on sparc systems.  I am digging into the
whole build process to see what needs to be "hacked" at to get solid and
reasonable results. The real issue is compilers.  Sorry but gcc just
won't do the right things on sparc and that isn't anyones fault.

This is where we could go down a deep dark hole.  For the sake of
getting it out there we may as well just admit that the compilers that
are generally installed on Solaris systems were of the Forte flavour way
back when little dinosaurs were still roaming the datacenters and the
cost of the license was about $3000 or so. The acquisitions and rename
of everything happened for a while there and I am surprised no one at
Sun lost their little minds and called it the Java Enterprise C Compiler
because everything else had "Java" slapped on it. Regardless, the Forte
name went away and we then had "Sun Studio" which revved up until we
were able to compile the whole source code base with it and Solaris
"UNIX" was self hosted and self boot-strappable and time marched on. So
here we are today with Oracle Studio compilers and they are very very
good. At least on sparc they are. The concept of doing a compile for a
very specific machine class was dropped on the market way back in 1999
or so and I think by 2002 we could target flavours of sparc v9 with the
vis instructions as well as a lot of hullabaloo about fused multiply
etc.  However that was a sun4c and sun4m issue back when we needed the
optional weitek coprocessor.

So anyways the "target" option was born out of necessity to get the
right opcodes for given sparc units. People had fights over the entire
x86 platform and Sun dropped it. Then picked it up again.  Then built a
version for Itanium. Put that on a shelf and hid it. Buried it. Then
went back and released a general x86 version again. Madness. I had a sit
down coffee with the global manager for the "solaris" product and it is
history now but the compiler tools for x86 were never the same quality
as the sparc tools.  Never have been.  One needs to use "fpversion" to
get the correct target and cache line options but someone at Oracle has
spilled a coffee and shuffled papers and forgot to release fpversion in
the latest flavour of the Studio compilers. I will take a look on a big
new shiney M-class machine and see what is there but I can tell you that
the openssl binaries I build from sources are at least the same speed or
better than the ones shipped out by Oracle. For a given specific type of
machine and sparc target.


jupiter # /opt/developerstudio12.5/bin/fpversion
 A SPARC-based CPU is available.
 Kernel says main memory's clock rate is 1272.0 MHz.

 Sun-4 floating-point controller version 0 found.
 An UltraSPARC chip is available.

 Use "-xtarget=sparc64viiplus -xcache=64/64/2:11264/256/11" 
code-generation option.


 Hostid = 0xBADCAFFE.


A much older system may say :


mimas $ /opt/solarisstudio12.4/bin/fpversion
 A SPARC-based CPU is available.
 Kernel says CPU's clock rate is 500.0 MHz.
 Kernel says main memory's clock rate is 100.0 MHz.

 Sun-4 floating-point controller version 0 found.
 An UltraSPARC chip is available.

 Use "-xtarget=ultra2e -xcache=16/32/1:256/64/1" code-generation option.

 Hostid = 0xBADCAFFE.


Even more bizarre and older :

ns1_$ /opt/solarisstudio12.4/bin/fpversion
 A SPARC-based CPU is available.
 Kernel says CPU's clock rate is 360.0 MHz.
 Kernel says main memory's clock rate is 90.0 MHz.

 Sun-4 floating-point controller version 0 found.
 An UltraSPARC chip is available.

 Use "-xtarget=ultra2i -xcache=16/32/1:1024/64/1" code-generation option.

 Hostid = 0xDEADBEEF.


I say "bizarre" because that is a system that uses the memory options
which were shipped on the E10k servers and those cache lines are wrong.
That machine will always report "infinite" performance from openssl
speed results and be damned if I can figure out why.  Yet.

ns1_$ /usr/local/ssl/bin/openssl speed rsa4096
Doing 4096 bit private rsa's for 10s: 13 4096 bit private RSA's in 0.00s
Doing 4096 bit public rsa's for 10s: 1436 4096 bit public RSA's in 0.00s
OpenSSL 1.0.2n  7 Dec 2017
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) 
idea(int) blowfish(ptr)
compiler: /opt/solarisstudio12.4/bin/c99 -I. -I.. -I../include  -KPIC 
-DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -Xc -g -errfmt=error -erroff=%none -xmemalign=8s 
-errshort=full -xstrconst -xildoff -m64 -xnolibmil -xcode=pic32 
-xregs=no%appl -xlibmieee -ftrap=%none -xarch=sparc -mc -xs 
-xbuiltin=%none 

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Norm Green]

On 2/21/2018 8:42 AM, Dennis Clarke wrote:
Pretty sure I have done builds and tests. In fact I am certain of it. 


If you added -xmemalign=8s to the SPARC compiler flags (as shown in one 
of your emails from yesterday) then you would not see the problem.  
-xmemalign=8s forces the compiler to use 8-byte alignment.


Norm

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

Re: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key

[Robert Watson]

Thanks for suggestion, don't understand why the compiler didn't complain
about the first argument.  Unfortunately, that just brings out other
problem
code:
bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
if (_pDH == NULL) {
FATAL("DHWrapper not initialized");
return false;
}
BIGNUM *_keyPublic, *_keyPrivate;
_keyPublic = BN_new();
_keyPrivate = BN_new();
DH_get0_key( _pDH, &_keyPublic, &_keyPrivate );
CopyKey(_keyPublic, pDst, dstLength);
return true;
}
Still fails compilation with:
/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:
In member function ‘bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)’:
/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:21:
error: invalid conversion from ‘BIGNUM** {aka bignum_st**}’ to ‘const
BIGNUM** {aka const bignum_st**}’ [-fpermissive]
  DH_get0_key( _pDH, &_keyPublic, &_keyPrivate );
 ^~~
In file included from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/misc/crypto.h:26:0,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/iobuffer.h:27,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/buffering.h:23,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/utils.h:23,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/common.h:25:
/usr/include/openssl/dh.h:183:6: note:   initializing argument 2 of ‘void
DH_get0_key(const DH*, const BIGNUM**, const BIGNUM**)’
 void DH_get0_key(const DH *dh,
  ^~~
/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:34:
error: invalid conversion from ‘BIGNUM** {aka bignum_st**}’ to ‘const
BIGNUM** {aka const bignum_st**}’ [-fpermissive]
  DH_get0_key( _pDH, &_keyPublic, &_keyPrivate );
  ^~~~
In file included from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/misc/crypto.h:26:0,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/iobuffer.h:27,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/buffering/buffering.h:23,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/utils/utils.h:23,
 from
/build/crtmpserver/src/crtmpserver/sources/common/include/common.h:25:
/usr/include/openssl/dh.h:183:6: note:   initializing argument 3 of ‘void
DH_get0_key(const DH*, const BIGNUM**, const BIGNUM**)’
 void DH_get0_key(const DH *dh,
  ^~~
make[2]: *** [common/CMakeFiles/common.dir/build.make:591:
common/CMakeFiles/common.dir/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp.o]
Error 1
make[1]: *** [CMakeFiles/Makefile2:231: common/CMakeFiles/common.dir/all]
Error 2
make: *** [Makefile:130: all] Error 2



On Wed, Feb 21, 2018 at 8:20 AM, Benjamin Kaduk  wrote:

> On 02/21/2018 10:16 AM, Robert Watson wrote:
>
> I'm trying to update a crypto library for crtmpserver to work with openssl
> 1.1.0.  The software is no longer actively maintained and my c++ skills are
> somewhat rudimentary but I keep getting a compilation error for something
> that seems trivial.
>
> Here's the code snippet:
> bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
> if (_pDH == NULL) {
> FATAL("DHWrapper not initialized");
> return false;
> }
> BIGNUM *_keyPublic,*_keyPrivate;
> _keyPublic = BN_new();
> _keyPrivate = BN_new();
> DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );
>
>
> Use '&' instead of '*'
>
> -Ben
>
> CopyKey(_keyPublic, pDst, dstLength);
> return true;
> }
>
> Here's the compilation error:
> /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:
> In member function ‘bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)’:
> /build/crtmpserver/src/crtmpserver/sources/common/
> src/utils/misc/crypto.cpp:92:47: error: cannot convert ‘BIGNUM {aka
> bignum_st}’ to ‘const BIGNUM** {aka const bignum_st**}’ for argument ‘2’ to
> ‘void DH_get0_key(const DH*, const BIGNUM**, const BIGNUM**)’
>   DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );
>^
> make[2]: *** [common/CMakeFiles/common.dir/build.make:591:
> common/CMakeFiles/common.dir/build/crtmpserver/src/
> crtmpserver/sources/common/src/utils/misc/crypto.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:231: common/CMakeFiles/common.dir/all]
> Error 2
> make: *** [Makefile:130: all] Error 2
>
> What am I doing wrong? Thanks,
> Robert
>
>
>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Viktor Dukhovni]

> On Feb 21, 2018, at 11:42 AM, Dennis Clarke  wrote:
> 
> On 21/02/18 09:14 AM, Viktor Dukhovni wrote:
>>> On Feb 21, 2018, at 5:06 AM, Andy Polyakov  wrote:
>>> 
>>> I wonder how come the problem with asn1_encode_test.c went unnoticed so
>>> far. Objects on stack are customarily aligned at pointer size, even if
>>> their declaration doesn't imply corresponding guarantee. So there are
>>> two options here: a) it's first time it's tested with SPARC Solaris cc
>>> (note that it is regularly tested on SPARC Linux, naturally with gcc);
>>> b) compiler was recently patched/upgraded. Do note that I don't dispute
>>> suggested fix (or compiler's "right" to misalign buf in this case), only
>>> wonder how come it worked so far. Implied question would be what are
>>> other possible implications of b).
>> The code introduced the misaligned "bug" is master-only, added in Apr/2017,
>> so quite possibly nobody has ever built in SunOS+SPARC, in which case it
>> never worked, but simply was never tested until now.
> 
> Pretty sure I have done builds and tests. In fact I am certain of it.

Were you testing "master"?  Or OpenSSL_1_1_0-stable?  The alignment of
"buf" is of course compiler-version dependent, and can also change from
unrelated later changes in the surrounding code.  In any case, the problem
code is comparatively recent (less than a year old), and only users testing
the master development branch on SPARC would have run into the issue.

-- 
Viktor.

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Dennis Clarke]

On 21/02/18 09:14 AM, Viktor Dukhovni wrote:




On Feb 21, 2018, at 5:06 AM, Andy Polyakov  wrote:

I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarantee. So there are
two options here: a) it's first time it's tested with SPARC Solaris cc
(note that it is regularly tested on SPARC Linux, naturally with gcc);
b) compiler was recently patched/upgraded. Do note that I don't dispute
suggested fix (or compiler's "right" to misalign buf in this case), only
wonder how come it worked so far. Implied question would be what are
other possible implications of b).


The code introduced the misaligned "bug" is master-only, added in Apr/2017,
so quite possibly nobody has ever built in SunOS+SPARC, in which case it
never worked, but simply was never tested until now.



Pretty sure I have done builds and tests. In fact I am certain of it.

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

Re: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key

[Matt Caswell]

On 21/02/18 16:20, Benjamin Kaduk via openssl-users wrote:
> On 02/21/2018 10:16 AM, Robert Watson wrote:
>> I'm trying to update a crypto library for crtmpserver to work with
>> openssl 1.1.0.  The software is no longer actively maintained and my
>> c++ skills are somewhat rudimentary but I keep getting a compilation
>> error for something that seems trivial.
>>
>> Here's the code snippet:
>> bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
>>     if (_pDH == NULL) {
>>         FATAL("DHWrapper not initialized");
>>         return false;
>>     }
>>     BIGNUM *_keyPublic,*_keyPrivate;
>>     _keyPublic = BN_new();
>>     _keyPrivate = BN_new();
>>     DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );
> 
> Use '&' instead of '*'

Yes, this is the problem. In addition to that though you have a memory
leak. DH_get0_key() will overwrite the values pointed to by _keyPublic
and_keyPrivate. So don't initialise them first with the BN_new() calls.

Matt


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

Re: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key

[Benjamin Kaduk via openssl-users]

On 02/21/2018 10:16 AM, Robert Watson wrote:
> I'm trying to update a crypto library for crtmpserver to work with
> openssl 1.1.0.  The software is no longer actively maintained and my
> c++ skills are somewhat rudimentary but I keep getting a compilation
> error for something that seems trivial.
>
> Here's the code snippet:
> bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
>     if (_pDH == NULL) {
>         FATAL("DHWrapper not initialized");
>         return false;
>     }
>     BIGNUM *_keyPublic,*_keyPrivate;
>     _keyPublic = BN_new();
>     _keyPrivate = BN_new();
>     DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );

Use '&' instead of '*'

-Ben

>     CopyKey(_keyPublic, pDst, dstLength);
>     return true;
> }
>
> Here's the compilation error:
> /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:
> In member function ‘bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)’:
> /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:47:
> error: cannot convert ‘BIGNUM {aka bignum_st}’ to ‘const BIGNUM** {aka
> const bignum_st**}’ for argument ‘2’ to ‘void DH_get0_key(const DH*,
> const BIGNUM**, const BIGNUM**)’
>   DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );
>    ^
> make[2]: *** [common/CMakeFiles/common.dir/build.make:591:
> common/CMakeFiles/common.dir/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp.o]
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:231:
> common/CMakeFiles/common.dir/all] Error 2
> make: *** [Makefile:130: all] Error 2
>
> What am I doing wrong? Thanks,
> Robert
>
>
>

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

[openssl-users] compilation error with openssl-1.1.0 and DH_get0_key

[Robert Watson]

I'm trying to update a crypto library for crtmpserver to work with openssl
1.1.0.  The software is no longer actively maintained and my c++ skills are
somewhat rudimentary but I keep getting a compilation error for something
that seems trivial.

Here's the code snippet:
bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
if (_pDH == NULL) {
FATAL("DHWrapper not initialized");
return false;
}
BIGNUM *_keyPublic,*_keyPrivate;
_keyPublic = BN_new();
_keyPrivate = BN_new();
DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );
CopyKey(_keyPublic, pDst, dstLength);
return true;
}

Here's the compilation error:
/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:
In member function ‘bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)’:
/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:47:
error: cannot convert ‘BIGNUM {aka bignum_st}’ to ‘const BIGNUM** {aka
const bignum_st**}’ for argument ‘2’ to ‘void DH_get0_key(const DH*, const
BIGNUM**, const BIGNUM**)’
  DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );
   ^
make[2]: *** [common/CMakeFiles/common.dir/build.make:591:
common/CMakeFiles/common.dir/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp.o]
Error 1
make[1]: *** [CMakeFiles/Makefile2:231: common/CMakeFiles/common.dir/all]
Error 2
make: *** [Makefile:130: all] Error 2

What am I doing wrong? Thanks,
Robert
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Viktor Dukhovni]

> On Feb 21, 2018, at 5:06 AM, Andy Polyakov  wrote:
> 
> I wonder how come the problem with asn1_encode_test.c went unnoticed so
> far. Objects on stack are customarily aligned at pointer size, even if
> their declaration doesn't imply corresponding guarantee. So there are
> two options here: a) it's first time it's tested with SPARC Solaris cc
> (note that it is regularly tested on SPARC Linux, naturally with gcc);
> b) compiler was recently patched/upgraded. Do note that I don't dispute
> suggested fix (or compiler's "right" to misalign buf in this case), only
> wonder how come it worked so far. Implied question would be what are
> other possible implications of b).

The code introduced the misaligned "bug" is master-only, added in Apr/2017,
so quite possibly nobody has ever built in SunOS+SPARC, in which case it
never worked, but simply was never tested until now.

-- 
Viktor.

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

Re: [openssl-users] Windows 1.1.1 binaries and web server

[Salz, Rich via openssl-users]

This is very useful!  Can you post an udate to the wiki?  
https://wiki.openssl.org/index.php/Binaries


On 2/21/18, 8:57 AM, "Angus Robertson - Magenta Systems Ltd" 
 wrote:

Windows developers may be interested in our Win32 build of OpenSSL
1.1.1-pre1 (alpha), the binaries are digitally code signed 'Open Source
Developer, François PIETTE', the lead developer for the Delphi Internet
Component Suite project.  About half way down the page at:

http://wiki.overbyte.eu/wiki/index.php/ICS_Download

The latest 1.0.2 and 1.1.0 are also available, digitally code signed. 

I have also built my Windows ICS web application server to use
1.1.1-pre1 (alpha) so it can be used for testing TLSv1.3, the
information page shows the protocol you connect with, the ciphers
available and the OpenSSL and draft version being used. 

Currently most browsers still connect with TLSv1.2.  

https://www2.telecom-tariffs.co.uk/serverinfo.htm

Angus

-- 
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] 1.1.1 pre1 tests failing on Solaris SPARC

[Andy Polyakov]

> https://github.com/openssl/openssl/pull/5423

I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarantee. So there are
two options here: a) it's first time it's tested with SPARC Solaris cc
(note that it is regularly tested on SPARC Linux, naturally with gcc);
b) compiler was recently patched/upgraded. Do note that I don't dispute
suggested fix (or compiler's "right" to misalign buf in this case), only
wonder how come it worked so far. Implied question would be what are
other possible implications of b).

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Andy Polyakov]

> Interesting comment :
> 
> 
>  Solaris x86 with Sun C setups
>     # There used to be solaris-x86-cc target, but it was removed,
>     # primarily because vendor assembler can't assemble our modules
>     # with -KPIC flag. As result it, assembly support, was not even
>     # available as option. But its lack means lack of side-channel
>     # resistant code, which is incompatible with security by todays
>     # standards. Fortunately gcc is readily available prepackaged
>     # option, which we can firmly point at...
>     #
>     # On related note, solaris64-x86_64-cc target won't compile code
>     # paths utilizing AVX and post-Haswell instruction extensions.
>     # Consider switching to solaris64-x86_64-gcc even here...
>     #
> 
> 
> Pre-packaged? Really ...

Nowadays you just pkgadd it from some common Oracle repository. Well, at
least on x86, as I have no idea if SPARC Solaris offers it. But the
comment is explicitly about x86.

> let's not go down the route of argument today.
> 
> 
>     "solaris64-sparcv9-cc" => {
>     inherit_from => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
>     cflags   => add_before("-xarch=v9"),
>     bn_ops   => "BN_LLONG RC4_CHAR",
>     multilib => "/64",
>     },
> 
> 
> Actually xarch=v9 is wrong.  Should just say "sparc".

So assertion is that compiler recognizes option -sparc? Don't see
anything of the sort in the manual page. Well, I can see that
contemporary compiler would recognize -xarch=sparc, but that's
*contemporary* version. But more importantly manual also says that
-xarch=v9 is equivalent to -m64 -xarch=sparc and -m64 is the essence of
this configuration. So -xarch=v9 is right, because it generates 64-bit
code and works with all compiler versions. [Well, one can probably argue
that it's time to reconsider meaning of "all compiler versions" in the
context, yet it wouldn't make "just say "sparc"" right :-)]
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL Version Definitions Issue on ARM

[Matt Caswell]

On 21/02/18 01:19, Andrei Danaila wrote:
> Any insight would be greatly appreciated.
> 

All OpenSSL versions before 1.1.0 provide no symbol version information.
However Debian distribute a patched version of OpenSSL that adds this -
so this is why you will see a difference between your system supplied
OpenSSL and the downloaded OpenSSL in this respect.

>From OpenSSL 1.1.0 onwards we do provide symbol versions on platforms
where we support that capability (e.g. Linux).

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