Re: [openssl-users] DTLS server records repeated
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
>> 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
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
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
> 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
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?
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
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
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
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 -xdebugforma
Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
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
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
> 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
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
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
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
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
> 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
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
> 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
> 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
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
