Hi Karthik, Thanks a lot for the response. I will also go through the route of modifying the application for renegotiation.
-Shashank On 1/14/14 7:44 AM, "Karthik Krishnamurthy" <karthik3...@gmail.com> wrote: >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-du >plex-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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
