I'm no expert in SSL, but this seems to me to be a case of ISO/IEC 7816-4 padding vs. PKCS#7 / RFC 5652 padding. If someone can dig up the documentation which says which padding should be used, that should settle it theoretically (of course there is still the practical issue of fixing the either part to be compatible with the other :-)).
Best, Attila On Fri, Oct 25, 2013 at 5:38 PM, Andris Eiduks <[email protected]> wrote: > Hi all! > > We and our customers found that last Oracle Database 11.2 patches breaks > SSL handshake between Oracle Database package DBMS_LDAP and OpenLDAP. In > our case was used latest OpenSSL 1.0.1e libraries for SSL/TLS support. > > OpenLDAP debug log shows fillowing: > > TLS trace: SSL_accept:SSLv3 read finished A > TLS trace: SSL_accept:SSLv3 write change cipher spec A > TLS trace: SSL_accept:SSLv3 write finished A > tls_write: want=75, written=75 > 0000: 14 03 00 00 01 01 16 03 00 00 40 1c 81 00 a5 5e > ..........@....^ > 0010: b4 17 07 46 c4 dd 30 8a 89 98 8a 1b 3f 44 a2 99 > ...F..0.....?D.. > 0020: 4e 49 28 9f 1b 4e 53 c9 a4 e2 e1 3d 53 d0 b4 ae > NI(..NS....=S... > 0030: 02 0a 54 eb 64 e8 9e 3b 74 86 68 48 c6 25 60 0a > ..T.d..;t.hH.%`. > 0040: 2f 9d 56 fe ce b6 ef 00 0c cf 05 /.V........ > TLS trace: SSL_accept:SSLv3 flush data > 52569bcb connection_read(15): unable to get TLS client DN, error=49 id=1001 > 52569bcb daemon: activity on 1 descriptor > 52569bcb daemon: activity on:52569bcb > 52569bcb daemon: epoll: listen=7 active_threads=0 tvp=zero > 52569bcb daemon: activity on 1 descriptor > 52569bcb daemon: activity on:52569bcb 15r52569bcb > 52569bcb daemon: read active on 15 > 52569bcb daemon: epoll: listen=7 active_threads=0 tvp=zero > 52569bcb connection_get(15) > 52569bcb connection_get(15): got connid=1001 > 52569bcb connection_read(15): checking for input on id=1001 > ber_get_next > tls_read: want=5, got=5 > 0000: 15 03 00 00 18 ..... > tls_read: want=24, got=24 > 0000: e6 c9 40 cb b9 83 1c 6c 81 3d 8a 84 ec 77 19 96 > [email protected].=...w.. > 0010: 9b af d0 99 a6 3d 83 9b .....=.. > TLS trace: SSL3 alert read:fatal:bad record mac > > In the same time Oracle Database worked with Oracle Internet Directory > without any problem. > > Researching with tcpdump and wireshark showed that Oracle Database as SSL > Client rejects Finished message from OpenSSL. > We also found that this problem between Oracle Database and OpenSSL is > only in case of DES & 3DES cipher usage (Oracle Database currently doesnt > support ciphers with AES ... ). > > Analyse and comparing of communication between OpenSSL->OpenSSL and > Oracle->OpenSSL revealed following diference in encrypted block padding: > OpenSSL paddind is " .... 00 00 00 03" > Oracle padding is " .... 03 03 03 03" > > Looks that Oracle Database SSL client library performs verification for > padding content which must be equal with padding_length byte. > > In specifications we didn't find concrete sample how must be filled > padding info .... > > We offer to perform small change in ssl/s3_enc.c : > > if ((bs != 1) && send) > { > i=bs-((int)l%bs); > > /* we need to add 'i-1' padding bytes */ > l+=i; > /* the last of these zero bytes will be overwritten > * with the padding length. */ > /* HACK HERE memset(&rec->input[rec->length], 0, i);*/ > fprintf(stderr,"%s:%s:%d Do padding for %i > bytes\n",__FILE__,__func__,__LINE__,i); > memset(&rec->input[rec->length], (i-1), i); > rec->length+=i; > rec->input[l-1]=(i-1); > } > > > With best regards, > Andris Eiduks and colleague > >
