Re: DTLS OpenSSL internal error, assertion failed: i == DTLS1_HM_HEADER_LENGTH
On Feb 11, 2011, at 5:46 AM, Robert Story wrote: Hello, I'm running an client/server application over DTLS, which works great locally, but when we started testing over the net, things got a little wacky. It appears that there is an issue somewhere with fragmentation/reassembly. I'm getting the above assertion with 0.9.8g and 1.0.0e, both on CentOS 5.5. Are both sides communicating running 1.0.0.e or is an 0.9.8g implementation involved? Best regards Michael The problem is intermittent, but easy for me to reproduce. Generally within 10 exchanges this assert will be hit. I've looked at the packets with wireshark, and there is an initial reassembled packet that appears to get dropped, and then several resend which are exactly 82 bytes shorter than the initial packet (and the packet size of the first 10 or so requests that do not trigger this assert). It would be great if I could get a patch that would gracefully handle this, instead of asserting. The last thing we need is a remote DOS attack against our application. I've attached pcaps for a successful exchange between the client and server, and one which triggered the assert. Here is the debug output from our app: dtlsudp: received 3414 raw bytes on way to dtls tls_x509:verify: verify_callback called with: ok=1 ctx=0x7fffdda0 depth=1 err=0:ok tls_x509:verify: verify_callback called with: ok=1 ctx=0x7fffdda0 depth=0 err=0:ok tls_x509:verify: returning the passed in value of 1 OpenSSL Related Errors: TLS error: SSL_read: rc=-1, sslerror = 1 (SSL_ERROR_SSL) TLS Error: bad decompression error: #336601317 (file d1_pkt.c, line 751) End of OpenSSL Errors dtlsudp: received -1 decoded bytes from dtls OpenSSL Related Errors: TLS error: SSL_read: rc=-1, sslerror = 5 (SSL_ERROR_SYSCALL): system_error=0 (Success) TLS Error: (null) dtlsudp: netsnmp_dtlsudp_recv(): transports/snmpDTLSUDPDomain.c, 509: dtlsudp: received 3414 raw bytes on way to dtls d1_both.c(663): OpenSSL internal error, assertion failed: i == DTLS1_HM_HEADER_LENGTH So it looks like it gets the same reassembled fragment twice (dtlsudp: received 3414 raw bytes on way to dtls), and it chokes on the second one. On the good packets, the packet size is 3496 bytes. Here's the stack trace (openssl-1.0.0.e): Program received signal SIGABRT, Aborted. 0x0033d2430265 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0033d2430265 in raise () from /lib64/libc.so.6 #1 0x0033d2431d10 in abort () from /lib64/libc.so.6 #2 0x2ad8143e in OpenSSLDie (file=0x2ab0f768 d1_both.c, line=663, assertion=0x2ab0f81c i == DTLS1_HM_HEADER_LENGTH) at cryptlib.c:877 #3 0x2aaf5bcf in dtls1_get_message_fragment (s=0x808fc0, st1=8640, stn=8641, max=64, ok=0x7fffdf34) at d1_both.c:663 #4 0x2aaf5210 in dtls1_get_message (s=0x808fc0, st1=8640, stn=8641, mt=20, max=64, ok=0x7fffdf34) at d1_both.c:393 #5 0x2aae379a in ssl3_get_finished (s=0x808fc0, a=8640, b=8641) at s3_both.c:215 #6 0x2aaecad4 in dtls1_accept (s=0x808fc0) at d1_srvr.c:536 #7 0x2aaf2d3f in dtls1_read_bytes (s=0x808fc0, type=23, buf=0x7e82c0 \026\376\377, len=65536, peek=0) at d1_pkt.c:747 #8 0x2aade96f in ssl3_read_internal (s=0x808fc0, buf=0x7e82c0, len=65536, peek=0) at s3_lib.c:3265 #9 0x2aadea1c in ssl3_read (s=0x808fc0, buf=0x7e82c0, len=65536) at s3_lib.c:3285 #10 0x2aaf91ea in SSL_read (s=0x808fc0, buf=0x7e82c0, num=65536) at ssl_lib.c:954 [...] Robert -- Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) dtls-bad.pcapdtls-good.pcap __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Version numbering and soname's.
Hi, I'm wondering what your plan is with version numbering and changing sonames for future versions of the library. With the 1.0.0 release you made it libssl.so.1.0.0 (and libcrypto.so.1.0.0). Current CVS HEAD seems to be having 1.1.0 as part of it's soname, OpenSSL_1_0_1-stable still has 1.0.0. So far you seem to be using 1.0.0X to do security updates, and I assume that 1.0.1 will going to be the first non-security update. I'm planning on uploading a version based on 1.0.0 to Debian soon. And I would like to keep the current soname for the rest of the release cycle. The transition from 0.9.7 to 0.9.8 took over 2 years. I also had to support both the 0.9.7 and 0.9.8 version at the same time, because some applications were still linked to the old version. I would like to avoid having to maintain multiple versions. So I hope that you will keep using the same soname as long as possible. If there is no reason to change it, please don't change it. Like the comment says in the header file, there is no reason that the version of the library should match the soname. So my question is basicly what do you think will happen in say the next 2 years with version numbers and sonames? Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Version numbering and soname's.j
On Fri, Feb 11, 2011 at 09:01:01PM +0100, Kurt Roeckx wrote: I'm planning on uploading a version based on 1.0.0 to Debian soon. And I would like to keep the current soname for the rest of the release cycle. The transition from 0.9.7 to 0.9.8 took over 2 years. I also had to support both the 0.9.7 and 0.9.8 version at the same time, because some applications were still linked to the old version. I would like to avoid having to maintain multiple versions. I assume you know that 0.9.7 and 0.9.8 were not binary compatible and thus *REQUIRED* different sonames? I have not heard that the situation changed in any way with newer releases. It would take a lot of work to make it so, and I don't see that work going on (nor do I think it should be a high priority for OpenSSL, frankly). If it has the same soname, it *has to* be 100% backwards compatible for a binary application linked to the oldest version with that soname. Both the 0.9.7 and 0.9.8 release streams managed to break that at one point or another though at least for 0.9.8 it was not as serious and most applications would continue to work. It would not be good to make the situation even worse. ELF sonames are not vanity license plates to be used to tell everyone what textual version number you picked for your shiny new library. They tell the system which libraries are guaranteed to be binary compatible with which applications. Failing to change them when changing any exposed interface is a serious bug. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Version numbering and soname's.
On Fri, Feb 11, 2011 at 03:56:53PM -0500, Thor Lancelot Simon wrote: On Fri, Feb 11, 2011 at 09:01:01PM +0100, Kurt Roeckx wrote: I'm planning on uploading a version based on 1.0.0 to Debian soon. And I would like to keep the current soname for the rest of the release cycle. The transition from 0.9.7 to 0.9.8 took over 2 years. I also had to support both the 0.9.7 and 0.9.8 version at the same time, because some applications were still linked to the old version. I would like to avoid having to maintain multiple versions. I assume you know that 0.9.7 and 0.9.8 were not binary compatible and thus *REQUIRED* different sonames? I have not heard that the situation changed in any way with newer releases. It would take a lot of work to make it so, and I don't see that work going on (nor do I think it should be a high priority for OpenSSL, frankly). If it has the same soname, it *has to* be 100% backwards compatible for a binary application linked to the oldest version with that soname. Both the 0.9.7 and 0.9.8 release streams managed to break that at one point or another though at least for 0.9.8 it was not as serious and most applications would continue to work. It would not be good to make the situation even worse. ELF sonames are not vanity license plates to be used to tell everyone what textual version number you picked for your shiny new library. They tell the system which libraries are guaranteed to be binary compatible with which applications. Failing to change them when changing any exposed interface is a serious bug. I know very well when you need to change the soname. That doesn't mean you should require an soname change for every major or even minor versions. I just want to be able to use the same soname for as long as possible. Which means that you need to be careful about changes you made. One of my problems with openssl is that changing compile time options break the ABI. And people don't seem to be willing to change this. With every version I upload to Debian I do check for possible problems before I upload it and have seen various problems during the 0.9.8 series. I've enabled some new options that did break the ABI as a result broke some applications. It also meant that I couldn't enable various options because it would break all of them. And this is all very frustrating. But it's better than having to support 20 different versions of openssl. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS OpenSSL internal error, assertion failed: i == DTLS1_HM_HEADER_LENGTH
On Feb 11, 2011, at 8:18 PM, Robert Story wrote: On Fri, 11 Feb 2011 18:05:51 +0100 Michael wrote: MT I'm running an client/server application over DTLS, which works great MT locally, but when we started testing over the net, things got a little MT wacky. It appears that there is an issue somewhere with MT fragmentation/reassembly. I'm getting the above assertion with 0.9.8g MT and 1.0.0e, both on CentOS 5.5. MT Are both sides communicating running 1.0.0.e or is an 0.9.8g implementation MT involved? Client is 1.0.0.e (Fedora 13), and I've built the server (CentOS 5.5) with both, the crash happens with 0.9.8g and 1.0.0.e on the server. Stack trace was from 1.0.0.e. So the problem occurs when 1.0.0 is communicating with 1.0.0, right? Robin will look into it when he's back from vacation... Best regards Michael -- Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Version numbering and soname's.
On Fri, Feb 11, 2011 at 10:41:54PM +0100, Kurt Roeckx wrote: One of my problems with openssl is that changing compile time options break the ABI. And people don't seem to be willing to change this. With every version I upload to Debian I do check for possible problems before I upload it and have seen various problems during the 0.9.8 series. I've enabled some new options that did How do you check? It's a nontrivial static analysis task to automate but with almost every new version -- not every trailing-letter bump, however -- I find many such problems by eyeball, just in the course of integrating the changes into our local revision control system. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2446] AutoReply: Need clarification on licensing requirements of certain files
Hi, Any possibility of getting a reply to this? We need to satisfy our lawyers. :-) Lisa -Original Message- From: The default queue via RT [mailto:r...@openssl.org] Sent: Friday, February 04, 2011 1:42 AM To: Mitchell, Lisa Subject: [openssl.org #2446] AutoReply: Need clarification on licensing requirements of certain files Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: Need clarification on licensing requirements of certain files, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #2446]. Please include the string: [openssl.org #2446] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, r...@openssl.org - Hi OpenSSL Project , I was hoping you could help us with some open source issues. Our company policy of explicit copyright license compliance is being enforced by corporate. We are being required to assure them some of the files from the Open Source SSL project are only subject to OpenSSL licenses and not any additional licenses. I have attached a spreadsheet with 29 files that I was told have ambiguous ownership statements. It would be a great help if you could answer these questions because we want to use your project and we are not sure we can without your reply. Please let us know: 1) How the content of the 28 filenames in the attached spreadsheet became licensed under the Open SSL project licenses (www.openssl.org/source/license.htmlhttp://www.openssl.org/source/license.html)? (Perhaps an Email commitment to the project, agreement or otherwise?), and 2) If there are any other intellectual property rights associated with these files which might restrict rights or add conditions to our use of the software? We are trying to make a release soon using the OpenSSL software and were just hit with this Legal requirement. Your response by 2/11/2011 would be greatly appreciated. Thank you very much, Lisa __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS OpenSSL internal error, assertion failed: i == DTLS1_HM_HEADER_LENGTH
On Fri, 11 Feb 2011 22:47:24 +0100 Michael wrote: MT So the problem occurs when 1.0.0 is communicating with 1.0.0, right? correct. MT Robin will look into it when he's back from vacation... Ok... would that be a US-type 1-2 week vacation, or a European-type 1 month vacation? :-) -- Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) signature.asc Description: PGP signature
