From darshanmody at avaya.com Sun Apr 2 03:50:38 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Sun, 2 Apr 2017 03:50:38 +0000 Subject: [openssl-dev] Renegotiation ticket 3712 Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A10C98F@AZ-FFEXMB03.global.avaya.com> Hi Matt, Is re-negotiation fixed with openssl 1.1.0 ? https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guesthttps://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest >From the ticket it seems its marked resolved but your patch is not in the openssl base due to possible vulnerabilities. Thanks Darshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Apr 3 09:09:51 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 3 Apr 2017 10:09:51 +0100 Subject: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing In-Reply-To: References: Message-ID: On 31/03/17 18:54, Raja ashok wrote: > Hi All, > > > > In ssl3_write_bytes, if (len < tot) we are returning failure with > SSL_R_BAD_LENGTH error. In this place I hope we should set ?tot? back to > ?s->s3->wnum?. Otherwise when application calls back SSL_write with > correct buffer, it causes serious problem (?tot? is 0 and iLeft is not > NULL). I hope we should do like below. > > > > if (len < tot) { > > s->s3->wnum = tot; > > SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); > > return (-1); > > } This is 1.0.2 code. The check appears to be earlier in master/1.1.0 (before wnum is reset) and so this isn't an issue there. Really, if an application passes a bad len value, then this is an application bug and shouldn't ever happen in a well-behaved application. I'm not sure you could really describe this as an OpenSSL bug (its a bit border line) so I'm not sure it justifies a patch to 1.0.2 (which only takes bug fixes). > > And also we should do one additional check for ?len? as mentioned in my > previous mail. > > > > if ((len < tot) || ((tot != 0) && (len < (tot + s->s3->wpend_tot)))){ > > s->s3->wnum = tot; > > SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); > > return (-1); > > } Please could you raise a github pull request for this suggestion? You will probably need two versions: one targeting master and one targeting 1.0.2 as the the code looks a little different in this area. Matt From matt at openssl.org Mon Apr 3 09:23:02 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 3 Apr 2017 10:23:02 +0100 Subject: [openssl-dev] Renegotiation ticket 3712 In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A10C98F@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A10C98F@AZ-FFEXMB03.global.avaya.com> Message-ID: <9b225e6c-3895-6f2a-648e-949204088f6d@openssl.org> On 02/04/17 04:50, Mody, Darshan (Darshan) wrote: > Hi Matt, > > Is re-negotiation fixed with openssl 1.1.0 > ? https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guesthttps://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest > > 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 From darshanmody at avaya.com Mon Apr 3 10:24:45 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Mon, 3 Apr 2017 10:24:45 +0000 Subject: [openssl-dev] Renegotiation ticket 3712 In-Reply-To: <9b225e6c-3895-6f2a-648e-949204088f6d@openssl.org> References: <25D2EC755404B4409F263AC6D050FEBB2A10C98F@AZ-FFEXMB03.global.avaya.com> <9b225e6c-3895-6f2a-648e-949204088f6d@openssl.org> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A10D4C6@AZ-FFEXMB03.global.avaya.com> 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-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Monday, April 03, 2017 2:53 PM To: openssl-dev at 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&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXza > IDagy9EuEhJrKfQ&m=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng&s=Ni8yD4 > vI9arECJEB4AvTHTPslAIBDOyQYItrnXI8Ho8&e= > > 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&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng&s=u1jQpWruXjaddyFVQW6x3TnRYA3CsHe1XzBwNlHn3p0&e= From matt at openssl.org Mon Apr 3 10:28:34 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 3 Apr 2017 11:28:34 +0100 Subject: [openssl-dev] Renegotiation ticket 3712 In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A10D4C6@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A10C98F@AZ-FFEXMB03.global.avaya.com> <9b225e6c-3895-6f2a-648e-949204088f6d@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10D4C6@AZ-FFEXMB03.global.avaya.com> Message-ID: <28165a1e-6e2e-d4f2-288b-3d9914467262@openssl.org> 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-bounces at openssl.org] On Behalf Of Matt Caswell > Sent: Monday, April 03, 2017 2:53 PM > To: openssl-dev at 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&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXza >> IDagy9EuEhJrKfQ&m=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng&s=Ni8yD4 >> vI9arECJEB4AvTHTPslAIBDOyQYItrnXI8Ho8&e= >> >> 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&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng&s=u1jQpWruXjaddyFVQW6x3TnRYA3CsHe1XzBwNlHn3p0&e= > From darshanmody at avaya.com Mon Apr 3 11:40:05 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Mon, 3 Apr 2017 11:40:05 +0000 Subject: [openssl-dev] Renegotiation ticket 3712 In-Reply-To: <28165a1e-6e2e-d4f2-288b-3d9914467262@openssl.org> References: <25D2EC755404B4409F263AC6D050FEBB2A10C98F@AZ-FFEXMB03.global.avaya.com> <9b225e6c-3895-6f2a-648e-949204088f6d@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10D4C6@AZ-FFEXMB03.global.avaya.com> <28165a1e-6e2e-d4f2-288b-3d9914467262@openssl.org> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A10D4F8@AZ-FFEXMB03.global.avaya.com> 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-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Monday, April 03, 2017 3:59 PM To: openssl-dev at 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-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Monday, April 03, 2017 2:53 PM > To: openssl-dev at 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&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXz >> a >> IDagy9EuEhJrKfQ&m=0_oGDu1Nd351FfLBQxFRBsvQxamucuAh4kuC9XC9rng&s=Ni8yD >> 4 vI9arECJEB4AvTHTPslAIBDOyQYItrnXI8Ho8&e= >> >> 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&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEU > LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=0_oGDu1Nd351FfLBQxFRBsvQxamu > cuAh4kuC9XC9rng&s=u1jQpWruXjaddyFVQW6x3TnRYA3CsHe1XzBwNlHn3p0&e= > -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=5fscKGrpSiVuD-o67_AL7je6ixVNP8R_ABJUSL0DuPc&s=KRpeak_T_gjRwyOpNMqprUNfS_1ay9lISTgdkYdm28Y&e= From rsalz at akamai.com Mon Apr 3 16:10:57 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 3 Apr 2017 16:10:57 +0000 Subject: [openssl-dev] Renegotiation ticket 3712 In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A10D4F8@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A10C98F@AZ-FFEXMB03.global.avaya.com> <9b225e6c-3895-6f2a-648e-949204088f6d@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10D4C6@AZ-FFEXMB03.global.avaya.com> <28165a1e-6e2e-d4f2-288b-3d9914467262@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10D4F8@AZ-FFEXMB03.global.avaya.com> Message-ID: > 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. Perhaps a more accurate way to say it is "I was hoping ..." :) If this is important to you -- and Matt has said that it's not important to (some of) the OpenSSL team -- then you will have to fix it yourself. If you do, I hope you will make a PR to feed it back to the open source community. From bkaduk at akamai.com Mon Apr 3 20:26:08 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 3 Apr 2017 15:26:08 -0500 Subject: [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0? Message-ID: <5b7fe7d5-c4be-9b34-07ce-21074476c48c@akamai.com> Hi all, We noticed that the depth limit check seems to behave differently between 1.0.2 and 1.1.0. In particular, with a (1.1.0) openssl/test$ ../util/shlib_wrap.sh ../apps/openssl s_server -port 8080 -cert certs/ee-cert.pem -certform PEM -key certs/ee-key.pem -keyform PEM -no-CApath -CAfile certs/root-cert.pem -chainCAfile certs/ca-cert.pem running, I can then go poke at it with s_client and look for the 'Verify return code' output from: openssl s_client -connect localhost:8080 -CAfile teset/certs/root-cert.pem -verify_depth N for N equal to 0, 1, or 2. With a 1.0.2 s_client, N=0 --> "Verify return code: 21 (unable to verify the first certificate)" N=1 --> "Verify return code: 20 (unable to get local issuer certificate)" N=2 --> "Verify return code: 0 (ok)" But the 1.1.0 s_client shows: N=0 --> "Verify return code: 22 (certificate chain too long)" N=1 --> "Verify return code: 0 (ok)" N=2 --> "Verify return code: 0 (ok)" The new behavior (which does not consider the root to be part of the chain for purposes of verification) seems to be intentional, and is explicitly tested in test/recipes/25-test_verify.t: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% # Depth tests, note the depth limit bounds the number of CA certificates # between the trust-anchor and the leaf, so, for example, with a root->ca->leaf # chain, depth = 1 is sufficient, but depth == 0 is not. # ok(verify("ee-cert", "sslserver", ["root-cert"], ["ca-cert"], "-verify_depth", "2"), "accept chain with verify_depth 2"); ok(verify("ee-cert", "sslserver", ["root-cert"], ["ca-cert"], "-verify_depth", "1"), "accept chain with verify_depth 1"); ok(!verify("ee-cert", "sslserver", ["root-cert"], ["ca-cert"], "-verify_depth", "0"), "accept chain with verify_depth 0"); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% There was a fair amount of churn in x509_vfy.c with the inclusion of the DANE stuff and whatnot, so it's not immediately clear to me when this change actually happened. I think there are good arguments for the current 1.1.0 behavior and it doesn't really make sense to try to change back to the historical behavior, but it would be good to know when the change actually happened and that it is/was a known change. Ideally we could also document the different behavior between 1.0.x and 1.1.0 better; any thoughts about where to do so? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Apr 3 20:43:15 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 3 Apr 2017 16:43:15 -0400 Subject: [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0? In-Reply-To: <5b7fe7d5-c4be-9b34-07ce-21074476c48c@akamai.com> References: <5b7fe7d5-c4be-9b34-07ce-21074476c48c@akamai.com> Message-ID: <3740CAF3-1BB0-4706-9F84-F08E586DBBE3@dukhovni.org> > On Apr 3, 2017, at 4:26 PM, Benjamin Kaduk wrote: > > There was a fair amount of churn in x509_vfy.c with the inclusion > of the DANE stuff and whatnot, so it's not immediately clear to me > when this change actually happened. I think there are good > arguments for the current 1.1.0 behavior and it doesn't really make > sense to try to change back to the historical behavior, but it would > be good to know when the change actually happened and that it is/was > a known change. Ideally we could also document the different > behavior between 1.0.x and 1.1.0 better; any thoughts about where to > do so? https://www.openssl.org/docs/man1.1.0/apps/verify.html -verify_depth num Limit the certificate chain to num intermediate CA certificates. A maximal depth chain can have up to num+2 certificates, since neither the end-entity certificate nor the trust-anchor certificate count against the -verify_depth limit. https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify_depth.html SSL_CTX_set_verify_depth() sets the maximum depth for the certificate chain verification that shall be allowed for ctx. (See the BUGS section.) ... BUGS The certificate verification depth set with SSL[_CTX]_verify_depth() stops the verification at a certain depth. The error message produced will be that of an incomplete certificate chain and not X509_V_ERR_CERT_CHAIN_TOO_LONG as may be expected. The 1.0.2 behaviour was under-documented and somewhat broken. This was fixed in 1.1.0. Unfortunately, the SSL_CTX_set_verify_depth(3) was not brought up to date, contributes welcome: https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_verify_depth.html -- Viktor. From thiago.arrais at gmail.com Tue Apr 4 14:07:55 2017 From: thiago.arrais at gmail.com (Thiago Arrais) Date: Tue, 04 Apr 2017 14:07:55 +0000 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? Message-ID: I'm interested in contributing to TLS 1.3 support. I'm also a total newbie to openssl development. I'm trying to build/run the tests and working through CONTRIBUTING. For TLS 1.3 specifically, I understand that support for draft-19 of the spec is mostly done. How do I get started working on draft-20 or some of the nice-to-haves that aren't done yet? Maybe some of the things that Matt enumerated on [his reply to openssl-users][1]? Maybe getting familiar with the spec? Where should a beginner start? Help! ;-) -- Thiago Arrais [1]: https://www.mail-archive.com/openssl-users at openssl.org/msg81262.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Apr 4 14:17:38 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 4 Apr 2017 14:17:38 +0000 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? In-Reply-To: References: Message-ID: Look at https://www.openssl.org/community/ and https://www.openssl.org/community/getting-started.html as useful starting points. From thiago.arrais at gmail.com Tue Apr 4 14:34:07 2017 From: thiago.arrais at gmail.com (Thiago Arrais) Date: Tue, 04 Apr 2017 14:34:07 +0000 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? In-Reply-To: References: Message-ID: Hmmm... The Getting Started page talks about writing test cases. It seems like a good start. Is there any area that needs special attention? On Tue, Apr 4, 2017 at 11:18 AM Salz, Rich via openssl-dev < openssl-dev at openssl.org> wrote: > Look at https://www.openssl.org/community/ and > https://www.openssl.org/community/getting-started.html as useful starting > points. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Tue Apr 4 14:41:16 2017 From: tshort at akamai.com (Short, Todd) Date: Tue, 4 Apr 2017 14:41:16 +0000 Subject: [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0? In-Reply-To: <3740CAF3-1BB0-4706-9F84-F08E586DBBE3@dukhovni.org> References: <5b7fe7d5-c4be-9b34-07ce-21074476c48c@akamai.com> <3740CAF3-1BB0-4706-9F84-F08E586DBBE3@dukhovni.org> Message-ID: Ben Kaduk: Do we know the values that are being passed to SSL_CTX_set_Verify_depth() match the -verify_depth argument, or do they differ? If they differ, do identical arguments to the function behave the same in 1.1.0 and 1.0.2? Viktor: What we?re getting at here, is that this appears to be a potentially significant behavioral change. We want to understand it better. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Apr 3, 2017, at 4:43 PM, Viktor Dukhovni > wrote: On Apr 3, 2017, at 4:26 PM, Benjamin Kaduk > wrote: There was a fair amount of churn in x509_vfy.c with the inclusion of the DANE stuff and whatnot, so it's not immediately clear to me when this change actually happened. I think there are good arguments for the current 1.1.0 behavior and it doesn't really make sense to try to change back to the historical behavior, but it would be good to know when the change actually happened and that it is/was a known change. Ideally we could also document the different behavior between 1.0.x and 1.1.0 better; any thoughts about where to do so? https://www.openssl.org/docs/man1.1.0/apps/verify.html -verify_depth num Limit the certificate chain to num intermediate CA certificates. A maximal depth chain can have up to num+2 certificates, since neither the end-entity certificate nor the trust-anchor certificate count against the -verify_depth limit. https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify_depth.html SSL_CTX_set_verify_depth() sets the maximum depth for the certificate chain verification that shall be allowed for ctx. (See the BUGS section.) ... BUGS The certificate verification depth set with SSL[_CTX]_verify_depth() stops the verification at a certain depth. The error message produced will be that of an incomplete certificate chain and not X509_V_ERR_CERT_CHAIN_TOO_LONG as may be expected. The 1.0.2 behaviour was under-documented and somewhat broken. This was fixed in 1.1.0. Unfortunately, the SSL_CTX_set_verify_depth(3) was not brought up to date, contributes welcome: https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_verify_depth.html -- Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Apr 4 17:09:53 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 4 Apr 2017 18:09:53 +0100 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? In-Reply-To: References: Message-ID: <21c872f2-7a34-5277-1d27-d6220d6529ff@openssl.org> On 04/04/17 15:34, Thiago Arrais wrote: > Hmmm... The Getting Started page talks about writing test cases. > > It seems like a good start. Is there any area that needs special attention? Actually I have a suggestion for a fairly small self-contained piece of work suitable for a starting project. The spec has this requirement: As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client. If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences; this extension SHOULD contain all groups the server supports, regardless of whether they are currently supported by the client. Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake, but MAY use the information learned from a successfully completed handshake to change what groups they use in their "key_share" extension in subsequent connections. At the moment we only ever send supported_groups client -> server. Never server -> client. I wouldn't worry about the client acting on this information at this stage. Just start with the server sending it if the selected key_share is not for the most preferred group. Hint: you will need to look at ssl/statem/extensions.c and you will also need to add code to ssl/statem/extensions_srvr.c. I strongly suggest you spend some time looking at some other github pull requests to get a feel for how our submission and review process works, and the kind of review comments that come up. You should also familiarise yourself with our coding style: https://www.openssl.org/policies/codingstyle.html All submissions should include tests. Adding something to test/recipes/70-test_tls13messages.t would probably be sufficient, i.e. a test to demonstrate that sending a preferred key_share results in no supported_groups extension in the EncryptedExtensions message, and then a test to demonstrate that sending an acceptable but non-preferred key_share results in the supported_groups extension being sent. If you are not already familiar with the TLSv1.3 spec then you will need to be. Make sure you read it through and gain a good understanding of it before you start. Matt From thiago.arrais at gmail.com Tue Apr 4 17:37:54 2017 From: thiago.arrais at gmail.com (Thiago Arrais) Date: Tue, 04 Apr 2017 17:37:54 +0000 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? In-Reply-To: <21c872f2-7a34-5277-1d27-d6220d6529ff@openssl.org> References: <21c872f2-7a34-5277-1d27-d6220d6529ff@openssl.org> Message-ID: Thank you, Matt. I actually am _not_ familiar with the spec. I was looking for some work on OpenSSL exactly because I want to know TLS better. Your suggestion seems like a good start. It is pretty dense, but that was exactly what I was looking for. Thank you again. -- Arrais On Tue, Apr 4, 2017 at 2:10 PM Matt Caswell wrote: > > > On 04/04/17 15:34, Thiago Arrais wrote: > > Hmmm... The Getting Started page talks about writing test cases. > > > > It seems like a good start. Is there any area that needs special > attention? > > Actually I have a suggestion for a fairly small self-contained piece of > work suitable for a starting project. > > The spec has this requirement: > > As of TLS 1.3, servers are permitted to send the "supported_groups" > extension to the client. If the server has a group it prefers to the > ones in the "key_share" extension but is still willing to accept the > ClientHello, it SHOULD send "supported_groups" to update the client's > view of its preferences; this extension SHOULD contain all groups the > server supports, regardless of whether they are currently supported > by the client. Clients MUST NOT act upon any information found in > "supported_groups" prior to successful completion of the handshake, > but MAY use the information learned from a successfully completed > handshake to change what groups they use in their "key_share" > extension in subsequent connections. > > At the moment we only ever send supported_groups client -> server. Never > server -> client. I wouldn't worry about the client acting on this > information at this stage. Just start with the server sending it if the > selected key_share is not for the most preferred group. > > Hint: you will need to look at ssl/statem/extensions.c and you will also > need to add code to ssl/statem/extensions_srvr.c. > > I strongly suggest you spend some time looking at some other github pull > requests to get a feel for how our submission and review process works, > and the kind of review comments that come up. You should also > familiarise yourself with our coding style: > > https://www.openssl.org/policies/codingstyle.html > > All submissions should include tests. Adding something to > test/recipes/70-test_tls13messages.t would probably be sufficient, i.e. > a test to demonstrate that sending a preferred key_share results in no > supported_groups extension in the EncryptedExtensions message, and then > a test to demonstrate that sending an acceptable but non-preferred > key_share results in the supported_groups extension being sent. > > If you are not already familiar with the TLSv1.3 spec then you will need > to be. Make sure you read it through and gain a good understanding of it > before you start. > > Matt > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Apr 4 17:44:19 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 4 Apr 2017 13:44:19 -0400 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? In-Reply-To: <21c872f2-7a34-5277-1d27-d6220d6529ff@openssl.org> References: <21c872f2-7a34-5277-1d27-d6220d6529ff@openssl.org> Message-ID: > On Apr 4, 2017, at 1:09 PM, Matt Caswell wrote: > > Actually I have a suggestion for a fairly small self-contained piece of > work suitable for a starting project. My suggestion would be start with something simpler still, and get used to the format of the documentation, which will be required for future more ambitious work. Specifically, update the documentation of SSL_CTX_set_verify_depth(3) to correctly describe the semantics of the "verify depth" in OpenSSL 1.1.0 and later. The documentation was updated in the CLI verify(1) manpage, but some of the required changes did make it into the API document. -- Viktor. From thiago.arrais at gmail.com Tue Apr 4 19:28:09 2017 From: thiago.arrais at gmail.com (Thiago Arrais) Date: Tue, 04 Apr 2017 19:28:09 +0000 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? In-Reply-To: References: <21c872f2-7a34-5277-1d27-d6220d6529ff@openssl.org> Message-ID: Viktor, This is related to this message on openssl-users, right? https://www.mail-archive.com/openssl-users at openssl.org/msg81251.html As I understand this isn't directly related to TLS 1.3. But it can work as an intro to the codebase. -- Arrais On Tue, Apr 4, 2017 at 2:50 PM Viktor Dukhovni wrote: > > > On Apr 4, 2017, at 1:09 PM, Matt Caswell wrote: > > > > Actually I have a suggestion for a fairly small self-contained piece of > > work suitable for a starting project. > > My suggestion would be start with something simpler still, and get used > to the format of the documentation, which will be required for future > more ambitious work. > > Specifically, update the documentation of SSL_CTX_set_verify_depth(3) > to correctly describe the semantics of the "verify depth" in OpenSSL > 1.1.0 and later. The documentation was updated in the CLI verify(1) > manpage, but some of the required changes did make it into the API > document. > > -- > Viktor. > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Apr 4 23:09:58 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 4 Apr 2017 19:09:58 -0400 Subject: [openssl-dev] Contributing to TLS 1.3 - Where to start? In-Reply-To: References: <21c872f2-7a34-5277-1d27-d6220d6529ff@openssl.org> Message-ID: <1B54B079-A5AB-48A9-828C-6A67CD182C59@dukhovni.org> > On Apr 4, 2017, at 3:28 PM, Thiago Arrais wrote: > > Viktor, > > This is related to this message on openssl-users, right? > > https://www.mail-archive.com/openssl-users at openssl.org/msg81251.html Yes. > As I understand this isn't directly related to TLS 1.3. But it can work > as an intro to the codebase. Yes, and we want all contributions to be documented, so the documentation is a good place to start. Perhaps then tests, and only after that new code. -- Viktor. From raja.ashok at huawei.com Wed Apr 5 04:59:52 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Wed, 5 Apr 2017 04:59:52 +0000 Subject: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing In-Reply-To: References: Message-ID: Hi Matt, I created a Pull request for the second change on master, 1.0.2 and 1.1.0. I am creating PR in github for the first time, so if anything else I missed please update me. https://github.com/openssl/openssl/pull/3124 https://github.com/openssl/openssl/pull/3123 https://github.com/openssl/openssl/pull/3122 Regards, Ashok Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: 03 April 2017 14:40 To: openssl-dev at openssl.org Subject: Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing On 31/03/17 18:54, Raja ashok wrote: > Hi All, > > > > In ssl3_write_bytes, if (len < tot) we are returning failure with > SSL_R_BAD_LENGTH error. In this place I hope we should set ?tot? back > to ?s->s3->wnum?. Otherwise when application calls back SSL_write with > correct buffer, it causes serious problem (?tot? is 0 and iLeft is not > NULL). I hope we should do like below. > > > > if (len < tot) { > > s->s3->wnum = tot; > > SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); > > return (-1); > > } This is 1.0.2 code. The check appears to be earlier in master/1.1.0 (before wnum is reset) and so this isn't an issue there. Really, if an application passes a bad len value, then this is an application bug and shouldn't ever happen in a well-behaved application. I'm not sure you could really describe this as an OpenSSL bug (its a bit border line) so I'm not sure it justifies a patch to 1.0.2 (which only takes bug fixes). > > And also we should do one additional check for ?len? as mentioned in > my previous mail. > > > > if ((len < tot) || ((tot != 0) && (len < (tot + > s->s3->wpend_tot)))){ > > s->s3->wnum = tot; > > SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); > > return (-1); > > } Please could you raise a github pull request for this suggestion? You will probably need two versions: one targeting master and one targeting 1.0.2 as the the code looks a little different in this area. Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From nmav at redhat.com Wed Apr 5 09:59:37 2017 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Wed, 05 Apr 2017 11:59:37 +0200 Subject: [openssl-dev] internationalized passwords for pkcs#8, pkcs#12 files Message-ID: <1491386377.4249.7.camel@redhat.com> Hi, I would like to eliminate the ambiguities concerning internationalized passwords in PKCS#8 and PKCS#12 files. I plan to propose an update to the PKCS#5, PKCS#12 documents mandating UTF-8 and requiring the RFC7613 OpaqueString profile. I'm interested on openssl developers opinion on the topic. The unpublished draft is at: https://gitlab.com/nmav/ietf-pkcs5 while the ietf-saag discussion at: https://mailarchive.ietf.org/arch/msg/saag/STcizjP7tVYQANm-_HwWNQr7DXw regards, Nikos From xlyson02 at stud.fit.vutbr.cz Wed Apr 5 18:24:02 2017 From: xlyson02 at stud.fit.vutbr.cz (=?iso-8859-2?b?THlzb27saw==?= Milan) Date: Wed, 05 Apr 2017 20:24:02 +0200 Subject: [openssl-dev] Testing CVE-2016-6309 Message-ID: <20170405202402.25874xkjrj33jvpe@email.fit.vutbr.cz> Hello, I'd like to make test for CVE-2016-6309 https://www.openssl.org/news/secadv/20160926.txt in tlsfuzzer. I tried combining and sending different lengths (from small lengths to large) of application data and padding, but I could not trigger this issue on mentioned OpenSSL 1.1.0a. Is there any way, how can I test it and if yes, then how? Thanks, Milan. From matt at openssl.org Wed Apr 5 22:25:51 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Apr 2017 23:25:51 +0100 Subject: [openssl-dev] Testing CVE-2016-6309 In-Reply-To: <20170405202402.25874xkjrj33jvpe@email.fit.vutbr.cz> References: <20170405202402.25874xkjrj33jvpe@email.fit.vutbr.cz> Message-ID: <03bef12f-01b8-b683-099c-88314d686059@openssl.org> On 05/04/17 19:24, Lyson?k Milan wrote: > Hello, > I'd like to make test for CVE-2016-6309 > https://www.openssl.org/news/secadv/20160926.txt in tlsfuzzer. I tried > combining and sending different lengths (from small lengths to large) of > application data and padding, but I could not trigger this issue on > mentioned OpenSSL 1.1.0a. > > Is there any way, how can I test it and if yes, then how? Can you reproduce it using the fuzz corpora added in commit 44f206aa9df, or by running the large message test introduced in 84d5549e69? Matt From paul.dale at oracle.com Thu Apr 6 05:40:00 2017 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 5 Apr 2017 22:40:00 -0700 (PDT) Subject: [openssl-dev] Code Health Tuesday - test modernisation Message-ID: Next week on the 11th of April it is Code Health Tuesday again. This fortnight it will be about updating the C unit tests to use the test framework. Everyone is invited to participate to help bring consistency and order to the unit tests. Many of the existing C tests are ad-hoc. The desired form of C test executables is described at the end of test/README. A brief description of the condition and output framework is in the list archives: https://www.mail-archive.com/openssl-dev at openssl.org/msg46648.html. Some tests have already been updated to use both to serve as examples. Regards, Pauli (at the suggestion of the dev team) FAQ: Q: How do I participate? A: Once you've update your tests, create a Github pull request and put "code health" in the title. Such commits will be monitored for quick turnaround. Q: Which tests should I convert? A: There is a spreadsheet: conversion: https://docs.google.com/spreadsheets/d/1VJTmEVT1EyYxZ90GnhAPd4vtFg74Ij3Y-pthjXdmH80/edit#gid=0 This lists all the C tests, select one you want to work on and tag it to avoid duplication. Q: Which branch should I target? A: Master is the one. It is the only branch with the new infrastructure. Q: Where do I go if the infrastructure isn't working? A: Post the problem here. Q: Can I suggest improvements to the infrastructure? A: Sure thing, post them here too. -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Mon Apr 10 04:08:09 2017 From: paul.dale at oracle.com (Paul Dale) Date: Sun, 9 Apr 2017 21:08:09 -0700 (PDT) Subject: [openssl-dev] Code Health Tuesday - test modernisation In-Reply-To: References: Message-ID: A quick reminder that tomorrow is _test update_ Code Health Tuesday. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Paul Dale Sent: Thursday, 6 April 2017 3:40 PM To: openssl-dev at openssl.org Subject: [openssl-dev] Code Health Tuesday - test modernisation Next week on the 11th of April it is Code Health Tuesday again. This fortnight it will be about updating the C unit tests to use the test framework. Everyone is invited to participate to help bring consistency and order to the unit tests. ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? Many of the existing C tests are ad-hoc.? The desired form of C test executables is described at the end of test/README.? A brief description of the condition and output framework is in the list archives: https://www.mail-archive.com/openssl-dev at openssl.org/msg46648.html.? Some tests have already been updated to use both to serve as examples. Regards, Pauli (at the suggestion of the dev team) FAQ: Q: How do I participate? A: Once you've update your tests, create a Github pull request and put "code health" in the title. Such commits will be monitored for quick turnaround. Q: Which tests should I convert? A: There is a spreadsheet: conversion: https://docs.google.com/spreadsheets/d/1VJTmEVT1EyYxZ90GnhAPd4vtFg74Ij3Y-pthjXdmH80/edit#gid=0 This lists all the C tests, select one you want to work on and tag it to avoid duplication. Q: Which branch should I target? A: Master is the one.? It is the only branch with the new infrastructure. Q: Where do I go if the infrastructure isn't working? A: Post the problem here. Q: Can I suggest improvements to the infrastructure? A: Sure thing, post them here too. -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From michaelr at cisco.com Tue Apr 11 22:12:41 2017 From: michaelr at cisco.com (Michael Reilly) Date: Tue, 11 Apr 2017 15:12:41 -0700 Subject: [openssl-dev] Question about commit 222333cf01e2fec4a20c107ac9e820694611a4db Message-ID: Hi, commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in crypto/evp/pmeth_fn.c is != 0. We are in the process of upgrading from 1.0.2j to 1.0.2k and discovered that the if (pksize == 0) check added in 1.0.2k breaks some of our applications. We use an engine for the RSA sign operation. The applications do not know anything about the keypair being used. The keypair is kept private by the engine so the application couldn't determine the attributes of the keypair if it wanted to do so. If this check is necessary is there a way to bypass it when the application does not have the keypair but the engine being used is holding the keypair? I know we can simply remove this line from our copy of the code but we like to avoid modifying the openssl distributed code if at all possible. Thanks, michael commit info: commit 222333cf01e2fec4a20c107ac9e820694611a4db Author: Richard Levitte Date: Tue Dec 20 12:56:14 2016 +0100 M_check_autoarg: sanity check the key For now, checking that the size is non-zero will suffice. Reviewed-by: Rich Salz (Merged from https://github.com/openssl/openssl/pull/2120) (cherry picked from commit d7c8f142ea5953bf260b70a58739c1c9b0f038eb) -- ---- ---- ---- Michael Reilly michaelr at cisco.com Cisco Systems Arizona From steve at openssl.org Tue Apr 11 22:47:36 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 11 Apr 2017 22:47:36 +0000 Subject: [openssl-dev] Question about commit 222333cf01e2fec4a20c107ac9e820694611a4db In-Reply-To: References: Message-ID: <20170411224736.GA27880@openssl.org> On Tue, Apr 11, 2017, Michael Reilly wrote: > Hi, > > commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size > returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in > crypto/evp/pmeth_fn.c is != 0. > > We are in the process of upgrading from 1.0.2j to 1.0.2k and discovered that the > if (pksize == 0) check added in 1.0.2k breaks some of our applications. > > We use an engine for the RSA sign operation. The applications do not know > anything about the keypair being used. The keypair is kept private by the > engine so the application couldn't determine the attributes of the keypair if it > wanted to do so. > > If this check is necessary is there a way to bypass it when the application does > not have the keypair but the engine being used is holding the keypair? > > I know we can simply remove this line from our copy of the code but we like to > avoid modifying the openssl distributed code if at all possible. > Well the point of that code is so an application knows how large a buffer to allocate for the signature. If it returns zero I can't see how applications can do that. Note that you don't have to return the *precise* length of the signature just an upper bound is sufficient. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From michaelr at cisco.com Tue Apr 11 23:20:57 2017 From: michaelr at cisco.com (Michael Reilly) Date: Tue, 11 Apr 2017 16:20:57 -0700 Subject: [openssl-dev] Question about commit 222333cf01e2fec4a20c107ac9e820694611a4db In-Reply-To: <20170411224736.GA27880@openssl.org> References: <20170411224736.GA27880@openssl.org> Message-ID: <28f7c786-4a63-f723-467f-c416986e869c@cisco.com> Unfortunately the check breaks code which doesn't know nor need to know the keysize. The engine takes care of allocating buffers required. Leaving it set to 0 has not broken anything yet. I supposed we could try to somehow set it to an arbitrary non-zero value to please the == 0 check. michael On 04/11/2017 03:47 PM, Dr. Stephen Henson wrote: > On Tue, Apr 11, 2017, Michael Reilly wrote: > >> Hi, >> >> commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size >> returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in >> crypto/evp/pmeth_fn.c is != 0. >> >> We are in the process of upgrading from 1.0.2j to 1.0.2k and discovered that the >> if (pksize == 0) check added in 1.0.2k breaks some of our applications. >> >> We use an engine for the RSA sign operation. The applications do not know >> anything about the keypair being used. The keypair is kept private by the >> engine so the application couldn't determine the attributes of the keypair if it >> wanted to do so. >> >> If this check is necessary is there a way to bypass it when the application does >> not have the keypair but the engine being used is holding the keypair? >> >> I know we can simply remove this line from our copy of the code but we like to >> avoid modifying the openssl distributed code if at all possible. >> > > Well the point of that code is so an application knows how large a buffer to > allocate for the signature. If it returns zero I can't see how applications > can do that. > > Note that you don't have to return the *precise* length of the signature just > an upper bound is sufficient. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- ---- ---- ---- Michael Reilly michaelr at cisco.com Cisco Systems Arizona From bkaduk at akamai.com Tue Apr 11 23:44:58 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 11 Apr 2017 18:44:58 -0500 Subject: [openssl-dev] Question about commit 222333cf01e2fec4a20c107ac9e820694611a4db In-Reply-To: <28f7c786-4a63-f723-467f-c416986e869c@cisco.com> References: <20170411224736.GA27880@openssl.org> <28f7c786-4a63-f723-467f-c416986e869c@cisco.com> Message-ID: <8de2da60-c113-6e1e-368a-b9dc0ce2e685@akamai.com> It seems like a more elegant option would be if there was some attribute of the engine that could be queried and override the check against zero. -Ben On 04/11/2017 06:20 PM, Michael Reilly wrote: > Unfortunately the check breaks code which doesn't know nor need to know the > keysize. The engine takes care of allocating buffers required. > > Leaving it set to 0 has not broken anything yet. I supposed we could try to > somehow set it to an arbitrary non-zero value to please the == 0 check. > > michael > > On 04/11/2017 03:47 PM, Dr. Stephen Henson wrote: >> On Tue, Apr 11, 2017, Michael Reilly wrote: >> >>> Hi, >>> >>> commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size >>> returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in >>> crypto/evp/pmeth_fn.c is != 0. >>> >>> We are in the process of upgrading from 1.0.2j to 1.0.2k and discovered that the >>> if (pksize == 0) check added in 1.0.2k breaks some of our applications. >>> >>> We use an engine for the RSA sign operation. The applications do not know >>> anything about the keypair being used. The keypair is kept private by the >>> engine so the application couldn't determine the attributes of the keypair if it >>> wanted to do so. >>> >>> If this check is necessary is there a way to bypass it when the application does >>> not have the keypair but the engine being used is holding the keypair? >>> >>> I know we can simply remove this line from our copy of the code but we like to >>> avoid modifying the openssl distributed code if at all possible. >>> >> Well the point of that code is so an application knows how large a buffer to >> allocate for the signature. If it returns zero I can't see how applications >> can do that. >> >> Note that you don't have to return the *precise* length of the signature just >> an upper bound is sufficient. >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarner_online at gmgsystemsinc.com Wed Apr 12 00:10:14 2017 From: ggarner_online at gmgsystemsinc.com (George Garner (online)) Date: Tue, 11 Apr 2017 20:10:14 -0400 Subject: [openssl-dev] Problem displaying rsa private key. Message-ID: An rsa private key may be displayed using the following command (on MS Windows): openssl rsa -inform PEM -in E:\Temp\private.pem -text -noout When I execute this command I get the following partial results: modulus: 00:cd:a7:cc:46:17:97:e6:89:e7:bb:36:e2:4d:f0: 32:1c:e7:e2:6f:18:de:80:73:2a:2b:48:f8:36:0c: ed:a4:55:a1:5f:d2:72:62:88:3c:15:8c:a5:31:89: f5:f6:83:d5:ba:19:f1:7d:1e:ae:5d:f9:5d:d9:4d: 87:4f:27:b1:b2:a4:ac:a5:81:1f:41:51:5d:90:d6: 0d:cc:3c:d5:56:47:ba:61:5d:2b:f9:85:36:0c:b7: 76:aa:87:0e:2e:51:f9:b3:cf:24:b3:92:38:28:51: 90:72:1c:d6:13:87:3b:cf:19:f8:80:e6:32:25:b0: 79:9b:cb:d6:11:f4:68:be:2d:96:ce:42:a0:ee:0e: e7:14:5a:a4:38:80:c6:13:37:bb:dc:23:d7:e8:ea: e3:b7:49:af:74:21:6a:57:0d:d5:0a:18:a0:53:e8: e5:62:b5:b0:c0:36:82:f8:45:53:8b:ff:de:5e:1e: ef:dc:c3:e8:fa:69:ac:f6:1e:6a:18:f4:2f:43:98: c7:e0:e3:f9:ff:1a:d3:b4:9a:66:28:0c:de:aa:a9: 60:a5:5b:eb:a2:a0:f7:9c:71:80:2b:26:76:1d:97: 04:f3:4b:f6:3d:e0:77:ab:95:5b:47:14:04:3b:ad: 54:8e:8d:84:1c:d5:0b:91:25:27:37:c2:2f:f9:0d: 8c:73 publicExponent: 65537 (0x10001) The public exponent is correct but the modulus has a spurious zero byte prepended to it in the display. The modulus actually starts with 0xcd. The private exponent and primes (not shown) exhibit a similar problem. Was this the intention? Regards, George. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Apr 12 00:55:57 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 12 Apr 2017 00:55:57 +0000 Subject: [openssl-dev] Problem displaying rsa private key. In-Reply-To: References: Message-ID: <87c56ac50a1c47e0a3c88160885912f5@ustx2ex-dag1mb1.msg.corp.akamai.com> modulus: ??? 00:cd:a7:cc:46:17:97:e6:89:e7:bb:36:e2:4d:f0: Without the leading zero, the 0xCD would be interpreted as a negative number according to ASN1/DER rules. From matt at openssl.org Wed Apr 12 08:34:57 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Apr 2017 09:34:57 +0100 Subject: [openssl-dev] Question about commit 222333cf01e2fec4a20c107ac9e820694611a4db In-Reply-To: <28f7c786-4a63-f723-467f-c416986e869c@cisco.com> References: <20170411224736.GA27880@openssl.org> <28f7c786-4a63-f723-467f-c416986e869c@cisco.com> Message-ID: On 12/04/17 00:20, Michael Reilly wrote: > Unfortunately the check breaks code which doesn't know nor need to know the > keysize. The engine takes care of allocating buffers required. So how does EVP_SignFinal() work with your engine? The "sig" parameter is supposed to be allocated by the caller to be EVP_PKEY_size() bytes long. I don't see how that API works if the engine allocates the buffers. Matt > > Leaving it set to 0 has not broken anything yet. I supposed we could try to > somehow set it to an arbitrary non-zero value to please the == 0 check. > > michael > > On 04/11/2017 03:47 PM, Dr. Stephen Henson wrote: >> On Tue, Apr 11, 2017, Michael Reilly wrote: >> >>> Hi, >>> >>> commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size >>> returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in >>> crypto/evp/pmeth_fn.c is != 0. >>> >>> We are in the process of upgrading from 1.0.2j to 1.0.2k and discovered that the >>> if (pksize == 0) check added in 1.0.2k breaks some of our applications. >>> >>> We use an engine for the RSA sign operation. The applications do not know >>> anything about the keypair being used. The keypair is kept private by the >>> engine so the application couldn't determine the attributes of the keypair if it >>> wanted to do so. >>> >>> If this check is necessary is there a way to bypass it when the application does >>> not have the keypair but the engine being used is holding the keypair? >>> >>> I know we can simply remove this line from our copy of the code but we like to >>> avoid modifying the openssl distributed code if at all possible. >>> >> >> Well the point of that code is so an application knows how large a buffer to >> allocate for the signature. If it returns zero I can't see how applications >> can do that. >> >> Note that you don't have to return the *precise* length of the signature just >> an upper bound is sufficient. >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> > From rees.bettell at identifiglobal.com Wed Apr 12 13:20:14 2017 From: rees.bettell at identifiglobal.com (Rees Bettell) Date: Wed, 12 Apr 2017 13:20:14 +0000 Subject: [openssl-dev] OpenSSL Dev Opportunity - Rees Bettell - Identifi Global Message-ID: Good Morning/Afternoon All, I hope you are well. The reason I am reaching out to you all today is because I have a very interesting opportunity that I would like to bring to your attention. I am currently seeking an expert OpenSSL Developer with a strong knowledge of Linux, and also an encryption specialist to work for one of my clients that are looking to build a layer of encryption to interface with the encryption chip that they are currently designing. This role is very unique and interesting, and my client is happy for the successful person to work from home so relocation wouldn't be needed. The work will take place on a consultancy basis, so the type of rate would be daily. If you tick both of the boxes needed by my client, they will be happy to pay a substantial amount per day. I think the best thing to do at this point is to say that the rate is negotiable as my client has had a lot of funding provided by investors and the government, so would be happy to pay near enough anything for the right person. This isn't a role that I work on regularly so I am sorry if this comes across in an unprofessional manner, however this is an amazing opportunity and if you aren't interested yourself then you may know someone that would be. Please do get in contact with me if this is going to be something of interest. Kind regards, Rees Bettell. Rees Bettell | Researcher T: +44 (0)1908 886 048 | M: +44 (0)7730096013 | DDI: +44 (0)1908 886 031 E: rees.bettell at identifiglobal.com | W: www.identifiglobal.com Innovation Centre, A&E Block, Bletchley Park, Milton Keynes, Buckinghamshire, MK3 6EB [http://tiny.cc/23bq4x] [http://tiny.cc/o5bq4x] [http://tiny.cc/76bq4x] [http://tiny.cc/r7bq4x] [identifi Global Resources] [http://tiny.cc/e9bq4x] This message is intended only for the use of the person(s) to whom it is addressed. Any dissemination, distribution, copying or other use of this message or any of its contents by any person other that the intended recipient may constitute a breach of civil or criminal law and is strictly prohibited. Emails are susceptible to interference. Identifi Global Resources Limited accepts no responsibility for information, errors, omissions or corrupt files received as a result of this email. Identifi Global Resources Limited is a Company registered in the UK, Company number 9652112. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 989 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 766 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 839 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 916 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 7839 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 3957 bytes Desc: image008.jpg URL: From glosterj9 at gmail.com Wed Apr 12 17:43:33 2017 From: glosterj9 at gmail.com (john gloster) Date: Wed, 12 Apr 2017 23:13:33 +0530 Subject: [openssl-dev] OSCP. Message-ID: Could anyone point me to some OSCP samples? Needed to check whether CA certificate is still active. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wrowe at rowe-clan.net Wed Apr 12 18:09:05 2017 From: wrowe at rowe-clan.net (William A Rowe Jr) Date: Wed, 12 Apr 2017 13:09:05 -0500 Subject: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch Message-ID: Did the no-fips option get removed by-design? Are the no-* corollaries going to be dropped going forwards? ../src/openssl-1.1.0git/config shared no-fips --libdir=lib --prefix=/opt/openssl110 Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0f-dev (0x10100060L) ***** Unsupported options: no-fips From rsalz at akamai.com Wed Apr 12 18:26:57 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 12 Apr 2017 18:26:57 +0000 Subject: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch In-Reply-To: References: Message-ID: <994207dc6eb64a6a880aadd6b7b6e7b2@ustx2ex-dag1mb1.msg.corp.akamai.com> > Did the no-fips option get removed by-design? Are the no-* corollaries going > to be dropped going forwards? Yes. All FIPS support was removed. It could be brought back, and made a no-op, if that's a real issue. There are no plans to remove any other no-* at this time. From rsalz at akamai.com Wed Apr 12 18:31:10 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 12 Apr 2017 18:31:10 +0000 Subject: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch In-Reply-To: <994207dc6eb64a6a880aadd6b7b6e7b2@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <994207dc6eb64a6a880aadd6b7b6e7b2@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <0f6074da826344019dc31f4265d49531@ustx2ex-dag1mb1.msg.corp.akamai.com> > Yes. All FIPS support was removed. It could be brought back, and made a > no-op, if that's a real issue. By it, I meant the "no-fips" option From phpdev at ehrhardt.nl Wed Apr 12 18:21:20 2017 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Wed, 12 Apr 2017 20:21:20 +0200 Subject: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch References: Message-ID: Hi Bill, William A Rowe Jr in gmane.comp.encryption.openssl.devel (Wed, 12 Apr 2017 13:09:05 -0500): >Did the no-fips option get removed by-design? Are the no-* >corollaries going to be dropped going forwards? > >../src/openssl-1.1.0git/config shared no-fips --libdir=lib >--prefix=/opt/openssl110 > >Operating system: x86_64-whatever-linux2 >Configuring for linux-x86_64 >Configuring OpenSSL version 1.1.0f-dev (0x10100060L) >***** Unsupported options: no-fips fips is not supported in OpenSSL 1.1 yet, so my best guess is that both fips and no-fips are removed by-design. -- Jan From wrowe at rowe-clan.net Wed Apr 12 18:39:03 2017 From: wrowe at rowe-clan.net (William A Rowe Jr) Date: Wed, 12 Apr 2017 13:39:03 -0500 Subject: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch In-Reply-To: <994207dc6eb64a6a880aadd6b7b6e7b2@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <994207dc6eb64a6a880aadd6b7b6e7b2@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Wed, Apr 12, 2017 at 1:26 PM, Salz, Rich via openssl-dev wrote: >> Did the no-fips option get removed by-design? Are the no-* corollaries going >> to be dropped going forwards? > > Yes. All FIPS support was removed. It could be brought back, and made a no-op, if that's a real issue. It isn't a big problem here for me (default = no-fips, whether the /usr/local/openssl/fips/ tree was discovered or not.) It was future proofing a new schema before some existing fips binary might be detected on a build box inadvertently. But for consistency, permitting 'no-fips' for the lifespan of 1.0.2/1.1.0 seems prudent. No reason for it to survive on master. From paul.dale at oracle.com Thu Apr 13 00:02:43 2017 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 12 Apr 2017 17:02:43 -0700 (PDT) Subject: [openssl-dev] Code Health Tuesday - summary Message-ID: <86362e95-c6af-4483-be50-0ac904e75691@default> Code Health Tuesday is over once again. In total 27 PRs were raised for the event with three of these as yet unmerged. In total about thirty tests were updated which represents roughly half of the outstanding test cases. All in all, a solid outcome for testing uniformity. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Paul Dale Sent: Thursday, 6 April 2017 3:40 PM To: openssl-dev at openssl.org Subject: [openssl-dev] Code Health Tuesday - test modernisation Next week on the 11th of April it is Code Health Tuesday again. This fortnight it will be about updating the C unit tests to use the test framework. Everyone is invited to participate to help bring consistency and order to the unit tests. Many of the existing C tests are ad-hoc. The desired form of C test executables is described at the end of test/README. A brief description of the condition and output framework is in the list archives: https://www.mail-archive.com/openssl-dev at openssl.org/msg46648.html. Some tests have already been updated to use both to serve as examples. Regards, Pauli (at the suggestion of the dev team) FAQ: Q: How do I participate? A: Once you've update your tests, create a Github pull request and put "code health" in the title. Such commits will be monitored for quick turnaround. Q: Which tests should I convert? A: There is a spreadsheet: conversion: https://docs.google.com/spreadsheets/d/1VJTmEVT1EyYxZ90GnhAPd4vtFg74Ij3Y-pthjXdmH80/edit#gid=0 This lists all the C tests, select one you want to work on and tag it to avoid duplication. Q: Which branch should I target? A: Master is the one. It is the only branch with the new infrastructure. Q: Where do I go if the infrastructure isn't working? A: Post the problem here. Q: Can I suggest improvements to the infrastructure? A: Sure thing, post them here too. -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Apr 13 08:18:53 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 13 Apr 2017 09:18:53 +0100 Subject: [openssl-dev] Code Health Tuesday - summary In-Reply-To: <86362e95-c6af-4483-be50-0ac904e75691@default> References: <86362e95-c6af-4483-be50-0ac904e75691@default> Message-ID: <03a9c3d8-fed9-9511-e7fd-ebee36ec8827@openssl.org> On 13/04/17 01:02, Paul Dale wrote: > Code Health Tuesday is over once again. > > > > In total 27 PRs were raised for the event with three of these as yet > unmerged. In total about thirty tests were updated which represents > roughly half of the outstanding test cases. > > All in all, a solid outcome for testing uniformity. > Fantatic result! Thanks to all involved. Also thanks to Paul for organising this. Matt > > > > > Pauli > > -- > > Oracle > > Dr Paul Dale | Cryptographer | Network Security & Encryption > > Phone +61 7 3031 7217 > > Oracle Australia > > > > *From:*Paul Dale > *Sent:* Thursday, 6 April 2017 3:40 PM > *To:* openssl-dev at openssl.org > *Subject:* [openssl-dev] Code Health Tuesday - test modernisation > > > > Next week on the 11th of April it is Code Health Tuesday again. > > > > This fortnight it will be about updating the C unit tests to use the > test framework. Everyone is invited to participate to help bring > consistency and order to the unit tests. > > > > > Many of the existing C tests are ad-hoc. The desired form of C test > executables is described at the end of test/README. A brief description > of the condition and output framework is in the list archives: > https://www.mail-archive.com/openssl-dev at openssl.org/msg46648.html. > Some tests have already been updated to use both to serve as examples. > > > > > > Regards, > > > > Pauli > > (at the suggestion of the dev team) > > > > > > FAQ: > > > > Q: How do I participate? > > A: Once you've update your tests, create a Github pull request and put > "code health" in the title. Such commits will be monitored for quick > turnaround. > > > > Q: Which tests should I convert? > > A: There is a spreadsheet: conversion: > https://docs.google.com/spreadsheets/d/1VJTmEVT1EyYxZ90GnhAPd4vtFg74Ij3Y-pthjXdmH80/edit#gid=0 > This lists all the C tests, select one you want to work on and tag it to > avoid duplication. > > > > Q: Which branch should I target? > > A: Master is the one. It is the only branch with the new infrastructure. > > > > Q: Where do I go if the infrastructure isn't working? > > A: Post the problem here. > > > > Q: Can I suggest improvements to the infrastructure? > > A: Sure thing, post them here too. > > > > > > -- > > Oracle > > Dr Paul Dale | Cryptographer | Network Security & Encryption > > Phone +61 7 3031 7217 > > Oracle Australia > > > > > From uri at ll.mit.edu Thu Apr 13 20:55:36 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 13 Apr 2017 20:55:36 +0000 Subject: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag Message-ID: <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9@ll.mit.edu> I am trying to use ?openssl rsautl? to wrap/unwrap symmetric keys in a script. Decryption (and encryption too, but that isn?t relevant) is done using a token accessible via pkcs11 engine (libp11). The problem is: ?rsautl? appears to assume that if ?-oaep? flag is given, then the engine is going to handle OAEP padding. This is the screen log: $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -oaep -in t256.dat -out t256.dat.enc engine "pkcs11" set. $ ls -l t256.dat.enc -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep -in t256.dat.enc -out t256.dat.dec engine "pkcs11" set. PKCS#11 token PIN: PKCS#11: Unsupported padding type RSA operation error $ libp11 does not know how to deal with OAEP padding, so it returns an error. Desired solution: in case of ?-oaep? pass ?RSA_NO_PADDING? to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. I?d like to see that fixed in both 1.1 and 1.0.2 branches. ? Regards, Uri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From levitte at openssl.org Thu Apr 13 21:18:40 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 13 Apr 2017 23:18:40 +0200 (CEST) Subject: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag In-Reply-To: <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9@ll.mit.edu> References: <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9@ll.mit.edu> Message-ID: <20170413.231840.1562451136092061926.levitte@openssl.org> In message <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9 at ll.mit.edu> on Thu, 13 Apr 2017 20:55:36 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> I am trying to use ?openssl rsautl? to wrap/unwrap symmetric keys in a script. Decryption (and encryption too, but that isn?t relevant) is done using a token accessible via pkcs11 engine (libp11). uri> uri> The problem is: ?rsautl? appears to assume that if ?-oaep? flag is given, then the engine is going to handle OAEP padding. This is the screen log: uri> uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -oaep -in t256.dat -out t256.dat.enc uri> engine "pkcs11" set. uri> $ ls -l t256.dat.enc uri> -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep -in t256.dat.enc -out t256.dat.dec uri> engine "pkcs11" set. uri> PKCS#11 token PIN: uri> PKCS#11: Unsupported padding type uri> RSA operation error uri> $ uri> uri> libp11 does not know how to deal with OAEP padding, so it returns an error. uri> uri> Desired solution: in case of ?-oaep? pass ?RSA_NO_PADDING? to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. uri> uri> I?d like to see that fixed in both 1.1 and 1.0.2 branches. Wouldn't it be muuuuuch easier to add the following lines: case RSA_PKCS1_OAEP_PADDING: mechanism->mechanism = CKM_RSA_PKCS_OAEP; break; right about here? https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L72 What you propose for OpenSSL is quite a lot harder to implement well, and one might also wonder why the OAEP padding should have that special treatment and no other? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Thu Apr 13 21:31:55 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 13 Apr 2017 21:31:55 +0000 Subject: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag In-Reply-To: <20170413.231840.1562451136092061926.levitte@openssl.org> References: <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9@ll.mit.edu> <20170413.231840.1562451136092061926.levitte@openssl.org> Message-ID: On 4/13/17, 5:18 PM, "Richard Levitte" wrote: uri> . . . . . uri> libp11 does not know how to deal with OAEP padding, so it returns an error. uri> uri> Desired solution: in case of ?-oaep? pass ?RSA_NO_PADDING? to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. uri> uri> I?d like to see that fixed in both 1.1 and 1.0.2 branches. Wouldn't it be muuuuuch easier to add the following lines [to libp11/src/p11_rsa.c]: case RSA_PKCS1_OAEP_PADDING: mechanism->mechanism = CKM_RSA_PKCS_OAEP; break; I?m afraid not ? because currently OpenSSL does have full support for OAEP, and OpenSC has none. This is what causes the problem: OpenSSL expects the engine (libp11 and OpenSC) to handle OAEP, which they cannot do. What you propose for OpenSSL is quite a lot harder to implement well, I agree that it?s harder to implement *well*, but it is a lot simpler and shorter to implement in rsautl.c (a few lines of code), as compared to adding the whole support for OAEP to OpenSC (which ? I agree ? would be great to have, but let?s be realistic: it?s not there now). and one might also wonder why the OAEP padding should have that special treatment and no other? I?d say the same treatment is applicable to any padding that is supported by OpenSSL but not by (the majority of) PKCS#11 devices (and OpenSC). What OpenSSL does programmatically with this is (IMHO) perfect. This code works correctly with the token that only does raw RSA (the original had a lot more of error checking stuff (): privkey = ENGINE_load_private_key(e, KeyManPrivKey, NULL, &cb_data); ctx = EVP_PKEY_CTX_new(privkey, NULL); EVP_PKEY_free(privkey); rv = EVP_PKEY_decrypt_init(ctx); if (rv <= 0) goto end; rv = EVP_PKEY_CTX_set_rsa_padding(ctx, PADDING); *olen = 0; rv = EVP_PKEY_decrypt(ctx, NULL, olen, in, inlen); *out = OPENSSL_malloc(*olen); rv = EVP_PKEY_decrypt(ctx, *out, olen, in, inlen); end: Perhaps rsautl.c could do the same? Instead of what it?s doing now (aka calling RSA_private_decrypt())? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From deengert at gmail.com Thu Apr 13 21:41:35 2017 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 13 Apr 2017 16:41:35 -0500 Subject: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag In-Reply-To: <20170413.231840.1562451136092061926.levitte@openssl.org> References: <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9@ll.mit.edu> <20170413.231840.1562451136092061926.levitte@openssl.org> Message-ID: <006b8116-8aad-18f6-8759-2696ebf38de4@gmail.com> On 4/13/2017 4:18 PM, Richard Levitte wrote: > In message <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9 at ll.mit.edu> on Thu, 13 Apr 2017 20:55:36 +0000, "Blumenthal, Uri - 0553 - MITLL" said: > > uri> I am trying to use ?openssl rsautl? to wrap/unwrap symmetric keys in a script. Decryption (and encryption too, but that isn?t relevant) is done using a token accessible via pkcs11 engine (libp11). > uri> > uri> The problem is: ?rsautl? appears to assume that if ?-oaep? flag is given, then the engine is going to handle OAEP padding. This is the screen log: > uri> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -oaep -in t256.dat -out t256.dat.enc > uri> engine "pkcs11" set. > uri> $ ls -l t256.dat.enc > uri> -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep -in t256.dat.enc -out t256.dat.dec > uri> engine "pkcs11" set. > uri> PKCS#11 token PIN: > uri> PKCS#11: Unsupported padding type > uri> RSA operation error > uri> $ > uri> > uri> libp11 does not know how to deal with OAEP padding, so it returns an error. > uri> > uri> Desired solution: in case of ?-oaep? pass ?RSA_NO_PADDING? to the engine (aka to libp11), and strip the padding using OpenSSL mechanisms. > uri> > uri> I?d like to see that fixed in both 1.1 and 1.0.2 branches. > > Wouldn't it be muuuuuch easier to add the following lines: > > case RSA_PKCS1_OAEP_PADDING: > mechanism->mechanism = CKM_RSA_PKCS_OAEP; > break; > > right about here? > https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L72 > > What you propose for OpenSSL is quite a lot harder to implement well, > and one might also wonder why the OAEP padding should have that > special treatment and no other? > Because there are parameters to the OAEP, and rsautl.c does not set it. when not using an engine, rsa/rsa_pmeth.c in pkey_rsa_decrypt does something similar: 300 if (rctx->pad_mode == RSA_PKCS1_OAEP_PADDING) { 304 ret = RSA_private_decrypt(inlen, in, rctx->tbuf, 305 ctx->pkey->pkey.rsa, RSA_NO_PADDING); 312 ret = RSA_padding_check_PKCS1_OAEP_mgf1(out, ret, rctx->tbuf + i, 313 ret - i, ret, 314 rctx->oaep_label, 315 rctx->oaep_labellen, 316 rctx->md, rctx->mgf1md); > Cheers, > Richard > -- Douglas E. Engert From levitte at openssl.org Thu Apr 13 21:58:02 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 13 Apr 2017 23:58:02 +0200 (CEST) Subject: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag In-Reply-To: <006b8116-8aad-18f6-8759-2696ebf38de4@gmail.com> References: <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9@ll.mit.edu> <20170413.231840.1562451136092061926.levitte@openssl.org> <006b8116-8aad-18f6-8759-2696ebf38de4@gmail.com> Message-ID: <20170413.235802.973971291160779918.levitte@openssl.org> In message <006b8116-8aad-18f6-8759-2696ebf38de4 at gmail.com> on Thu, 13 Apr 2017 16:41:35 -0500, Douglas E Engert said: deengert> deengert> deengert> On 4/13/2017 4:18 PM, Richard Levitte wrote: deengert> > In message <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9 at ll.mit.edu> on Thu, deengert> > 13 Apr 2017 20:55:36 +0000, "Blumenthal, Uri - 0553 - MITLL" deengert> > said: deengert> > deengert> > uri> I am trying to use ?openssl rsautl? to wrap/unwrap symmetric keys deengert> > in a script. Decryption (and encryption too, but that isn?t relevant) deengert> > is done using a token accessible via pkcs11 engine (libp11). deengert> > uri> deengert> > uri> The problem is: ?rsautl? appears to assume that if ?-oaep? flag deengert> > is given, then the engine is going to handle OAEP padding. This is the deengert> > screen log: deengert> > uri> deengert> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin deengert> > -inkey deengert> > "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" deengert> > -oaep -in t256.dat -out t256.dat.enc deengert> > uri> engine "pkcs11" set. deengert> > uri> $ ls -l t256.dat.enc deengert> > uri> -rw-r--r-- 1 mouse 256 Apr 10 17:34 t256.dat.enc deengert> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey deengert> > "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep deengert> > -in t256.dat.enc -out t256.dat.dec deengert> > uri> engine "pkcs11" set. deengert> > uri> PKCS#11 token PIN: deengert> > uri> PKCS#11: Unsupported padding type deengert> > uri> RSA operation error deengert> > uri> $ deengert> > uri> deengert> > uri> libp11 does not know how to deal with OAEP padding, so it returns deengert> > an error. deengert> > uri> deengert> > uri> Desired solution: in case of ?-oaep? pass ?RSA_NO_PADDING? to the deengert> > engine (aka to libp11), and strip the padding using OpenSSL deengert> > mechanisms. deengert> > uri> deengert> > uri> I?d like to see that fixed in both 1.1 and 1.0.2 branches. deengert> > deengert> > Wouldn't it be muuuuuch easier to add the following lines: deengert> > deengert> > case RSA_PKCS1_OAEP_PADDING: deengert> > mechanism->mechanism = CKM_RSA_PKCS_OAEP; deengert> > break; deengert> > deengert> > right about here? deengert> > https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L72 deengert> > deengert> > What you propose for OpenSSL is quite a lot harder to implement well, deengert> > and one might also wonder why the OAEP padding should have that deengert> > special treatment and no other? deengert> > deengert> deengert> Because there are parameters to the OAEP, and rsautl.c does not set deengert> it. deengert> deengert> when not using an engine, rsa/rsa_pmeth.c in pkey_rsa_decrypt does deengert> something similar: deengert> deengert> 300 if (rctx->pad_mode == RSA_PKCS1_OAEP_PADDING) { deengert> deengert> 304 ret = RSA_private_decrypt(inlen, in, rctx->tbuf, deengert> 305 ctx->pkey->pkey.rsa, RSA_NO_PADDING); deengert> deengert> 312 ret = RSA_padding_check_PKCS1_OAEP_mgf1(out, ret, rctx->tbuf + i, deengert> 313 ret - i, ret, deengert> 314 rctx->oaep_label, deengert> 315 rctx->oaep_labellen, deengert> 316 rctx->md, rctx->mgf1md); Good point. But then, rsautl is a poor choice, as it uses the RSA API. For something more general and with a whole lot more functionality, pkeyutl is the better choice. Incidently, for decryption, it will end up calling exactly the code you're citing, and with -pkeyopt, you can specify the padding mode and its necessary data. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Thu Apr 13 22:16:49 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 13 Apr 2017 22:16:49 +0000 Subject: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag In-Reply-To: <20170413.235802.973971291160779918.levitte@openssl.org> References: <1EF605EC-D2DD-4D15-A27F-1E1CE7956BA9@ll.mit.edu> <20170413.231840.1562451136092061926.levitte@openssl.org> <006b8116-8aad-18f6-8759-2696ebf38de4@gmail.com> <20170413.235802.973971291160779918.levitte@openssl.org> Message-ID: <1F398E96-A7DB-4389-94BD-7F1C1AF995AA@ll.mit.edu> On 4/13/17, 5:58 PM, "openssl-dev on behalf of Richard Levitte" wrote: deengert> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey deengert> > "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep deengert> > -in t256.dat.enc -out t256.dat.dec Replacing, as Richard suggested, rsautl with pkeyutl resulted in a successful decryption of the previously encrypted message: $ openssl pkeyutl -engine pkcs11 -keyform ENGINE -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -pkeyopt rsa_padding_mode:oaep -in t256.dat.enc -out t256.dat.dec engine "pkcs11" set. Enter PKCS#11 token PIN for PIV Card Holder pin (PIV_II): $ cmp t256.dat t256.dat.dec $ . . . . . rsautl is a poor choice, as it uses the RSA API. For something more general and with a whole lot more functionality, pkeyutl is the better choice. Your suggestion worked perfectly ? I didn?t even need to provide any parameters, besides specifying the padding mode. Does it mean that rsautl is pretty much deprecated, and pkeyutl superseded it? Or is it still worth bringing it ?up to snuff?? Incidently, for decryption, it will end up calling exactly the code you're citing, ( What a coincidence! and with -pkeyopt, you can specify the padding mode and its necessary data. Yep, and thanks for the great suggestion! Now whether rsautl.c is fixed or not - is no longer critical (though since it?s still included in the codebase, perhaps it could be made more capable?). Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From levitte at openssl.org Fri Apr 14 07:47:19 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 14 Apr 2017 09:47:19 +0200 (CEST) Subject: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag In-Reply-To: <1F398E96-A7DB-4389-94BD-7F1C1AF995AA@ll.mit.edu> References: <006b8116-8aad-18f6-8759-2696ebf38de4@gmail.com> <20170413.235802.973971291160779918.levitte@openssl.org> <1F398E96-A7DB-4389-94BD-7F1C1AF995AA@ll.mit.edu> Message-ID: <20170414.094719.1912506852165545448.levitte@openssl.org> In message <1F398E96-A7DB-4389-94BD-7F1C1AF995AA at ll.mit.edu> on Thu, 13 Apr 2017 22:16:49 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> Does it mean that rsautl is pretty much deprecated, and pkeyutl superseded it? Or is it still worth bringing it ?up to snuff?? In my very personal opinion, I'd say yes, pkeyutl supersedes rsautl. I don't know if there's any operation of rsautl's that isn't implemented in pkeyutl (yet?), though. But yeah, if you ask me, I'd rather see rsautl abandoned for the benefit of pkeyutl. Team opinion may differ... the question of deprecating commands hasn't actually come up yet. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From xlyson02 at stud.fit.vutbr.cz Fri Apr 14 20:11:23 2017 From: xlyson02 at stud.fit.vutbr.cz (=?UTF-8?Q?Lyson=c4=9bk_Milan?=) Date: Fri, 14 Apr 2017 22:11:23 +0200 Subject: [openssl-dev] Testing CVE-2016-6309 In-Reply-To: <03bef12f-01b8-b683-099c-88314d686059@openssl.org> References: <20170405202402.25874xkjrj33jvpe@email.fit.vutbr.cz> <03bef12f-01b8-b683-099c-88314d686059@openssl.org> Message-ID: <0f8d20e8-9cf6-6397-554b-477c39c383b4@stud.fit.vutbr.cz> On 06/04/17 00:25 Matt Caswell wrote: > Can you reproduce it using the fuzz corpora added in commit 44f206aa9df, > or by running the large message test introduced in 84d5549e69? > > Matt > Commit 44f206aa9df - All tests from this commit give me: OSError: [Errno 8] Exec format error And I dont know, if its because my OS (Ubuntu 16.04 64bit) or I'm doing something wrong (I followed instructions from https://github.com/openssl/openssl/blob/master/fuzz/README.md ) Commit 84d5549e69 - It looks like this test reproduce it (I tried run tests with "./config","make" and then "make test") # Failed test 'running sslapitest' # at ../test/recipes/90-test_sslapi.t line 21. # Looks like you failed 1 test of 1. ../test/recipes/90-test_sslapi.t ........... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests It fails in 1.1.0a, but at 1.1.0b too, which is weird (also tried it at 1.1.0e and here it was ok). I'm not sure if I have done everything correctly in running these tests. I'm a newbie, so I apologize if I made any mistake. Milan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanjoodo at gmail.com Sat Apr 15 16:01:13 2017 From: tanjoodo at gmail.com (Mohammed) Date: Sat, 15 Apr 2017 19:01:13 +0300 Subject: [openssl-dev] Wiki adjustments Message-ID: <89e0278b-62e2-d18b-20e5-a6b0f808b42e@gmail.com> Hello, I have note about a wiki article. It's not major enough that I would want to create an account for it. I tried using the freenode IRC channel which seems big but very inactive. Here is my remark: In https://wiki.openssl.org/index.php/Android the ./config command sets --openssldir but not --prefix which causes issues in 1.1.0 apparently. If you could just change the commands to have --prefix contain the same value as --openssldir it would be great. According to this page, this is the rule of thumb https://wiki.openssl.org/index.php/Compilation_and_Installation#PREFIX_and_OPENSSLDIR Regards, Mohammed Arabiat From raja.ashok at huawei.com Mon Apr 17 16:08:33 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Mon, 17 Apr 2017 16:08:33 +0000 Subject: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow Message-ID: Hi All, I am having a doubt BUF_MEM_grow and BUF_MEM_grow_clean. After reallocation of buffer we are memsetting the buffer from ??str->length?? index. } else { str->data = ret; str->max = n; memset(&str->data[str->length], 0, len - str->length); str->length = len; } I feel we should memset from ??str->max??. 1) One usage of this BUF_MEM is init buffer (s->init_buf) in SSL handshake for storing peer??s message and framing response message. 2) Initially in ssl3_connect and ssl3_accept we are creating this s->init_buf of size 16348 bytes. 3) Later in ssl3_get_message we are using this buffer for receiving peer??s handshake message of length ??l??. Here we are calling BUF_MEM_grow_clean with ??(l + 4 + 16)?? as length. If (l + 4 +16) is lesser than 16348, then ??init_buf->length?? is set to that. 4) After parsing the received msg and we are framing the response message on the same s->init_buf. For example consider ssl3_send_certificate_request, here we are copying Cert types and sign hash algorithm, after that we are calling mem grow before copying X509 name of CA cert. 5) Here, if the data (cert types and sign hash alg) copied before calling mem grow is more than (l + 4 + 16) of previously received msg, then it will leads to some data loss inside BUF_MEM_grow_clean we are memsetting from ??data[str->length]??. In OpenSSL, BUF_MEM is used in many modules like ASN, PEM and SSL. So as per my understanding better we should memset from ??max?? index in case of realloc, like below pseudocode. } else { str->data = ret; memset(&str->data[str->max], 0, n ?C str->max); str->max = n; str->length = len; } This we should not do for OPENSSL_malloc, in that case we can memset complete buffer. Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: From rsalz at akamai.com Mon Apr 17 16:32:20 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 17 Apr 2017 16:32:20 +0000 Subject: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow In-Reply-To: References: Message-ID: <401e90cc43994892bb7524397353c0a4@ustx2ex-dag1mb1.msg.corp.akamai.com> >??????? memset(&str->data[str->length], 0, len - str->length); The intent is to blank out everything from what was currently written. This "covers up" possible pointer over-runs. We could do just from the old max. From matt at openssl.org Tue Apr 18 09:38:16 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 18 Apr 2017 10:38:16 +0100 Subject: [openssl-dev] Testing CVE-2016-6309 In-Reply-To: <0f8d20e8-9cf6-6397-554b-477c39c383b4@stud.fit.vutbr.cz> References: <20170405202402.25874xkjrj33jvpe@email.fit.vutbr.cz> <03bef12f-01b8-b683-099c-88314d686059@openssl.org> <0f8d20e8-9cf6-6397-554b-477c39c383b4@stud.fit.vutbr.cz> Message-ID: On 14/04/17 21:11, Lyson?k Milan wrote: > > On 06/04/17 00:25 Matt Caswell wrote: >> Can you reproduce it using the fuzz corpora added in commit 44f206aa9df, >> or by running the large message test introduced in 84d5549e69? >> >> Matt >> > > Commit 44f206aa9df - All tests from this commit give me: > > OSError: [Errno 8] Exec format error > > And I dont know, if its because my OS (Ubuntu 16.04 64bit) or I'm doing > something wrong (I followed instructions from > https://github.com/openssl/openssl/blob/master/fuzz/README.md ) > > > Commit 84d5549e69 - It looks like this test reproduce it (I tried run > tests with "./config","make" and then "make test") > > # Failed test 'running sslapitest' > # at ../test/recipes/90-test_sslapi.t line 21. > # Looks like you failed 1 test of 1. > ../test/recipes/90-test_sslapi.t ........... Dubious, test returned > 1 (wstat 256, 0x100) > Failed 1/1 subtests > > It fails in 1.1.0a, but at 1.1.0b too, which is weird (also tried it at > 1.1.0e and here it was ok). Well that doesn't sound right because that commit is already in 1.1.0b. In the 1.1.0 tree it appears as commit df7681e46 (which is just a cherry-pick of 84d5549e69). So you shouldn't need to do anything special to test this in 1.1.0b - just checkout that version, compile and run the tests. sslapitest should pass if all is well (it does for me and I don't believe we had any other reports of problems). Matt From nia13paulino at gmail.com Tue Apr 18 18:44:00 2017 From: nia13paulino at gmail.com (Nia Paulino) Date: Tue, 18 Apr 2017 11:44:00 -0700 Subject: [openssl-dev] (no subject) Message-ID: Open device for new account thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at leonklingele.de Wed Apr 19 11:09:33 2017 From: mail at leonklingele.de (Leon Klingele) Date: Wed, 19 Apr 2017 13:09:33 +0200 Subject: [openssl-dev] ETA: TLS 1.3 release Message-ID: Out of curiosity, what's the ETA for TLS 1.3? [1] mentions April 5 as the release date (which was two weeks ago). [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rsalz at akamai.com Wed Apr 19 12:14:17 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 19 Apr 2017 12:14:17 +0000 Subject: [openssl-dev] ETA: TLS 1.3 release In-Reply-To: References: Message-ID: > Out of curiosity, what's the ETA for TLS 1.3? > [1] mentions April 5 as the release date (which was two weeks ago). > > [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html That's an akamai blog, not an openssl statement :) And that post is misleading, it should have said "available" not "released." The code is in master. No date on a specific openssl release yet. From stefan.eissing at greenbytes.de Wed Apr 19 12:57:13 2017 From: stefan.eissing at greenbytes.de (Stefan Eissing) Date: Wed, 19 Apr 2017 14:57:13 +0200 Subject: [openssl-dev] ETA: TLS 1.3 release In-Reply-To: References: Message-ID: <62C0C979-589A-4D74-8D10-8DC63DF62032@greenbytes.de> > Am 19.04.2017 um 14:14 schrieb Salz, Rich via openssl-dev : > >> Out of curiosity, what's the ETA for TLS 1.3? >> [1] mentions April 5 as the release date (which was two weeks ago). >> >> [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html > > That's an akamai blog, not an openssl statement :) And that post is misleading, it should have said "available" not "released." Ok, let me announce then that Apache httpd then also has TLSv1.3 support "available". But our code is in trunk and 2.4.x. ;-P -Stefan > > The code is in master. > > No date on a specific openssl release yet. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From kurt at roeckx.be Wed Apr 19 21:47:48 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 19 Apr 2017 23:47:48 +0200 Subject: [openssl-dev] ETA: TLS 1.3 release In-Reply-To: <62C0C979-589A-4D74-8D10-8DC63DF62032@greenbytes.de> References: <62C0C979-589A-4D74-8D10-8DC63DF62032@greenbytes.de> Message-ID: <20170419214748.me55ir42mzl6r5p6@roeckx.be> On Wed, Apr 19, 2017 at 02:57:13PM +0200, Stefan Eissing wrote: > > > Am 19.04.2017 um 14:14 schrieb Salz, Rich via openssl-dev : > > > >> Out of curiosity, what's the ETA for TLS 1.3? > >> [1] mentions April 5 as the release date (which was two weeks ago). > >> > >> [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html > > > > That's an akamai blog, not an openssl statement :) And that post is misleading, it should have said "available" not "released." > > Ok, let me announce then that Apache httpd then also has TLSv1.3 support "available". But our code is in trunk and 2.4.x. And when can we expect a release of that? :) (As in a release that supports OpenSSL 1.1) Kurt From wrowe at rowe-clan.net Thu Apr 20 02:02:57 2017 From: wrowe at rowe-clan.net (William A Rowe Jr) Date: Wed, 19 Apr 2017 21:02:57 -0500 Subject: [openssl-dev] ETA: TLS 1.3 release In-Reply-To: <20170419214748.me55ir42mzl6r5p6@roeckx.be> References: <62C0C979-589A-4D74-8D10-8DC63DF62032@greenbytes.de> <20170419214748.me55ir42mzl6r5p6@roeckx.be> Message-ID: There is motion towards a 2.4.26 release around month end, give or take two weeks. On Apr 19, 2017 4:57 PM, "Kurt Roeckx" wrote: > On Wed, Apr 19, 2017 at 02:57:13PM +0200, Stefan Eissing wrote: > > > > > Am 19.04.2017 um 14:14 schrieb Salz, Rich via openssl-dev < > openssl-dev at openssl.org>: > > > > > >> Out of curiosity, what's the ETA for TLS 1.3? > > >> [1] mentions April 5 as the release date (which was two weeks ago). > > >> > > >> [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html > > > > > > That's an akamai blog, not an openssl statement :) And that post is > misleading, it should have said "available" not "released." > > > > Ok, let me announce then that Apache httpd then also has TLSv1.3 support > "available". But our code is in trunk and 2.4.x. > > And when can we expect a release of that? :) > > (As in a release that supports OpenSSL 1.1) > > > Kurt > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raja.ashok at huawei.com Thu Apr 20 08:13:39 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Thu, 20 Apr 2017 08:13:39 +0000 Subject: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow In-Reply-To: <401e90cc43994892bb7524397353c0a4@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <401e90cc43994892bb7524397353c0a4@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Hi Salz, I raised a PR for this change. Already got some comments from Kurt. Requesting you also to check and provide your suggestions on it. https://github.com/openssl/openssl/pull/3255 Currently raised PR on only 1.0.2. Once its reviewed, I can raise on other branches (1.1.0 and Master). Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-dev Sent: 17 April 2017 22:02 To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow >??????? memset(&str->data[str->length], 0, len - str->length); The intent is to blank out everything from what was currently written. This "covers up" possible pointer over-runs. We could do just from the old max. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rsalz at akamai.com Thu Apr 20 14:28:43 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 20 Apr 2017 14:28:43 +0000 Subject: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow In-Reply-To: References: <401e90cc43994892bb7524397353c0a4@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <6549d6aaab4948588b79e857532881f0@usma1ex-dag1mb1.msg.corp.akamai.com> > Requesting you also to check and provide your suggestions on it. > https://github.com/openssl/openssl/pull/3255 As Matt and Kurt have said, this seems to be 'covering up' real bugs in the source. It doesn't seem like a good idea. From rsalz at akamai.com Thu Apr 20 20:06:49 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 20 Apr 2017 20:06:49 +0000 Subject: [openssl-dev] Wiki adjustments In-Reply-To: <89e0278b-62e2-d18b-20e5-a6b0f808b42e@gmail.com> References: <89e0278b-62e2-d18b-20e5-a6b0f808b42e@gmail.com> Message-ID: <01fe21e335c941cfabc695e60b260e8d@usma1ex-dag1mb3.msg.corp.akamai.com> > In https://wiki.openssl.org/index.php/Android the ./config command sets -- > openssldir but not --prefix which causes issues in 1.1.0 apparently. Fixed, thank you ! From tanjoodo at gmail.com Thu Apr 20 20:23:38 2017 From: tanjoodo at gmail.com (Mohammed Arabiat) Date: Thu, 20 Apr 2017 23:23:38 +0300 Subject: [openssl-dev] Wiki adjustments In-Reply-To: <01fe21e335c941cfabc695e60b260e8d@usma1ex-dag1mb3.msg.corp.akamai.com> References: <89e0278b-62e2-d18b-20e5-a6b0f808b42e@gmail.com> <01fe21e335c941cfabc695e60b260e8d@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: Thank you for taking the time to fix it. On Apr 20, 2017 23:07, "Salz, Rich via openssl-dev" wrote: > > In https://wiki.openssl.org/index.php/Android the ./config command sets > -- > > openssldir but not --prefix which causes issues in 1.1.0 apparently. > > Fixed, thank you ! > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Thu Apr 20 20:24:51 2017 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 20 Apr 2017 21:24:51 +0100 Subject: [openssl-dev] ETA: TLS 1.3 release In-Reply-To: References: Message-ID: <1492719891.8404.18.camel@infradead.org> On Wed, 2017-04-19 at 12:14 +0000, Salz, Rich via openssl-dev wrote: > > Out of curiosity, what's the ETA for TLS 1.3? > > [1] mentions April 5 as the release date (which was two weeks ago). > >? > > [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html > > That's an akamai blog, not an openssl statement :)? And that post is > misleading, it should have said "available" not "released." > > The code is in master. Have the DTLS_get_data_mtu() and related tests been expanded to cover it? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4938 bytes Desc: not available URL: From matt at openssl.org Fri Apr 21 08:46:47 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 21 Apr 2017 09:46:47 +0100 Subject: [openssl-dev] ETA: TLS 1.3 release In-Reply-To: <1492719891.8404.18.camel@infradead.org> References: <1492719891.8404.18.camel@infradead.org> Message-ID: <432aef29-a2d2-43aa-8e73-abc2cda24f07@openssl.org> On 20/04/17 21:24, David Woodhouse wrote: > On Wed, 2017-04-19 at 12:14 +0000, Salz, Rich via openssl-dev wrote: >>> Out of curiosity, what's the ETA for TLS 1.3? >>> [1] mentions April 5 as the release date (which was two weeks ago). >>> >>> [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html >> >> That's an akamai blog, not an openssl statement :) And that post is >> misleading, it should have said "available" not "released." >> >> The code is in master. > > Have the DTLS_get_data_mtu() and related tests been expanded to cover > it? We are implementing *TLS* 1.3 not *DTLS* 1.3 (which is still in its early stages) - so no changes should be required to those tests. Just to build on Rich's original answer: the TLS1.3 spec has not been finalised by IETF yet. They were still making significant changes until quite recently (e.g. draft-19 is not compatible with draft-18). There won't be an OpenSSL release (at least) until we have a final version of the spec. Matt From doctor at doctor.nl2k.ab.ca Sat Apr 22 06:26:14 2017 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 22 Apr 2017 00:26:14 -0600 Subject: [openssl-dev] 2 snapshots did not generate accordingly Message-ID: <20170422062614.GA23087@doctor.nl2k.ab.ca> openssl-1.0.2-stable-SNAP-20170422.tar.gz and openssl-1.1.0-stable-SNAP-20170422.tar.gz did not generate accordingly. They are at 0 bytes -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism BC Keep your province Healthy!! Vote Liberal. From levitte at openssl.org Sat Apr 22 07:10:56 2017 From: levitte at openssl.org (Richard Levitte) Date: Sat, 22 Apr 2017 09:10:56 +0200 (CEST) Subject: [openssl-dev] 2 snapshots did not generate accordingly In-Reply-To: <20170422062614.GA23087@doctor.nl2k.ab.ca> References: <20170422062614.GA23087@doctor.nl2k.ab.ca> Message-ID: <20170422.091056.225315493378434981.levitte@openssl.org> In message <20170422062614.GA23087 at doctor.nl2k.ab.ca> on Sat, 22 Apr 2017 00:26:14 -0600, The Doctor said: doctor> openssl-1.0.2-stable-SNAP-20170422.tar.gz doctor> doctor> and doctor> doctor> openssl-1.1.0-stable-SNAP-20170422.tar.gz doctor> doctor> did not generate accordingly. doctor> doctor> They are at 0 bytes Thanks for notifying us. The disk had filled up, I'm cleaning up. I'll remove those empty tarballs, there will be new ones tomorrow. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From doctor at doctor.nl2k.ab.ca Sat Apr 22 12:20:16 2017 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 22 Apr 2017 06:20:16 -0600 Subject: [openssl-dev] 2 snapshots did not generate accordingly In-Reply-To: <20170422.091056.225315493378434981.levitte@openssl.org> References: <20170422062614.GA23087@doctor.nl2k.ab.ca> <20170422.091056.225315493378434981.levitte@openssl.org> Message-ID: <20170422122016.GA88593@doctor.nl2k.ab.ca> On Sat, Apr 22, 2017 at 09:10:56AM +0200, Richard Levitte wrote: > In message <20170422062614.GA23087 at doctor.nl2k.ab.ca> on Sat, 22 Apr 2017 00:26:14 -0600, The Doctor said: > > doctor> openssl-1.0.2-stable-SNAP-20170422.tar.gz > doctor> > doctor> and > doctor> > doctor> openssl-1.1.0-stable-SNAP-20170422.tar.gz > doctor> > doctor> did not generate accordingly. > doctor> > doctor> They are at 0 bytes > > Thanks for notifying us. The disk had filled up, I'm cleaning up. > I'll remove those empty tarballs, there will be new ones tomorrow. > > Cheers, > Richard > Thankyou And What happened to openssl 1.0.1 ? > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism BC Keep your province Healthy!! Vote Liberal. From rsalz at akamai.com Sat Apr 22 12:31:42 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 22 Apr 2017 12:31:42 +0000 Subject: [openssl-dev] 2 snapshots did not generate accordingly In-Reply-To: <20170422122016.GA88593@doctor.nl2k.ab.ca> References: <20170422062614.GA23087@doctor.nl2k.ab.ca> <20170422.091056.225315493378434981.levitte@openssl.org> <20170422122016.GA88593@doctor.nl2k.ab.ca> Message-ID: <1914c34d74694a768307358d80d4a2b7@usma1ex-dag1mb1.msg.corp.akamai.com> > And What happened to openssl 1.0.1 ? We stopped supporting it back in December. From rsalz at akamai.com Sat Apr 22 12:42:16 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 22 Apr 2017 12:42:16 +0000 Subject: [openssl-dev] Code heatlh delayed a week Message-ID: <779cb491262b4ac79be7215fa8067fb6@usma1ex-dag1mb1.msg.corp.akamai.com> We are still reviewing several PR's from the previous code health, which was about converting tests to use the new test framework. With this extended time period, we'll have ended up converting almost all the tests, which is great. We'll announce the next project toward the end of the week. Thanks for all your participation, folks! -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Apr 22 13:35:05 2017 From: levitte at openssl.org (Richard Levitte) Date: Sat, 22 Apr 2017 15:35:05 +0200 (CEST) Subject: [openssl-dev] 2 snapshots did not generate accordingly In-Reply-To: <1914c34d74694a768307358d80d4a2b7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170422.091056.225315493378434981.levitte@openssl.org> <20170422122016.GA88593@doctor.nl2k.ab.ca> <1914c34d74694a768307358d80d4a2b7@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20170422.153505.210558776929913311.levitte@openssl.org> In message <1914c34d74694a768307358d80d4a2b7 at usma1ex-dag1mb1.msg.corp.akamai.com> on Sat, 22 Apr 2017 12:31:42 +0000, "Salz, Rich" said: rsalz> > And What happened to openssl 1.0.1 ? rsalz> rsalz> We stopped supporting it back in December. We were still building snapshots for it, though. I've adjusted the script today and removed all present 1.0.1 snapshots (that's the answer for you, Doc) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Sat Apr 22 19:44:40 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 22 Apr 2017 21:44:40 +0200 Subject: [openssl-dev] OpenSSL Project Bylaws In-Reply-To: <6a9d61ca-923a-e4ce-f91b-421a77f83f97@openssl.org> References: <6a9d61ca-923a-e4ce-f91b-421a77f83f97@openssl.org> Message-ID: <20170422194440.crs6fjmobxzeveue@roeckx.be> On Tue, Feb 14, 2017 at 09:30:31AM +0000, Matt Caswell wrote: > I am pleased to be able to announce the publication of our new Project > Bylaws. I have written a short blog post about what we are hoping to > achieve and some of the thinking that went into these here: > > https://www.openssl.org/blog/blog/2017/02/13/bylaws/ > > The bylaws themselves are available here: > > https://www.openssl.org/policies/bylaws.html > > The Project Bylaws describe how the OpenSSL Project operates, what the > different project roles are and how decisions are made. Incidentally > these project bylaws should not be confused with the OpenSSL Software > Foundation (OSF) Bylaws which were also recently published and describe > how that legal entity operates. We have also published a guideline for commiters here: https://www.openssl.org/policies/committers.html Kurt From matt at openssl.org Thu Apr 27 07:43:18 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 27 Apr 2017 08:43:18 +0100 Subject: [openssl-dev] Code Health Tuesday - old issues Message-ID: Hi all Our next "Code Health Tuesday" event will be on Tuesday 2nd May. This time we would like to focus on closing off Github issues (with a particular focus on old ones - including all those we brought over from RT). Thanks! Matt FAQ: Q: How do I participate? A: Review the old issues in Github. If an issue can be closed then post a comment in the issue suggesting its closure along with your reasons. If an issue still needs to be fixed then raise a PR to fix it and include "Fixes #XXX" in the commit message (where XXX is the issue number) Include the words "code health" in the PR title. Q: Which branches should I target? A: Any currently supported branch (i.e. master, 1.1.0 and 1.0.2) where the issue applies Q: What are good reasons for recommending the closure of an issue? A: There are lots of possible reasons. Some are: - It has already been fixed - It is no longer relevant - It does not affect currently supported versions (master, 1.1.0 and 1.02) - We can no longer reproduce it - The issue is incorrect - It is a duplicate of some other issue Q: How do I find the issues that were brought over from RT? A: Use this link: https://github.com/openssl/openssl/issues?q=is%3Aissue%20is%3Aopen%20rt