[openssl-users] DTLS Handshake issue (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash

Matt Caswell matt at openssl.org
Mon Feb 9 23:07:50 UTC 2015



On 09/02/15 20:17, sanchit arora wrote:
> Bug report
> 
> OS: Linux

Which distro?

> 
> OpenSSL Version: 1.0.1e-30

That is not an OpenSSL version - that is an OS vendor specific version
based on OpenSSL 1.0.1e

> While doing DTLS testing with openssl-1.0.1e-30 Version and patches
> for RT3327, RT3470 and RT3483 on top of that, we are facing an issue
> where our process is crashing during the duration run of 24 hours.
> 
> Use Case:
> *        There are 125 DTLS Server Connections and 125 DTLS Client Connections.
> *        Connection Attempts towards Server connections are also being
> made every 1 second.
> *        Client Connections are initiating connection attempts every 1 second .
> *        SSL Handshake is made to fail so that connection attempts
> continues and there are no crashes observed.
> 
> During the above duration run, process is always crashing at the below
> location always.
> 
> #4  <signal handler called>
> #5  0x00007f61e97188e9 in sha1_block_data_order_ssse3 () from
> /usr/lib64/libcrypto.so.10
> #6  0xad89a0d6776026f6 in ?? ()
> #7  0xf9e71fd74025dad7 in ?? ()
> #8  0x2243d5d8167d7997 in ?? ()
> #9  0x8bbb75d9b4efd5d8 in ?? ()
> #10 0xea9689da4d4ac2cb in ?? ()
> #11 0x7067bc5f5034983b in ?? ()
> #12 0xe19f5aa4a5679ed0 in ?? ()
> #13 0x8ecbf7e83d1d8ccd in ?? ()
> #14 0x00007f61e9a827ce in state () from /usr/lib64/libcrypto.so.10
> #15 0x00000000bc803cd0 in ?? ()
> #16 0x0000000000000011 in ?? ()
> #17 0x00007f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10
> #18 0x00007f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10
> #19 0x00007f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10

There is insufficient information in the above to diagnose the problem.
We would need a build with full debugging symbols.


> 
> When we tested with openssl-1.0.1e-16 Version and patches for RT3327,
> RT3470 and RT3483 on top of that, the use case works fine.
> 
> On investigation, we found that there are 11 patches added between
> openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following
> 3 patches are related to DTLS.
> 
> openssl-1.0.1e-dtls-ecc-ext.
> patch
> openssl-1.0.1e-cve-2014-3513.
> patch
> openssl-1.0.1e-fallback-scsv.patch
> 
> We have narrowed down that when we use openssl-1.0.1e-30 Version with
> the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470
> and RT3483 on top of that, process crashes with the above abterm
> during the duration run of 24 hours.
> 
> When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from
> openssl-1.0.1e-30 Version, we didn't see an abterm during the duration
> run of 24  hours.
> 
> Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is
> causing the abterm in the duration run.
> 
> Please let us know if there could be issues with the
> openssl-1.0.1e-dtls-ecc-ext.patch?

All of the above are vendor specific patches (probably based on original
OpenSSL commits). However I don't know from the name what dtls-ecc-ext
is referring to. You would need to address your specific question to
your vendor.

Is it possible that you can run the latest 1.0.1 version of standard
OpenSSL (i.e. OpenSSL 1.0.1l)? There have been some significant DTLS
related fixes that have been applied in recent versions.

Matt







More information about the openssl-users mailing list