RE: *****SPAM(4.2)***** [openssl.org #2086] Resolved: problem with bufferoverflowu.lib on x64 VS2008

2010-01-25 Thread Ariel Salomon via RT

Appears to be fixed in 1.0.0 tree; but 0.9.8m-beta still has part of the 
problem because it didn't get the remove duplicate code part of e.g. 
http://cvs.openssl.org/chngview?cn=18895 .

--
 - Ariel Salomon / Security Lead, Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / ar...@rti.com

RTI - The Real-Time Middleware Experts

 -Original Message-
 From: Andy Polyakov via RT [mailto:r...@openssl.org]
 Sent: Thursday, January 07, 2010 3:07 AM
 To: Ariel Salomon
 Subject: *SPAM(4.2)* [openssl.org #2086] Resolved: problem with
 bufferoverflowu.lib on x64 VS2008

 According to our records, your request has been resolved. If you have any
 further questions or concerns, please respond to this message.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #1709] DTLS BUG: retransmition of handshake messages does not work

2008-07-04 Thread Ariel Salomon via RT

The DTLS code makes some assumptions that it is using a UDP socket BIO 
to detect the timeout condition for resend.

When using another BIO type (e.g. BIO pair) on read, this does not work 
properly.

  - Ariel

Pavel via RT wrote:
 Hello,

 This problem was described by Martin Vladic, but i cant find it in RT.

 Here is description:

 Let's suppose that handshake between client and server comes to the
 point where client sends this message flight to the server:

 Certificate
 ClientKeyExchange
 CertificateVerify
 ChangeCipherSpec
 Finished [this message is protected]

 So, client comes to the stage when all subsequent messages shall be
 protected. In above message flight only last message (Finished) is
 protected. First four messages are unprotected. That's all OK.

 To continue, client needs following response from the server:

 ChangeCipherSpec
 Finished [this message is encrypted]

 What happens if such message doesn't arrive? Retransmission timer
 expires and client must send last flight again.

 But, OpenSSL DTLS implementation doesn't handle this situation very
 well. It sends the last flight of messages, but all messages are
 protected because implementation thinks that CipherSpec and keys are
 negotiated. I think that only last message must be protected, and
 first four must not (like it was in first transmission of the same
 flight).

 Also, when client retransmits his last flight (5 messages), message
 retransmit:  message 4 non-existant is printed to stderr.

 Even if client resends correct last flight (encrypting only Finished
 message),
 server will not retransmit his last flight (2 messages).

 Pavel

 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   [EMAIL PROTECTED]

   


-- 
 - Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / [EMAIL PROTECTED]

RTI - The Real-Time Middleware Experts



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]


[openssl.org #1245] fragmentation problems

2007-10-03 Thread Ariel Salomon via RT

Does anyone know the status of this patch?  The problem still exists in 
the openssl-0.9.8 stable tree (and I believe in the head/0.9.9 tree as 
well).

The patch still applies; attached is an updated version.

  - Ariel

-- 
 - Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 200-4739 / [EMAIL PROTECTED]

RTI - The Real-Time Middleware Experts


Index: ssl/d1_both.c
===
RCS file: /home/local/cvsroot/usermodules/ariel/openssl/ssl/d1_both.c,v
retrieving revision 1.4.2.4
diff -u -r1.4.2.4 d1_both.c
--- ssl/d1_both.c   30 Sep 2007 21:20:59 -  1.4.2.4
+++ ssl/d1_both.c   4 Oct 2007 00:54:17 -
@@ -725,11 +725,12 @@
 /* case (3): received a immediately useful fragment.  Determine the 
  * possible overlap and copy the fragment.
  */
-overlap = (s-init_num - DTLS1_HM_HEADER_LENGTH) - frag_off;
 
 /* retain the header for the first fragment */
 if ( s-init_num  DTLS1_HM_HEADER_LENGTH)
 {
+s-init_num -= DTLS1_HM_HEADER_LENGTH;
+overlap = (s-init_num - DTLS1_HM_HEADER_LENGTH) - frag_off;
 memmove((s-init_buf-data[s-init_num]),
 (s-init_buf-data[s-init_num + DTLS1_HM_HEADER_LENGTH + 
overlap]),
 frag_len - overlap);
@@ -737,7 +738,10 @@
 s-init_num += frag_len - overlap;
 }
 else
+{
+overlap = 0;
 s-init_num += frag_len;
+}
 
 dtls1_process_handshake_fragment(s, frag_len - overlap);