Re: [openssl-dev] Renegotiation ticket 3712
Matt, I was under impression that issue would have been addressed in latest openssl version 1.1.0. In case of high traffic and high secure networks, one of the best way to validate the long-lived connection is to do renegotiation (unless negotiated protocol is TLS 1.3 still in draft phase). Since the traffic cannot be stopped and as mentioned in the RFC the app data and renegotiation can be interleaved there is a good chance that openssl would encounter app data instead of handshake message. This makes openssl to throw unexpected record error for which the application has to take an action (mostly closing the connection due to an error encountered) , thus leading to traffic disruption. The issue is fairly time sensitive and leads to non-deterministic outcome. Hence I was expecting the issue to be addressed with openssl version 1.1.0 due to major overhaul of state machine and internals. Thanks Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Monday, April 03, 2017 3:59 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Renegotiation ticket 3712 On 03/04/17 11:24, Mody, Darshan (Darshan) wrote: > Thanks Matt, > > Just another query. Is the issue addressed in the latest openssl 1.1.0? My answer was for 1.1.0 (as was your original question)? In any case it is not addressed in any OpenSSL version. Matt > > Regards > Darshan > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf > Of Matt Caswell > Sent: Monday, April 03, 2017 2:53 PM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Renegotiation ticket 3712 > > > > On 02/04/17 04:50, Mody, Darshan (Darshan) wrote: >> Hi Matt, >> >> Is re-negotiation fixed with openssl 1.1.0 ? >> https://urldefense.proofpoint.com/v2/url?u=https-3A__rt.openssl.org_T >> i >> cket_Display.html-3Fid-3D3712-26user-3Dguest-26pass-3Dguesthttps-3A__ >> r >> t.openssl.org_Ticket_Display.html-3Fid-3D3712-26user-3Dguest-26pass-3 >> D >> guest=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXz >> a >> IDagy9EuEhJrKfQ=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng=Ni8yD >> 4 vI9arECJEB4AvTHTPslAIBDOyQYItrnXI8Ho8= >> >> From the ticket it seems its marked resolved but your patch is not in >> the openssl base due to possible vulnerabilities. > > No, this issue is not fixed. It would require a major overhaul to properly > fix it, and I don't think it is considered worth it for this issue. > > Matt > -- > openssl-dev mailing list > To unsubscribe: > https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m > ailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEU > LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=0_oGDu1Nd351FfLBQxFRBsvQxamu > cuAh4kuC9XC9rng=u1jQpWruXjaddyFVQW6x3TnRYA3CsHe1XzBwNlHn3p0= > -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=5fscKGrpSiVuD-o67_AL7je6ixVNP8R_ABJUSL0DuPc=KRpeak_T_gjRwyOpNMqprUNfS_1ay9lISTgdkYdm28Y= -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Renegotiation ticket 3712
Thanks Matt, Just another query. Is the issue addressed in the latest openssl 1.1.0? Regards Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Monday, April 03, 2017 2:53 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Renegotiation ticket 3712 On 02/04/17 04:50, Mody, Darshan (Darshan) wrote: > Hi Matt, > > Is re-negotiation fixed with openssl 1.1.0 ? > https://urldefense.proofpoint.com/v2/url?u=https-3A__rt.openssl.org_Ti > cket_Display.html-3Fid-3D3712-26user-3Dguest-26pass-3Dguesthttps-3A__r > t.openssl.org_Ticket_Display.html-3Fid-3D3712-26user-3Dguest-26pass-3D > guest=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXza > IDagy9EuEhJrKfQ=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng=Ni8yD4 > vI9arECJEB4AvTHTPslAIBDOyQYItrnXI8Ho8= > > From the ticket it seems its marked resolved but your patch is not in > the openssl base due to possible vulnerabilities. No, this issue is not fixed. It would require a major overhaul to properly fix it, and I don't think it is considered worth it for this issue. Matt -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng=u1jQpWruXjaddyFVQW6x3TnRYA3CsHe1XzBwNlHn3p0= -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Memory leak in application when we use ECDH
Matt, We have set SSL_CTX_set_session_cache_mode(ctx, /*SSL_SESS_CACHE_SERVER */ SSL_SESS_CACHE_OFF); Do you observe the same behavior with s_server app when we have cache mode set as SSL_SES_CACHE_OFF? Thanks Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Monday, March 27, 2017 3:04 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH Hi Darshan The behaviour you are seeing is not particularly surprising and does not indicate a memory leak. s_server maintains a cache of sessions from previous connections to enable the resumption capability. Since your s_client loop isn't resuming it creates a new session every time (which contains the client certificate), so I would expect the memory to grow. To confirm there are no leaks I ran s_server through valgrind and ran your s_client loop. I actually *did* find a minor leak - but it does not grow over time and is constant no matter how many connections are made. It only affects the command line apps and is also quite small (64 bytes on my machine). Fix here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3040=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=coIwPvyWw4plXoF_ThJsi4JLRt34Sy9UvhnGuHBjYEU=VTPuVxG9-V4MA6C5eMla9AZ1hS3cGGFkl6PN3R0bAyA= This only impacts 1.0.2. It doesn't seem to be a problem in 1.1.0 (probably because of the new auto-deinit capability). Once the above patch was applied running s_server through valgrind with your s_client loop gives me: CONNECTION CLOSED 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 71 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 70 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) ==15312== ==15312== HEAP SUMMARY: ==15312== in use at exit: 0 bytes in 0 blocks ==15312== total heap usage: 230,141 allocs, 230,141 frees, 19,200,644 bytes allocated ==15312== ==15312== All heap blocks were freed -- no leaks are possible ==15312== ==15312== For counts of detected and suppressed errors, rerun with: -v ==15312== Use --track-origins=yes to see where uninitialised values come from ==15312== ERROR SUMMARY: 91846 errors from 1000 contexts (suppressed: 0 from 0) Matt On 27/03/17 09:40, Mody, Darshan (Darshan) wrote: > Matt, Richard, > > I have not created any patch. Instead I am using s_server app provided > from Openssl. Below is the server side command run > > openssl s_server -accept -key -cert > -CAfile CA> -verify > > On the client side I am running script below > > #/bin/sh > > while [ 1 ] > do > openssl s_client -connect : -cert client certificate not trusted by server> -key certificate key> &>/dev/null done > > Running the client once and printing the results showed the cipher selected > was ECDHE cipher. I believe there is inherent leak in the ECDHE side of > openssl. > > I find that the server started leaking was leaking. Check the Resident memory > and the CPU. Resident memory increases after every 3 second. When I had > stopped the client traffic the resident memory did not increase however it > did not returned back to what it was earlier. Hope this will help to > reproduce the issue. > > top - 10:16:37 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.6%us, 0.1%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 3924288k total, 3757716k used, 166572k free,78200k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219736k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 39908 3528 2740 S 0.0 0.1 0:00.00 openssl > > > top - 10:16:40 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > Cpu(s): 1.6%us, 0.9%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st > Mem: 3924288k total, 3757856k used, 166432k free,78208k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 39908 3532 2740 R 4.3 0.1 0:00.13 openssl > > > top - 10:16:43 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.6%us, 0.8%sy, 0.1%ni, 96.2%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st &
Re: [openssl-dev] Memory leak in application when we use ECDH
0.2 0:42.92 openssl top - 10:23:22 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 11.1%us, 4.6%sy, 20.2%ni, 63.6%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st Mem: 3924288k total, 3756924k used, 167364k free,75952k buffers Swap: 8388604k total, 998972k used, 7389632k free, 216600k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 27303 root 20 0 42500 6124 2740 S 10.3 0.2 0:43.23 openssl Thanks Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody, Darshan (Darshan) Sent: Thursday, March 23, 2017 7:40 PM To: openssl-dev@openssl.org Cc: Bahr, William G (Bill) Subject: Re: [openssl-dev] Memory leak in application when we use ECDH Thanks Richard and Matt, I will patch it and send the patch. It will take me couple of days. Regards Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard Levitte Sent: Thursday, March 23, 2017 7:31 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH I think that Matt is asking for example code that exhibits this leak. You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch. The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. Cheers, Richard In message <25d2ec755404b4409f263ac6d050febb2a107...@az-ffexmb03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +, "Mody, Darshan (Darshan)" <darshanm...@avaya.com> said: darshanmody> Matt, darshanmody> darshanmody> Below is the scenario. darshanmody> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. darshanmody> 3. Connect client with certificates that server does not trust. darshanmody> 4. The connections from client to server fails darshanmody> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. darshanmody> darshanmody> Hope this helps darshanmody> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -Original Message- darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] darshanmody> On Behalf Of Matt Caswell darshanmody> Sent: Thursday, March 23, 2017 6:55 PM darshanmody> To: openssl-dev@openssl.org darshanmody> Subject: Re: [openssl-dev] Memory leak in application when darshanmody> we use ECDH darshanmody> darshanmody> darshanmody> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: darshanmody> > Can you further elaborate? darshanmody> > darshanmody> > What we did is to create a TLS connection and with darshanmody> > invalid certificates from the client and server on darshanmody> > verification would reject the certificate. The cipher darshanmody> > negotiated was ECDHE cipher between client and server. darshanmody> > darshanmody> > This was done with load (multiple while 1 script trying darshanmody> > to connect to server using invalid certificates and in darshanmody> > course of time the memory was increasing). darshanmody> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. darshanmody> darshanmody> Matt darshanmody> darshanmody> darshanmody> > darshanmody> > Thanks Darshan darshanmody> > darshanmody> > -Original Message- From: openssl-dev darshanmody> > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of darshanmody> > Matt Caswell darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: darshanmody> > openssl-dev@openssl.org darshanmody> > Subject: Re: [openssl-dev] Memory leak in application darshanmody> > when we use ECDH darshanmody> > darshanmody> > darshanmody> > darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: darshanmody> >> Matt, darshanmody> >> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. darshanmody> >> The leak started a
Re: [openssl-dev] Memory leak in application when we use ECDH
Thanks Richard and Matt, I will patch it and send the patch. It will take me couple of days. Regards Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard Levitte Sent: Thursday, March 23, 2017 7:31 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH I think that Matt is asking for example code that exhibits this leak. You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch. The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. Cheers, Richard In message <25d2ec755404b4409f263ac6d050febb2a107...@az-ffexmb03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" <darshanm...@avaya.com> said: darshanmody> Matt, darshanmody> darshanmody> Below is the scenario. darshanmody> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. darshanmody> 3. Connect client with certificates that server does not trust. darshanmody> 4. The connections from client to server fails darshanmody> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. darshanmody> darshanmody> Hope this helps darshanmody> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -Original Message- darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] darshanmody> On Behalf Of Matt Caswell darshanmody> Sent: Thursday, March 23, 2017 6:55 PM darshanmody> To: openssl-dev@openssl.org darshanmody> Subject: Re: [openssl-dev] Memory leak in application when darshanmody> we use ECDH darshanmody> darshanmody> darshanmody> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: darshanmody> > Can you further elaborate? darshanmody> > darshanmody> > What we did is to create a TLS connection and with darshanmody> > invalid certificates from the client and server on darshanmody> > verification would reject the certificate. The cipher darshanmody> > negotiated was ECDHE cipher between client and server. darshanmody> > darshanmody> > This was done with load (multiple while 1 script trying darshanmody> > to connect to server using invalid certificates and in darshanmody> > course of time the memory was increasing). darshanmody> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. darshanmody> darshanmody> Matt darshanmody> darshanmody> darshanmody> > darshanmody> > Thanks Darshan darshanmody> > darshanmody> > -Original Message- From: openssl-dev darshanmody> > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of darshanmody> > Matt Caswell darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: darshanmody> > openssl-dev@openssl.org darshanmody> > Subject: Re: [openssl-dev] Memory leak in application darshanmody> > when we use ECDH darshanmody> > darshanmody> > darshanmody> > darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: darshanmody> >> Matt, darshanmody> >> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. darshanmody> >> The leak started after we started using supporting EC darshanmody> >> with callback SSL_set_tmp_ecdh_callback(). darshanmody> >> darshanmody> >> The core dump shows the string data of the far-end certificates. darshanmody> >> I cannot pin point the code in openssl with this regard. darshanmody> > darshanmody> > Are you able to create a simple reproducer demonstrating darshanmody> > the problem with the callback? darshanmody> > darshanmody> > Matt darshanmody> > darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8 darshanmody> bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEb
Re: [openssl-dev] Memory leak in application when we use ECDH
Matt, Below is the scenario. 1. Have server open a listen socket which always validates the client certificate and chain. 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. 3. Connect client with certificates that server does not trust. 4. The connections from client to server fails In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. Hope this helps Thanks Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Thursday, March 23, 2017 6:55 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: > Can you further elaborate? > > What we did is to create a TLS connection and with invalid > certificates from the client and server on verification would reject > the certificate. The cipher negotiated was ECDHE cipher between client > and server. > > This was done with load (multiple while 1 script trying to connect to > server using invalid certificates and in course of time the memory was > increasing). Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. Matt > > Thanks Darshan > > -Original Message- From: openssl-dev > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell > Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > > > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: >> Matt, >> >> Even after accounting for the EC_KEY we still observe some leak. >> The leak started after we started using supporting EC with >> callback SSL_set_tmp_ecdh_callback(). >> >> The core dump shows the string data of the far-end certificates. >> I cannot pin point the code in openssl with this regard. > > Are you able to create a simple reproducer demonstrating the problem > with the callback? > > Matt > -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ= -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Memory leak in application when we use ECDH
Can you further elaborate? What we did is to create a TLS connection and with invalid certificates from the client and server on verification would reject the certificate. The cipher negotiated was ECDHE cipher between client and server. This was done with load (multiple while 1 script trying to connect to server using invalid certificates and in course of time the memory was increasing). Thanks Darshan -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: > Matt, > > Even after accounting for the EC_KEY we still observe some leak. The > leak started after we started using supporting EC with callback > SSL_set_tmp_ecdh_callback(). > > The core dump shows the string data of the far-end certificates. I > cannot pin point the code in openssl with this regard. Are you able to create a simple reproducer demonstrating the problem with the callback? Matt -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=bLfMhjtc7o6YlbbKPhSGSKPuhTJsYubiC_LV17YO3do=CIdcV48IKxBzbTWaEpB4zcKDD76FwUj3wuMFrxa50UY= -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Memory leak in application when we use ECDH
Matt,
Even after accounting for the EC_KEY we still observe some leak. The leak
started after we started using supporting EC with callback
SSL_set_tmp_ecdh_callback().
The core dump shows the string data of the far-end certificates. I cannot pin
point the code in openssl with this regard.
Thanks
Darshan
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt
Caswell
Sent: Thursday, March 23, 2017 3:31 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
>
> But openssl does not release the memory when it has duplicated the EC
> Key which comes from the application
You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so there is no
"official" description of the memory management semantics of this function (and
like I said it has been removed from later versions of OpenSSL altogether so it
is unlikely to ever get documented). However my interpretation of the way the
code is written is that this is a deliberate design choice, i.e. it is
deliberately left to the the application to mange this memory. Presumably
multiple invocations across multiple connections could return the same value so
it would be inappropriate for OpenSSL to free it.
Matt
>
>/* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> if (s->cert->ecdh_tmp_auto)
> ecdh = ecdhp;
> else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
>
> Thanks
> Darshan
>
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf
> Of Matt Caswell
> Sent: Tuesday, March 21, 2017 3:28 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
>
>
> On 21/03/17 09:46, Matt Caswell wrote:
>>
>> There is a potential leak in this case:
>>
>> if (s->s3->tmp.ecdh != NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>ERR_R_INTERNAL_ERROR);
>> goto err;
>> }
>>
>> But this is a "should not happen" scenario - so there is another bug
>> if that is happening - and you would see "internal error" messages on
>> the error stack.
>>
>> Another slight oddity in this code is the double check of ecdhp
>> against NULL which seems redundant (but otherwise harmless):
>>
>> if (ecdhp == NULL) {
>> al = SSL_AD_HANDSHAKE_FAILURE;
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>SSL_R_MISSING_TMP_ECDH_KEY);
>> goto f_err;
>> }
>>
>> ...
>>
>> /* Duplicate the ECDH structure. */
>> if (ecdhp == NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>> goto err;
>> }
>
> Fix for the above issues (which is unlikely to solve your problem) is here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openss
> l_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7I
> nzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuk
> i2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
>
> Matt
>
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m
> ailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEU
> LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi
> -yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
>
--
openssl-dev mailing list
To unsubscribe:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=jvDI18EtBUGVhF0dlpzP1E0w75ZPjyBprI47vr1-QlA=QwfWOZbsFqgCiO23c3Z6HmnkCgfsT94LaHQSoaQLIFM=
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Memory leak in application when we use ECDH
Should not openssl release memory from app.
Some like below
/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else {
if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
else {
/* Release memory from cb */
If (NULL !=ecdhp) {
EC_KEY_free(ecdhp);
}
}
}
Thanks
Darshan
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody,
Darshan (Darshan)
Sent: Thursday, March 23, 2017 10:06 AM
To: openssl-dev@openssl.org
Cc: Bahr, William G (Bill)
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
Matt,
But openssl does not release the memory when it has duplicated the EC Key which
comes from the application
/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
Thanks
Darshan
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt
Caswell
Sent: Tuesday, March 21, 2017 3:28 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
On 21/03/17 09:46, Matt Caswell wrote:
>
> There is a potential leak in this case:
>
> if (s->s3->tmp.ecdh != NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>ERR_R_INTERNAL_ERROR);
> goto err;
> }
>
> But this is a "should not happen" scenario - so there is another bug
> if that is happening - and you would see "internal error" messages on
> the error stack.
>
> Another slight oddity in this code is the double check of ecdhp
> against NULL which seems redundant (but otherwise harmless):
>
> if (ecdhp == NULL) {
> al = SSL_AD_HANDSHAKE_FAILURE;
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>SSL_R_MISSING_TMP_ECDH_KEY);
> goto f_err;
> }
>
> ...
>
> /* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
Fix for the above issues (which is unlikely to solve your problem) is here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
Matt
--
openssl-dev mailing list
To unsubscribe:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
--
openssl-dev mailing list
To unsubscribe:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=ItYO5obXpUhcVAqtr-HAnmatrYOEJ-EpjZhn-eCTsyg=EYfD8Wpi4Eji8E2PwNF9obPY-g4EXP5FXF1AzbJtMGU=
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Memory leak in application when we use ECDH
Matt,
But openssl does not release the memory when it has duplicated the EC Key which
comes from the application
/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
Thanks
Darshan
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt
Caswell
Sent: Tuesday, March 21, 2017 3:28 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
On 21/03/17 09:46, Matt Caswell wrote:
>
> There is a potential leak in this case:
>
> if (s->s3->tmp.ecdh != NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>ERR_R_INTERNAL_ERROR);
> goto err;
> }
>
> But this is a "should not happen" scenario - so there is another bug
> if that is happening - and you would see "internal error" messages on
> the error stack.
>
> Another slight oddity in this code is the double check of ecdhp
> against NULL which seems redundant (but otherwise harmless):
>
> if (ecdhp == NULL) {
> al = SSL_AD_HANDSHAKE_FAILURE;
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>SSL_R_MISSING_TMP_ECDH_KEY);
> goto f_err;
> }
>
> ...
>
> /* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
Fix for the above issues (which is unlikely to solve your problem) is here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
Matt
--
openssl-dev mailing list
To unsubscribe:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Memory leak in application when we use ECDH
Hi,
Can anyone in the developer forum clarify whether there is an issue here?
Thanks
Darshan
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody,
Darshan (Darshan)
Sent: Wednesday, March 15, 2017 11:15 AM
To: openssl-dev@openssl.org
Cc: Bahr, William G (Bill); Vaquero, Alejandro (Alejandro)
Subject: [openssl-dev] Memory leak in application when we use ECDH
Hi,
We have observed memory leak when we register for ECDH
callback(SSL_set_tmp_ecdh_callback). While performing negative testing with
load we find that the applications starts leaking memory.
Further checking the Openssl implementation in the s3_srvr.c file (openssl
version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from
the application or EC_KEY_new being called.
I suspect the below code.
if (type & SSL_kEECDH) {
const EC_GROUP *group;
ecdhp = cert->ecdh_tmp;
if (s->cert->ecdh_tmp_auto) {
/* Get NID of appropriate shared curve */
int nid = tls1_shared_curve(s, -2);
if (nid != NID_undef)
ecdhp = EC_KEY_new_by_curve_name(nid); <-- Even memory
allocated in this case is not de-allocated.
} else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) {
ecdhp = s->cert->ecdh_tmp_cb(s,
<-- Application is responsible for the EC_KEY and its
memory
SSL_C_IS_EXPORT(s->s3->
tmp.new_cipher),
SSL_C_EXPORT_PKEYLENGTH(s->
s3->tmp.new_cipher));
}
if (ecdhp == NULL) {
al = SSL_AD_HANDSHAKE_FAILURE;
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
SSL_R_MISSING_TMP_ECDH_KEY);
goto f_err;
}
if (s->s3->tmp.ecdh != NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
ERR_R_INTERNAL_ERROR);
goto err;
}
/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
<-- Once the key is duplicated the memory for the
application should be released?
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
s->s3->tmp.ecdh = ecdh;
if ((EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL) ||
(s->options & SSL_OP_SINGLE_ECDH_USE)) {
if (!EC_KEY_generate_key(ecdh)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
ERR_R_ECDH_LIB);
goto err;
}
}
if (((group = EC_KEY_get0_group(ecdh)) == NULL) ||
(EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&
(EC_GROUP_get_degree(group) > 163)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER);
goto err;
}
/*
* XXX: For now, we only support ephemeral ECDH keys over named
* (not generic) curves. For supported named curves, curve_id is
* non-zero.
*/
if ((curve_id =
tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group)))
== 0) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
SSL_R_UNSUPPORTED_ELLIPTIC_CURVE);
goto err;
}
/*
* Encode the public key. First check the size of encoding and
* allocate memory accordingly.
*/
encodedlen = EC_POINT_point2oct(group,
EC_KEY_get0_public_key(ecdh),
POINT_CONVERSION_UNCOMPRESSED,
NULL, 0, NULL);
encodedPoint = (unsigned char *)
OPENSSL_malloc(encodedlen * sizeof(unsigned char));
bn_ctx = BN_CTX_new();
if ((encoded
[openssl-dev] Memory leak in application when we use ECDH
Hi,
We have observed memory leak when we register for ECDH
callback(SSL_set_tmp_ecdh_callback). While performing negative testing with
load we find that the applications starts leaking memory.
Further checking the Openssl implementation in the s3_srvr.c file (openssl
version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from
the application or EC_KEY_new being called.
I suspect the below code.
if (type & SSL_kEECDH) {
const EC_GROUP *group;
ecdhp = cert->ecdh_tmp;
if (s->cert->ecdh_tmp_auto) {
/* Get NID of appropriate shared curve */
int nid = tls1_shared_curve(s, -2);
if (nid != NID_undef)
ecdhp = EC_KEY_new_by_curve_name(nid); <-- Even memory
allocated in this case is not de-allocated.
} else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) {
ecdhp = s->cert->ecdh_tmp_cb(s,
<-- Application is responsible for the EC_KEY and its
memory
SSL_C_IS_EXPORT(s->s3->
tmp.new_cipher),
SSL_C_EXPORT_PKEYLENGTH(s->
s3->tmp.new_cipher));
}
if (ecdhp == NULL) {
al = SSL_AD_HANDSHAKE_FAILURE;
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
SSL_R_MISSING_TMP_ECDH_KEY);
goto f_err;
}
if (s->s3->tmp.ecdh != NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
ERR_R_INTERNAL_ERROR);
goto err;
}
/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
<-- Once the key is duplicated the memory for the
application should be released?
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
s->s3->tmp.ecdh = ecdh;
if ((EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL) ||
(s->options & SSL_OP_SINGLE_ECDH_USE)) {
if (!EC_KEY_generate_key(ecdh)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
ERR_R_ECDH_LIB);
goto err;
}
}
if (((group = EC_KEY_get0_group(ecdh)) == NULL) ||
(EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&
(EC_GROUP_get_degree(group) > 163)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER);
goto err;
}
/*
* XXX: For now, we only support ephemeral ECDH keys over named
* (not generic) curves. For supported named curves, curve_id is
* non-zero.
*/
if ((curve_id =
tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group)))
== 0) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
SSL_R_UNSUPPORTED_ELLIPTIC_CURVE);
goto err;
}
/*
* Encode the public key. First check the size of encoding and
* allocate memory accordingly.
*/
encodedlen = EC_POINT_point2oct(group,
EC_KEY_get0_public_key(ecdh),
POINT_CONVERSION_UNCOMPRESSED,
NULL, 0, NULL);
encodedPoint = (unsigned char *)
OPENSSL_malloc(encodedlen * sizeof(unsigned char));
bn_ctx = BN_CTX_new();
if ((encodedPoint == NULL) || (bn_ctx == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
ERR_R_MALLOC_FAILURE);
goto err;
}
encodedlen = EC_POINT_point2oct(group,
EC_KEY_get0_public_key(ecdh),
POINT_CONVERSION_UNCOMPRESSED,
encodedPoint, encodedlen, bn_ctx);
if (encodedlen == 0) {
[openssl-dev] CRL implementation caching
Hi, We have modified our codebase to have CRL verification on the incoming certificates. While doing a negative testing with load of certificates I find that the resident memory for the module. My query is when we have CRL verification enabled does openssl caches incoming certificates? Please note that we have set SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); >From the core file generated I am observing many entries of the far-end >certificate serial number. Thanks in Advance Regards Darshan -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Difference between re-negotiate APIs
Hi I find there are 2 APIs for SSL renegotiation. SSL_renegotiate and SSL_renegotiate_abbreviate. What is the difference between them? Thanks Darshan -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Null Ciphers in FIPS mode
Hi, Does Openssl allows NULL ciphers when we put openssl in FIPS mode? Thanks Darshan -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FIPs mode and openssl
Thanks Steve, My question here is do I need to put openssl in FIPS mode for my application, even when Kernel is in FIPS mode. I get FIPS_mode() returning true when I initialize openssl from my application. Regards Darshan From: openssl-dev [openssl-dev-boun...@openssl.org] on behalf of Steve Marquess [marqu...@openssl.com] Sent: Friday, May 27, 2016 2:58 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] FIPs mode and openssl On 05/27/2016 05:11 AM, Mody, Darshan (Darshan) wrote: > Hi, > > > > I have a query with regards to FIPS mode and use of Openssl. I have put > my kernel image n FIPs mode using the documentation > (https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2DUS_Red-5FHat-5FEnterprise-5FLinux_6_html_Security-5FGuide_sect-2DSecurity-5FGuide-2DFederal-5FStandards-5FAnd-5FRegulations-2DFederal-5FInformation-5FProcessing-5FStandard.html=CwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc=-Gf_V2cek9XebA8eKWhFeL2hXCtHLqwJauOD0IuopLU= > ) > > > > Do I need to put the openssl in FIPs mode using the API FIPS_mode_set(1) > or will by default the openssl will put itself in FIPS mode for my > application. There are couple of application on the server we use > openssl. Do I need to put each of the application openssl in FIPS mode > or will it put itself in FIPS since the kernel is in FIPS mode. > > > > Thanks > > Darshan > > > You are using the Red Hat FIPS module, not the OpenSSL one, so you'll need to ask that vendor. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.com_docs_0x6D1892F5.asc=CwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc=pvfmLNV5wFtbE8TvbGtpQdBRmzZzuuCQF0UgxmaZW34= -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=CwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc=XQfgkJcZEf0I-0-rMIEw2wp4U7mgrCk8EPGFlSM461U= -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] FIPs mode and openssl
Hi, I have a query with regards to FIPS mode and use of Openssl. I have put my kernel image n FIPs mode using the documentation (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html) Do I need to put the openssl in FIPs mode using the API FIPS_mode_set(1) or will by default the openssl will put itself in FIPS mode for my application. There are couple of application on the server we use openssl. Do I need to put each of the application openssl in FIPS mode or will it put itself in FIPS since the kernel is in FIPS mode. Thanks Darshan -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Openssl IPv6 Support
Hi, Does Openssl support IPv6 officially?. Thanks Regards Darshan
RE: Improving unit/automated test coverage
Hi Mike, I would like to volunteer for the same. I can spare some time on the weekends for it. Please do note that even I am new to openssl and it would be good to get to know more on the code by doing unit test. Thanks Darshan -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Matt Caswell Sent: Monday, June 02, 2014 8:23 PM To: openssl-dev@openssl.org Subject: Re: Improving unit/automated test coverage On 2 June 2014 15:38, Mike Bland mbl...@acm.org wrote: My goal would be to help everyone learn to fish, to use the tired cliché. I currently have very little knowledge of the OpenSSL code base or community, and I don't have a ton of time to do all the heavy lifting by myself; nor do I think that being the lone testing guy would be the best use of my time or in the best interests of OpenSSL. However, I want to contribute however I can to help the community as a whole address this one particular issue, and to maximize the impact of my contributions. Happy to hear people's thoughts on this. If the uptake is positive, I can help organize the effort to get things moving soon. I think that this is an exciting and important initiative. I would love to see a much stronger test suite for OpenSSL. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
