Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
Hi Matt,
Can you share s3_srvr.c file which is based on 1.1.0 release where DTLS
session resumption works? I tried downloading 1.1.0-pre5 but i didnt see
any file related with s3_srvr.c.
Thanks,
Rajeswari.
On Mon, May 16, 2016 at 11:20 AM, Rajeswari K <raji.kotamr...@gmail.com>
wrote:
> Hi Matt,
>
> Yes, i tested with your patch. Honestly, before writing to openssl-dev
> team, i tried session resumption with moving the version just like what you
> gave as patch. But, still session resumption didn't work for me. Am
> debugging same at openssl front.
>
> Just to confirm on the issue, i tried hardcoding s->version and s->method
> with DTLSv1 just after calling SSL_new() followed by SSL_clear(). Then
> Session resumption worked as expected.
>
> So, updation of s->version during handshake and updation of
> s->session->version has some relation which am trying to find out.
>
> I was looking at updation of s->session->version during handshake when the
> version is DTLS_ANY_VERSION. Will check and update you on my findings if
> any.
>
> Thanks,
> Rajeswari.
>
>
> On Fri, May 13, 2016 at 11:16 PM, Matt Caswell <m...@openssl.org> wrote:
>
>>
>>
>> On 13/05/16 18:33, Rajeswari K wrote:
>> > Hi Matt,
>> >
>> > Thanks for the response.
>> >
>> > But, this fix doesn't perform session resumption.
>>
>> Did you try the patch?
>>
>> As you pointed out we hit the following line:
>>
>> if (i == 1 && s->version == s->session->ssl_version) { /* previous
>> * session
>> */
>>
>> The version from the SSL object and the version from the session do not
>> match and that is why session resumption does not take place.
>>
>> The reason that the versions do not match is because version negotiation
>> takes place *after* this check. So at this point s->version equals
>> DTLS_ANY_VERSION. My patch moves the version negotiation to before the
>> above test so that s->version should now be equal to DTLSv1, and
>> therefore should be the same as in s->session->ssl_version, and session
>> resumption should be successful.
>>
>> Matt
>>
>>
>>
>> >
>> > Thanks,
>> > Rajeswari.
>> >
>> > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <m...@openssl.org
>> > <mailto:m...@openssl.org>> wrote:
>> >
>> >
>> >
>> > On 10/05/16 18:34, Rajeswari K wrote:
>> > > Hello openssl-dev team,
>> > >
>> > > Having query regarding DTLS session resumption when configured
>> SSL_CTX
>> > > with DTLS_ANY_VERSION.
>> > >
>> > > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
>> > > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD
>> to
>> > > support both the versions (i.e. DTLS1.0 and DTLS1.2).
>> > >
>> > > During handshake, we landed on to version DTLS1.0.i.e.
>> > > s->session->version holds 0xFEFF.
>> > >
>> > > In order to perform session resumption, we derived new SSL
>> structure
>> > > from global ssl_ctx using SSL_new() and tried performing ssl
>> > handshake.
>> > >
>> > > With the below logic,
>> > > else {
>> > > i = ssl_get_prev_session(s, p, j, d + n);
>> > > /*
>> > > * Only resume if the session's version matches the
>> negotiated
>> > > * version.
>> > > * RFC 5246 does not provide much useful advice on
>> resumption
>> > > * with a different protocol version. It doesn't forbid
>> it but
>> > > * the sanity of such behaviour would be questionable.
>> > > * In practice, clients do not accept a version mismatch
>> and
>> > > * will abort the handshake with an error.
>> > > */
>> > > if (i == 1 && s->version == s->session->ssl_version) { /*
>> > previous
>> > > *
>> > session */
>> > > s->hit = 1;
>> > > } else if (i == -1)
>> > > goto err;
>> > > else { /* i == 0 */
>&g
Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
Hi Matt,
Yes, i tested with your patch. Honestly, before writing to openssl-dev
team, i tried session resumption with moving the version just like what you
gave as patch. But, still session resumption didn't work for me. Am
debugging same at openssl front.
Just to confirm on the issue, i tried hardcoding s->version and s->method
with DTLSv1 just after calling SSL_new() followed by SSL_clear(). Then
Session resumption worked as expected.
So, updation of s->version during handshake and updation of
s->session->version has some relation which am trying to find out.
I was looking at updation of s->session->version during handshake when the
version is DTLS_ANY_VERSION. Will check and update you on my findings if
any.
Thanks,
Rajeswari.
On Fri, May 13, 2016 at 11:16 PM, Matt Caswell <m...@openssl.org> wrote:
>
>
> On 13/05/16 18:33, Rajeswari K wrote:
> > Hi Matt,
> >
> > Thanks for the response.
> >
> > But, this fix doesn't perform session resumption.
>
> Did you try the patch?
>
> As you pointed out we hit the following line:
>
> if (i == 1 && s->version == s->session->ssl_version) { /* previous
> * session
> */
>
> The version from the SSL object and the version from the session do not
> match and that is why session resumption does not take place.
>
> The reason that the versions do not match is because version negotiation
> takes place *after* this check. So at this point s->version equals
> DTLS_ANY_VERSION. My patch moves the version negotiation to before the
> above test so that s->version should now be equal to DTLSv1, and
> therefore should be the same as in s->session->ssl_version, and session
> resumption should be successful.
>
> Matt
>
>
>
> >
> > Thanks,
> > Rajeswari.
> >
> > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <m...@openssl.org
> > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 10/05/16 18:34, Rajeswari K wrote:
> > > Hello openssl-dev team,
> > >
> > > Having query regarding DTLS session resumption when configured
> SSL_CTX
> > > with DTLS_ANY_VERSION.
> > >
> > > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> > > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> > > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> > >
> > > During handshake, we landed on to version DTLS1.0.i.e.
> > > s->session->version holds 0xFEFF.
> > >
> > > In order to perform session resumption, we derived new SSL
> structure
> > > from global ssl_ctx using SSL_new() and tried performing ssl
> > handshake.
> > >
> > > With the below logic,
> > > else {
> > > i = ssl_get_prev_session(s, p, j, d + n);
> > > /*
> > > * Only resume if the session's version matches the
> negotiated
> > > * version.
> > > * RFC 5246 does not provide much useful advice on
> resumption
> > > * with a different protocol version. It doesn't forbid it
> but
> > > * the sanity of such behaviour would be questionable.
> > > * In practice, clients do not accept a version mismatch
> and
> > > * will abort the handshake with an error.
> > > */
> > > if (i == 1 && s->version == s->session->ssl_version) { /*
> > previous
> > > *
> > session */
> > > s->hit = 1;
> > > } else if (i == -1)
> > > goto err;
> > > else { /* i == 0 */
> > >
> > > if (!ssl_get_new_session(s, 1))
> > > goto err;
> > > }
> > >
> > > Since s->version is with 0xFEFD and s->session->ssl_version is
> 0xFEFF,
> > > we always try for new session and wont land on to session
> resumption
> > > though client has sent the session_id.
> > >
> > > Is this intended behaviour? Please clarify.
> >
> >
> > No. This appears to be a bug introduced by commit 03d14f588734 in
> > November 2014.
> >
> > The real problem though is that the DTLS version negotiation is
> > happening too late - after session resumption. Interestingly this
> only
> > seems to be a problem in 1.0.2. In 1.1.0 this is working correctly
> (the
> > version negotiation logic has been substantially rewritten in the new
> > version).
> >
> > Please could you try out the attached patch? Let me know how you get
> on.
> >
> > Thanks
> >
> > Matt
> >
> > --
> > openssl-dev mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> >
> >
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
Hi Matt,
Thanks for the response.
But, this fix doesn't perform session resumption.
Thanks,
Rajeswari.
On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <m...@openssl.org> wrote:
>
>
> On 10/05/16 18:34, Rajeswari K wrote:
> > Hello openssl-dev team,
> >
> > Having query regarding DTLS session resumption when configured SSL_CTX
> > with DTLS_ANY_VERSION.
> >
> > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> >
> > During handshake, we landed on to version DTLS1.0.i.e.
> > s->session->version holds 0xFEFF.
> >
> > In order to perform session resumption, we derived new SSL structure
> > from global ssl_ctx using SSL_new() and tried performing ssl handshake.
> >
> > With the below logic,
> > else {
> > i = ssl_get_prev_session(s, p, j, d + n);
> > /*
> > * Only resume if the session's version matches the negotiated
> > * version.
> > * RFC 5246 does not provide much useful advice on resumption
> > * with a different protocol version. It doesn't forbid it but
> > * the sanity of such behaviour would be questionable.
> > * In practice, clients do not accept a version mismatch and
> > * will abort the handshake with an error.
> > */
> > if (i == 1 && s->version == s->session->ssl_version) { /*
> previous
> > *
> session */
> > s->hit = 1;
> > } else if (i == -1)
> > goto err;
> > else { /* i == 0 */
> >
> > if (!ssl_get_new_session(s, 1))
> > goto err;
> > }
> >
> > Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
> > we always try for new session and wont land on to session resumption
> > though client has sent the session_id.
> >
> > Is this intended behaviour? Please clarify.
>
>
> No. This appears to be a bug introduced by commit 03d14f588734 in
> November 2014.
>
> The real problem though is that the DTLS version negotiation is
> happening too late - after session resumption. Interestingly this only
> seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
> version negotiation logic has been substantially rewritten in the new
> version).
>
> Please could you try out the attached patch? Let me know how you get on.
>
> Thanks
>
> Matt
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
Hello openssl-dev team,
Having query regarding DTLS session resumption when configured SSL_CTX with
DTLS_ANY_VERSION.
When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to support
both the versions (i.e. DTLS1.0 and DTLS1.2).
During handshake, we landed on to version DTLS1.0.i.e. s->session->version
holds 0xFEFF.
In order to perform session resumption, we derived new SSL structure from
global ssl_ctx using SSL_new() and tried performing ssl handshake.
With the below logic,
else {
i = ssl_get_prev_session(s, p, j, d + n);
/*
* Only resume if the session's version matches the negotiated
* version.
* RFC 5246 does not provide much useful advice on resumption
* with a different protocol version. It doesn't forbid it but
* the sanity of such behaviour would be questionable.
* In practice, clients do not accept a version mismatch and
* will abort the handshake with an error.
*/
if (i == 1 && s->version == s->session->ssl_version) { /* previous
* session */
s->hit = 1;
} else if (i == -1)
goto err;
else { /* i == 0 */
if (!ssl_get_new_session(s, 1))
goto err;
}
Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF, we
always try for new session and wont land on to session resumption though
client has sent the session_id.
Is this intended behaviour? Please clarify.
Thanks,
Rajeswari.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: Memory hold issue
Hello Team, I tried to set the cache off using following command, SSL_CTX_set_session_cache_mode(sslctx, SSL_SESS_CACHE_OFF); With this, am not seeing any memory hold. That means this memory is due to storage of ssl session information? If it is SSL session storage, when does this SSL session information will be cleared? When we do SSL_CTX_free() does this get free'd? Or Where actually this session information will be saved. Can some provide some light on this information. Any URL where this information is stored is fine. Thanks, Rajeswari. On Tue, Aug 26, 2014 at 2:08 PM, Rajeswari K raji.kotamr...@gmail.com wrote: Isn't CRYPTO_cleanup_all_ex_data() frees all ex_data? I hope the issue over here is holding the session information for resumption is my guess. How can we disable session resumption feature inorder not to update the session details and check whether complete memory is freed during SSL_CTX_free() or not? On Tue, Aug 26, 2014 at 1:31 PM, bernard Hauzeur b...@artofe.biz wrote: A tip I got from Jeff on a similar problem, try and tell us: BernardhI noted that a memory leak is left on exit of some of my programs if I omit to call CRYPTO_cleanup_all_ex_data() before leaving my DLL or other app built with openSSL. Worse, the leaked volume increases as I execute loops with more calls to e.g. some bio filters. JeffIt gets worse. If you are using Java/JNI or C#/Interop, then the leak accumulates each time the library is loaded/unloaded. Pretty soon, long lived process consume a massive amount of memory that can't be free'd. JeffCompression methods in the SSL library is another offender. Bernardh *From:* owner-openssl-...@openssl.org [mailto: owner-openssl-...@openssl.org] *On Behalf Of *Rajeswari K *Sent:* Tuesday, August 26, 2014 9:36 AM *To:* openssl-dev@openssl.org; openssl-us...@openssl.org *Subject:* Memory hold issue Hello Openssl team, I have a query on the memory hold with openssl handshake. When performed openssl handshake, we are always observing memory hold increase. This hold eventually increases and at last we end up with device having no memory at all. Following is the memory hold tracebacks. First Hold : SSL_SESSION_new(0x3794200)+0x16 ssl_get_new_session(0x3793d88)+0x1e ssl3_get_client_hello(0x378bdf8)+0x1b4 ssl3_accept(0x3789590)+0x32c SSL_accept(0x3791a1c)+0x27 ssl23_get_client_hello(0x3780c12)+0x7f ssl23_accept(0x3780980)+0xe3 ssl23_read(0x3780730)+0x36 SSL_read(0x3791940)+0x3c Second Hold : sk_insert(0x375ffac)+0x52 sk_push(0x376007c)+0x17 ssl_bytes_to_cipher_list(0x3790f42)+0x102 ssl3_get_client_hello(0x378bdf8)+0x270 ssl3_accept(0x3789590)+0x32c SSL_accept(0x3791a1c)+0x27 ssl23_get_client_hello(0x3780c12)+0x7f ssl23_accept(0x3780980)+0xe3 ssl23_read(0x3780730)+0x36 SSL_read(0x3791940)+0x3c Third place : lh_insert(0x3755b3a)+0x83 SSL_CTX_add_session(0x3793914)+0x6c ssl_update_cache(0x379037e)+0x5e ssl3_accept(0x3789590)+0x1c1 ssl3_read_bytes(0x3787798)+0xb7 ssl3_read_internal(0x3786730)+0x65 ssl3_read(0x378689c)+0x1c SSL_read(0x3791940)+0x3c Fourth function : sk_new(). Please let us know whether these memory holds are for session resumption? or someother purpose. Is there any way we can free these memory addresses during SSL_free()? Thanks, Rajeswari.
Memory hold issue
Hello Openssl team, I have a query on the memory hold with openssl handshake. When performed openssl handshake, we are always observing memory hold increase. This hold eventually increases and at last we end up with device having no memory at all. Following is the memory hold tracebacks. First Hold : SSL_SESSION_new(0x3794200)+0x16 ssl_get_new_session(0x3793d88)+0x1e ssl3_get_client_hello(0x378bdf8)+0x1b4 ssl3_accept(0x3789590)+0x32c SSL_accept(0x3791a1c)+0x27 ssl23_get_client_hello(0x3780c12)+0x7f ssl23_accept(0x3780980)+0xe3 ssl23_read(0x3780730)+0x36 SSL_read(0x3791940)+0x3c Second Hold : sk_insert(0x375ffac)+0x52 sk_push(0x376007c)+0x17 ssl_bytes_to_cipher_list(0x3790f42)+0x102 ssl3_get_client_hello(0x378bdf8)+0x270 ssl3_accept(0x3789590)+0x32c SSL_accept(0x3791a1c)+0x27 ssl23_get_client_hello(0x3780c12)+0x7f ssl23_accept(0x3780980)+0xe3 ssl23_read(0x3780730)+0x36 SSL_read(0x3791940)+0x3c Third place : lh_insert(0x3755b3a)+0x83 SSL_CTX_add_session(0x3793914)+0x6c ssl_update_cache(0x379037e)+0x5e ssl3_accept(0x3789590)+0x1c1 ssl3_read_bytes(0x3787798)+0xb7 ssl3_read_internal(0x3786730)+0x65 ssl3_read(0x378689c)+0x1c SSL_read(0x3791940)+0x3c Fourth function : sk_new(). Please let us know whether these memory holds are for session resumption? or someother purpose. Is there any way we can free these memory addresses during SSL_free()? Thanks, Rajeswari.
Re: Memory hold issue
Isn't CRYPTO_cleanup_all_ex_data() frees all ex_data? I hope the issue over here is holding the session information for resumption is my guess. How can we disable session resumption feature inorder not to update the session details and check whether complete memory is freed during SSL_CTX_free() or not? On Tue, Aug 26, 2014 at 1:31 PM, bernard Hauzeur b...@artofe.biz wrote: A tip I got from Jeff on a similar problem, try and tell us: BernardhI noted that a memory leak is left on exit of some of my programs if I omit to call CRYPTO_cleanup_all_ex_data() before leaving my DLL or other app built with openSSL. Worse, the leaked volume increases as I execute loops with more calls to e.g. some bio filters. JeffIt gets worse. If you are using Java/JNI or C#/Interop, then the leak accumulates each time the library is loaded/unloaded. Pretty soon, long lived process consume a massive amount of memory that can't be free'd. JeffCompression methods in the SSL library is another offender. Bernardh *From:* owner-openssl-...@openssl.org [mailto: owner-openssl-...@openssl.org] *On Behalf Of *Rajeswari K *Sent:* Tuesday, August 26, 2014 9:36 AM *To:* openssl-dev@openssl.org; openssl-us...@openssl.org *Subject:* Memory hold issue Hello Openssl team, I have a query on the memory hold with openssl handshake. When performed openssl handshake, we are always observing memory hold increase. This hold eventually increases and at last we end up with device having no memory at all. Following is the memory hold tracebacks. First Hold : SSL_SESSION_new(0x3794200)+0x16 ssl_get_new_session(0x3793d88)+0x1e ssl3_get_client_hello(0x378bdf8)+0x1b4 ssl3_accept(0x3789590)+0x32c SSL_accept(0x3791a1c)+0x27 ssl23_get_client_hello(0x3780c12)+0x7f ssl23_accept(0x3780980)+0xe3 ssl23_read(0x3780730)+0x36 SSL_read(0x3791940)+0x3c Second Hold : sk_insert(0x375ffac)+0x52 sk_push(0x376007c)+0x17 ssl_bytes_to_cipher_list(0x3790f42)+0x102 ssl3_get_client_hello(0x378bdf8)+0x270 ssl3_accept(0x3789590)+0x32c SSL_accept(0x3791a1c)+0x27 ssl23_get_client_hello(0x3780c12)+0x7f ssl23_accept(0x3780980)+0xe3 ssl23_read(0x3780730)+0x36 SSL_read(0x3791940)+0x3c Third place : lh_insert(0x3755b3a)+0x83 SSL_CTX_add_session(0x3793914)+0x6c ssl_update_cache(0x379037e)+0x5e ssl3_accept(0x3789590)+0x1c1 ssl3_read_bytes(0x3787798)+0xb7 ssl3_read_internal(0x3786730)+0x65 ssl3_read(0x378689c)+0x1c SSL_read(0x3791940)+0x3c Fourth function : sk_new(). Please let us know whether these memory holds are for session resumption? or someother purpose. Is there any way we can free these memory addresses during SSL_free()? Thanks, Rajeswari.
Query on non blocking sockets
Hello Team, In our application we open non blocking socket for read and write operation and pass the fd to openssl through BOI API's like this bio = BIO_new(BIO_s_socket()); BIO_set_fd(bio, socket_fd, BIO_NOCLOSE); And we update this bio to SSL using SSL_set_bio() function. My query is do we need to update SSL_CTX with these modes when we use non blocking sockets? SSL_CTX_set_mode(ctx, SSL_MODE_ENABLE_PARTIAL_WRITE); SSL_CTX_set_mode(ctx, SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER); Or without setting this also non blocking sockets work? Please provide your inputs at Earliest. Thanks Regards, Rajeswari.
Renegotiation DOS
Hello Openssl-dev team,
Currently am checking whether Renegotiation is enabled in openssl 0.9.8q
version. If enabled, would like to disable this.
As per release note, i see
*Changes between 0.9.8k and 0.9.8l [5 Nov 2009]*
*) Disable renegotiation completely - this fixes a severe security
problem (CVE-2009-3555) at the cost of breaking all
renegotiation. Renegotiation can be re-enabled by setting
SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s3-flags at
run-time. This is really not recommended unless you know what
you're doing.
[Ben Laurie]
Renegotiation is completely removed from 0.9.8k version onwards.
Currenlty we are using openssl0.9.8q version.
But, when i tried to perform Renegotiation, OPENSSL SERVER is
accepting Renegotiation.
openssl s_client -connect 10.104.105.36:443 -ssl3
CONNECTED(0003)
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 512 bit*Secure Renegotiation IS supported*
SSL-Session:
Protocol : SSLv3
Cipher: DES-CBC3-SHA
Session-ID: 1C9FF53981EDECD2B45E9DB8BD6C776286F1EBA8F8DED95A877081C93B673658
Session-ID-ctx:
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
R
RENEGOTIATING
Renegotiation is successful.
On server side, i printed the values from s3_pkt.c file in this
portion of code :
if (s-server
SSL_is_init_finished(s)
!s-s3-send_connection_binding
(*s-version SSL3_VERSION*)
(s-s3-handshake_fragment_len = 4)
(s-s3-handshake_fragment[0] == SSL3_MT_CLIENT_HELLO)
(s-session != NULL) (s-session-cipher != NULL)
!(s-ctx-options SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION))
{
buginf(\n RENEGOTATION CANT BE DONE \n);
/*s-s3-handshake_fragment_len = 0;*/
rr-length = 0;
ssl3_send_alert(s,SSL3_AL_WARNING, SSL_AD_NO_RENEGOTIATION);
goto start;
}
else
{
buginf(\n Rajeswari entered in to else condition for
client hello. \n
Debugs :
Rajeswari entered in to else condition for client hello.
s-server : 1
SSL_is_init_finished(s) : 1
s-s3-send_connection_binding :1
s-version : 768
SSL3_VERSION : 768
s-s3-handshake_fragment_len : 4
s-s3-handshake_fragment[0] : 1
SSL3_MT_CLIENT_HELLO : 1
s-ctx-options : 404
SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION : 4
I would like to understand does Renegotiation is not disabled for SSL3
Version?
I read something like, for SSL3, RENEGOTIATION should return a failure and
for TLSV1, RENEGOTIATION should return a warning.
Please correct me if am wrong and also please provide your inputs how to
disable RENEGOTIATION for current session.
Thanks Regards,
Rajeswari.
Design change observed at ssl3_get_client_certificate()
Hello Openssl dev team,
Currently we are using openssl 0.9.8q version. Earlier we have used openssl
0.9.8k.
We have seen change in the return value handling of ssl_verify_cert_chain()
at function ssl3_get_client_certificate().
At openssl 0.9.8k, ssl_verify_cert_chain() is handled like this
else {
i=ssl_verify_cert_chain(s,sc-cert_chain); if (i 0)
{ ret = i;
goto err;} else if
(i == 0) {
al=ssl_verify_alarm_type(s-verify_result);
* \*
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err; }
}
But at openssl 0.9.8q, same code is changed as
else
{
i=ssl_verify_cert_chain(s,sk);
if (i = 0)
{
al=ssl_verify_alarm_type(s-verify_result);
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err;
}
}
Currently we have registered with our callback functions to perform
verification of certificates. In our code, we return negative values
if CRL fetch//certificate verifitication is in progress. Due to this,
current openssl0.9.8q, is treating the negative values as error and
sending an alert and clearing its session.
Same code worked with openssl0.9.8k because OPENSSL is not treating
negative value as error.
Is there any way we can get out of this situation with openssl0.9.8q?
Thanks Regards,
Rajeswari.
Re: Design change observed at ssl3_get_client_certificate()
Sorry team. Change observed between openssl 0.9.8g to openssl0.9.8k
Can you please tell us the intent of this change and how we can get out of
this problem.
Regards,
Rajeswari
On Thu, Sep 26, 2013 at 3:18 PM, Rajeswari K raji.kotamr...@gmail.comwrote:
Hello Openssl dev team,
Currently we are using openssl 0.9.8q version. Earlier we have used
openssl 0.9.8k.
We have seen change in the return value handling of
ssl_verify_cert_chain() at function ssl3_get_client_certificate().
At openssl 0.9.8k, ssl_verify_cert_chain() is handled like this
else {
i=ssl_verify_cert_chain(s,sc-cert_chain); if (i 0)
{ ret = i;
goto err;} else if (i == 0)
{
al=ssl_verify_alarm_type(s-verify_result);
* \*
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err; } }
But at openssl 0.9.8q, same code is changed as
else
{
i=ssl_verify_cert_chain(s,sk);
if (i = 0)
{
al=ssl_verify_alarm_type(s-verify_result);
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err;
}
}
Currently we have registered with our callback functions to perform
verification of certificates. In our code, we return negative values if CRL
fetch//certificate verifitication is in progress. Due to this, current
openssl0.9.8q, is treating the negative values as error and sending an alert
and clearing its session.
Same code worked with openssl0.9.8k because OPENSSL is not treating negative
value as error.
Is there any way we can get out of this situation with openssl0.9.8q?
Thanks Regards,
Rajeswari.
RENEGOTIATION DOS
Hello Openssl Team, I would like to understand how Renegotation DOS impacts our current TLS session and its issues. How we can avoid Renegotation initialized by client during the TLS/SSL session at openssl0.9.8q version. Please provide documents if any describes about Renegotiation DOS. And also i would like to understand how Renegotation on same TLS session impacts TLS Server performance and how it wont impact if server starts Renegotation in its fresh TLS/SSL handshake. Regards, Rajeswari.
Reason for design change of ssl3_get_client_certificate()
Hello Openssl dev team,
Currently we are using openssl 0.9.8q version. Earlier we have used openssl
0.9.8k.
We have seen change in the return value handling of ssl_verify_cert_chain()
at function ssl3_get_client_certificate().
At openssl 0.9.8k, ssl_verify_cert_chain() is handled like this
else {
i=ssl_verify_cert_chain(s,sc-cert_chain); if (i 0)
{ ret = i;
goto err;} else if
(i == 0) {
al=ssl_verify_alarm_type(s-verify_result);
* \*
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err; }
}
But at openssl 0.9.8q, same code is changed as
else
{
i=ssl_verify_cert_chain(s,sk);
if (i = 0)
{
al=ssl_verify_alarm_type(s-verify_result);
SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
goto f_err;
}
}
Is there any reason behind this change?
Currently we have registered with our callback functions to perform
verification of certificates. In our code, we return negative values
if CRL fetch//certificate verifitication is in progress. Due to this,
current openssl0.9.8q, is treating the negative values as error and
sending an alert and clearing its session.
Same code worked with openssl0.9.8k because OPENSSL is not treating
negative value as error.
Is there any way we can get out of this situation with openssl0.9.8q?
Thanks Regards,
Rajeswari.
Crash observed
Hello Openssl team,
Does any of you faced an issue while freeing the SSL_CTX?
Following is the backtrace found. But we are not yet sure which address is
being passed to SSL_CTX_free(). We are trying to get the crashinfo file and
trying to debug.
Meanwhile, if any of you faced similar issue please provide how you guys
have solved it.
Currently we are using openssl0.9.8q version. Does this version has any
problem in this area and any upgraded version fixed these issues? Please
let us know.
Your help is highly required.
% 0x3b197ea : __be_SSL_CTX_free + 202 (self)
1645 void SSL_CTX_free(SSL_CTX *a)
1646 {
1687 sk_SSL_CIPHER_free(a-cipher_list);
1688 if (a-cipher_list_by_id != NULL)
---
% 0x3adf8e0 : __be_sk_free + 48 (self)
303 void sk_free(STACK *st)
304 {
305 if (st == NULL) return;
306 if (st-data != NULL) OPENSSL_free(st-data);
307 OPENSSL_free(st);
308 }
309
--
-
% 0x3ad4368 : __be_CRYPTO_free + 56 (self)
404 void CRYPTO_free(void *str)
405 {
406 if (free_debug_func != NULL)
407 free_debug_func(str, 0);
408 #ifdef LEVITTE_DEBUG_MEM
409 fprintf(stderr, LEVITTE_DEBUG_MEM: 0x%p\n, str);
410 #endif
411 free_func(str); should be crashing here
412 if (free_debug_func != NULL)
413 free_debug_func(NULL, 1);
414 }
static void (*free_func)(void *) = free;
Smart card support with Openssl
Hello Users/dev Team, Need some urgent help to program openssl for smart card/HSM. Our smart card never shares private keys. All crypto operations such as encryption,decryption will be performed by smart card. And any such actions from openssl needs to be redirected to smart card. Only certicate is left open. Have read about pkcs11 crypto engine support at openssl. Currently we are using openssl 0.9.8q. Does this version supports pkcs11 engine support? If supports, can you provide which part of the code needs to be changed to have successful handshake using smart card. Currently our openssl code is expecting a private key to perform handshake. When smart card is used, private_key is updated with NULL at SSL_ACCEPT(). Hence, its throwing as no shard cipher during handshake. Please provide a sample application how to program openssl for smart card where private key is not known. Thanks in advance. Rajeswari.
Fwd: Key usage at openssl
Hello openssl team, We have two different keypairs such as signature keypair and encryption keypair on our device. Hence, two different certificates (signature and encryption) were issued by CA server. Query : To perform openssl handshake, which key do we need to read? Is it Encryption private key and corresponding encryption key's certificate or Signature private key and corresponding signature key's certificate? Have performed test to read encryption key and corresponding certificate. - Handshake succeeded. Have performed test to read signature key and corresponding certificate. - Handshake succeeded. Now, need to take a decision which key takes more precedence. Based on this need to change the design. Please provide your valuable inputs. Thanks Regards, Rajeswari.
Fwd: Openssl-0.9.8q
Forwarding to dev team as well -- Forwarded message -- From: Rajeswari K raji.kotamr...@gmail.com Date: Thu, Feb 14, 2013 at 4:58 PM Subject: Openssl-0.9.8q To: openssl-us...@openssl.org Hello Team, Our project uses openssl to perform ssl handshake and uses hardware crypto engine to encrypt and decrypt. Once we receive first Encrypted message in ssl handshake (i.e FINISHED message), we forward it to hardware crypto engine to decrypt. When used* openssl0.9.8g* version, and tried to connect from browser handshake was successful and hardware crypto engine successfully decrypted the FINISHED message. When ported with *OPENSSL0.9.8q* version, and tried to connect from browser handshake is not successful and hardware crypto engine is returning an error. After contacting hardware crypto engine team for the reason for failure, they responded that AUTH key used at openssl for the MAC calculation is incorrect/wrong. Observations : 1) TLS1.0 SSL3.0 handshakes were successful with OPENSSL0.9.8g 2) SSL3.0 handshake with OPENSSL0.9.8q is successful 3) *TLS1.0* handshake with *OPENSSL0.9.8q is failed*. Please provide some pointers if anyone come across similar kind of situation. Thanks in advance, Rajeswari.
