Shashank, I don't think there is a workaround for this. I've faced this very recently and the only solution is to modify your application protocol in a way that allows renegotiation to happen when things are quiet. I've rambled about it before in OpenSSL forums :
http://marc.info/?l=openssl-users&m=137873769824420&w=2 You can also read my SO post: http://stackoverflow.com/questions/18728355/ssl-renegotiation-with-full-duplex-socket-communication My understanding from all this is that OpenSSL doesn't like when application data is received while waiting for SSL handshake data. In a way, it makes sense because it is hard to do a handshake if there is a lot of application data pending in the underlying TCP pipe. As suggested above, make room for SSL renegotiation by modifying your application protocol so that renegotiation happens when the TCP pipe is empty on either side of the connection. Hope this helps. Thanks, Karthik On Mon, Jan 13, 2014 at 7:30 PM, Shashank Vinchurkar (sha1) <s...@cisco.com> wrote: > Hi, > > We are using openssl 1.0.1c version. We are seeing an issue during client > initiated renegotation with TLSv1.2. I was hoping to get some advice from > the experts in this mailer. > > The issue appears to be related to handling of application data in the > client side, after it has started the handshake for the renegotaiton ( We > have built a mechanism to indicate to the client to start rengotiation based > on configuration trigger). Client doesn's seem to like application data > after it has started renegotiation, that results in an alert from the client > to the server. Our application is a full duplex, client server application, > where both sides can send data to each other asynchronously. Application > sockets are in non-blocking mode. It seems this issue has been reported in > openssl mailing lists a few times in the past, though I couldn't find any > resolution of the issue. Attaching some of the links related to the issue. > > http://rt.openssl.org/Ticket/Display.html?id=1019 > http://rt.openssl.org/Ticket/Display.html?id=2146 > http://rt.openssl.org/Ticket/Display.html?id=2481 > > Here are the relevent logs from the client side on receving the application > data: > > 1.Sent handshake msg : version [301] : content_type [16] len [73] > 2.Sent handshake msg : version [301] : content_type [15] len [2] > 3.SSL_ERROR_SSL:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected > record:[file:line] [s3_pkt.c:1405] > > Here are the logs on the server side: > > 1.Received handshake msg : version [301] : content_type [16]len [73] > 2. Sent handshake msg : version [301] : content_type [16] len [82] > 3. Sent handshake msg : version [301] : content_type [16] len [30] > 4. Sent handshake msg : version [301] : content_type [16] len [4] > 5. Received handshake msg : version [301] : content_type [15]len [2] > 6. error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected > message:[file:line] [s3_pkt.c:1252] > 7. error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake > failure:[file:line] [s3_pkt.c:1330] > > Please let me know if there is a patch or workaround for this issue. I will > be happy to provide any additional information. > > Thanks for the help. > -Shashank > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
