[openssl-dev] [openssl.org #4626] Re: Are the point-at-infinity checks in ecp_nistz256 correct?

[Brian Smith via RT]

Brian Smith  wrote:
> The issue is particularly clear when we multiply the generator by
> zero. Note that in general, an application shouldn't multiply the
> generator by zero since there's no useful cryptographic purpose for
> doing so. But, this is a convenient example.

Sorry, I was wrong. From the definition of ECDSA:

H = Hash(M).
Convert the bit string H to an integer e.
w = s**−1 mod n
u1 = (e * w) mod n
R = u1*G + u2*Q

If the highest 256 bits of Hash(M) are zero, then e == 0 and then u1
== 0 * w == 0. So, it probably is important to handle g_scalar == 0 in
the way I described in my earlier message, using the conditional copy.

Cheers,
Brian


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4626
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?

[Brian Smith]

Brian Smith  wrote:
> The issue is particularly clear when we multiply the generator by
> zero. Note that in general, an application shouldn't multiply the
> generator by zero since there's no useful cryptographic purpose for
> doing so. But, this is a convenient example.

Sorry, I was wrong. From the definition of ECDSA:

H = Hash(M).
Convert the bit string H to an integer e.
w = s**−1 mod n
u1 = (e * w) mod n
R = u1*G + u2*Q

If the highest 256 bits of Hash(M) are zero, then e == 0 and then u1
== 0 * w == 0. So, it probably is important to handle g_scalar == 0 in
the way I described in my earlier message, using the conditional copy.

Cheers,
Brian
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

[David Benjamin via RT]

On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT  wrote:

> On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> > > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > > been
> >
> > > introduced in commit:
> > I tried what I thought was a fix for this which is to simply delete the
> > lines:
> >
> > if (decrypt_len < 0)
> > goto err;
> >
> > from ssl/statem/statem_srvr.c
> >
> > However your reproducer still indicates errors. I checked the message
> logs
> > and it should be now sending as many alerts as the original. The
> difference
> > however is that some of them will be sent immediately whereas originally
> > they would be at the end of the handshake.
> >
> > Could your reproducer possibly not be expecting this?
>
>
> sorry, I copied this part:
>
> > when the OpenSSL receives a Client Key Exchange message that has the
> > encrypted
> > premaster secret comprised only of zero bytes, or equal to server's
> modulus,
> > the server just aborts the connection without sending an Alert message
>
> from the DHE/ECDHE bug reports
>
> the expected behaviour is to continue the connection, but the server should
> select a premaster secret that was not provided by the client, instead
> OpenSSL
> just closes the connection
>

I don't believe this test is correct if the encrypted premaster is equal to
the server's modulus. Such an encrypted premaster is a publicly invalid RSA
ciphertext. It is perfectly reasonable to reject it early, should unpadded
RSA_decrypt fail. The timing sensitive portion is the padding check itself,
which this code should correctly defer failure of, to avoid the padding
oracle.

The reason public decrypt failures did not trigger early alerts before was
because the old code was a little sloppy about error-handling. In addition
to not being constant time, it squashed together codepaths for publicly
invalid keys and the timing sensitive check.

It is true that it no longer sends an alert on public failures. Probably
worth fixing. Meh.

David

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4625] Re: Are the point-at-infinity checks in ecp_nistz256 correct?

[Brian Smith via RT]

The issue is particularly clear when we multiply the generator by
zero. Note that in general, an application shouldn't multiply the
generator by zero since there's no useful cryptographic purpose for
doing so. But, this is a convenient example.

In the code we have,

ecp_nistz256_gather_w7(, preComputedTable[0], wvalue >> 1);
ecp_nistz256_neg(p.p.Z, p.p.Y);
copy_conditional(p.p.Y, p.p.Z, wvalue & 1);
memcpy(p.p.Z, ONE, sizeof(ONE));

The generator is all zeros, so we'll start off with the point (0, 0,
1). Then we add the point at infinity over and over again, leaving
that point unchanged each time. Thus, we'll end with (0, 0, 1). Then:

r->Z_is_one = is_one(p.p.Z) & 1;

Thus, the resulting point will be (0, 0, 1).

After the memcpy quoted above, we need to do a copy_conditional(p.p.Z,
is_infinity, ZERO) or equivalent, where ZERO is all-zeros and where
is_infinity is the result of checking if (x, y) == (0, 0).

This is just one example of an edge case that is handled in a
surprising way. I think there are more, as described in the quoted
message below.

Cheers,
Brian


Brian Smith  wrote:
>
> Brian Smith  wrote:
>>
>> When doing math on short Weierstrass curves like P-256, we have to
>> special case points at infinity. In Jacobian coordinates (X, Y, Z),
>> points at infinity have Z == 0. However, instead of checking for Z ==
>> 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it
>> does, in some sense, the opposite of what I expect it to do.
>
>
> I exchanged email with both of the original authors of the code, Shay and 
> Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent 
> the point at infinity as (0, 0) and it is expected (but I did not verify) 
> that those functions should work when the point at infinity is encoded as (0, 
> 0, _).
>
>> The authors
>> instead decided to encode the point at infinity as (0, 0), since the
>> affine point (0, 0) isn't on the P-256 curve. It isn't clear why the
>> authors chose to do that though, since the point at infinity doesn't
>> (can't, logically) appear in the table of precomputed multiples of G
>> anyway.
>
>
> Actually, as the code says, the point at infinity implicitly occurs in the 
> table implicitly. Obviously the accumulator point will be at infinity until 
> at least a one bit is found in the scalar.
>
>>
>> But, it seems like the functions that do the computations, like
>>
>> ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the
>> point at infinity as (_, _, 0), not necessarily (0, 0, _). Also,
>> ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and
>> ec_GFp_simple_point_set_to_infinity, which represent the point at
>> infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine
>> uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0.
>> This inconsistency is confusing, if not wrong. Given this, it seems
>> like the point-at-infinity checks in the ecp_nistz256_point_add and
>> ecp_nistz256_point_add_affine code should also be checking that z == 0
>> instead of (x, y) == (0, 0).
>
>
> Instead, when we convert a point from EC_POINT to P256_POINT or 
> P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0, 0) 
> form. And/or reject points at infinity as inputs to the function. Similarly, 
> when we convert the resultant P256_POINT to an EC_POINT, we chould translate 
> the (0, 0) encoding of the point at infinity to the (0, 0, 0) form or at 
> least the (_, _, 0) form.
>
> In particular, consider the case where you have an EC_POINT that isn't at 
> infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it. Then 
> it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even though 
> you shouldn't.
>
> Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the 
> input points are at infinity, in which case it doesn't matter. (But if so, 
> maybe these functions should do a point-at-infinity check.) But if it is 
> allowed to pass in the point at infinity, then the ecp_nistz256 code should 
> translate the input point from (_, _, 0) form to (0, 0, _) form before doing 
> the computation. It can use is_zero and copy_conditional and friends to do 
> this.
>
> Similarly, after the computation, it should translate the (0, 0, _) form to 
> (_, _, 0) form. In particular, it should do such a translation before the 
> code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the 
> form (0, 0, 0) instead of (0, 0, _) in which case this translation might not 
> be necessary.
>
> Regardless, it would be useful to write tests for these cases:
> 1. Verify that the result is correct when any of the input points are (0, 0, 
> 0)
> 2. Verify that the result is correct when any of the input points are (_, _, 
> 0).
> 3. Verify that the result is correct, and in particular that Z_is_one is set 
> correctly on the result, when the final result is at 

Re: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?

[Brian Smith]

The issue is particularly clear when we multiply the generator by
zero. Note that in general, an application shouldn't multiply the
generator by zero since there's no useful cryptographic purpose for
doing so. But, this is a convenient example.

In the code we have,

ecp_nistz256_gather_w7(, preComputedTable[0], wvalue >> 1);
ecp_nistz256_neg(p.p.Z, p.p.Y);
copy_conditional(p.p.Y, p.p.Z, wvalue & 1);
memcpy(p.p.Z, ONE, sizeof(ONE));

The generator is all zeros, so we'll start off with the point (0, 0,
1). Then we add the point at infinity over and over again, leaving
that point unchanged each time. Thus, we'll end with (0, 0, 1). Then:

r->Z_is_one = is_one(p.p.Z) & 1;

Thus, the resulting point will be (0, 0, 1).

After the memcpy quoted above, we need to do a copy_conditional(p.p.Z,
is_infinity, ZERO) or equivalent, where ZERO is all-zeros and where
is_infinity is the result of checking if (x, y) == (0, 0).

This is just one example of an edge case that is handled in a
surprising way. I think there are more, as described in the quoted
message below.

Cheers,
Brian


Brian Smith  wrote:
>
> Brian Smith  wrote:
>>
>> When doing math on short Weierstrass curves like P-256, we have to
>> special case points at infinity. In Jacobian coordinates (X, Y, Z),
>> points at infinity have Z == 0. However, instead of checking for Z ==
>> 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it
>> does, in some sense, the opposite of what I expect it to do.
>
>
> I exchanged email with both of the original authors of the code, Shay and 
> Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent 
> the point at infinity as (0, 0) and it is expected (but I did not verify) 
> that those functions should work when the point at infinity is encoded as (0, 
> 0, _).
>
>> The authors
>> instead decided to encode the point at infinity as (0, 0), since the
>> affine point (0, 0) isn't on the P-256 curve. It isn't clear why the
>> authors chose to do that though, since the point at infinity doesn't
>> (can't, logically) appear in the table of precomputed multiples of G
>> anyway.
>
>
> Actually, as the code says, the point at infinity implicitly occurs in the 
> table implicitly. Obviously the accumulator point will be at infinity until 
> at least a one bit is found in the scalar.
>
>>
>> But, it seems like the functions that do the computations, like
>>
>> ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the
>> point at infinity as (_, _, 0), not necessarily (0, 0, _). Also,
>> ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and
>> ec_GFp_simple_point_set_to_infinity, which represent the point at
>> infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine
>> uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0.
>> This inconsistency is confusing, if not wrong. Given this, it seems
>> like the point-at-infinity checks in the ecp_nistz256_point_add and
>> ecp_nistz256_point_add_affine code should also be checking that z == 0
>> instead of (x, y) == (0, 0).
>
>
> Instead, when we convert a point from EC_POINT to P256_POINT or 
> P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0, 0) 
> form. And/or reject points at infinity as inputs to the function. Similarly, 
> when we convert the resultant P256_POINT to an EC_POINT, we chould translate 
> the (0, 0) encoding of the point at infinity to the (0, 0, 0) form or at 
> least the (_, _, 0) form.
>
> In particular, consider the case where you have an EC_POINT that isn't at 
> infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it. Then 
> it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even though 
> you shouldn't.
>
> Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the 
> input points are at infinity, in which case it doesn't matter. (But if so, 
> maybe these functions should do a point-at-infinity check.) But if it is 
> allowed to pass in the point at infinity, then the ecp_nistz256 code should 
> translate the input point from (_, _, 0) form to (0, 0, _) form before doing 
> the computation. It can use is_zero and copy_conditional and friends to do 
> this.
>
> Similarly, after the computation, it should translate the (0, 0, _) form to 
> (_, _, 0) form. In particular, it should do such a translation before the 
> code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the 
> form (0, 0, 0) instead of (0, 0, _) in which case this translation might not 
> be necessary.
>
> Regardless, it would be useful to write tests for these cases:
> 1. Verify that the result is correct when any of the input points are (0, 0, 
> 0)
> 2. Verify that the result is correct when any of the input points are (_, _, 
> 0).
> 3. Verify that the result is correct, and in particular that Z_is_one is set 
> correctly on the result, when the final result is at 

[openssl-dev] [openssl.org #4599] big CRLs problem with openssl 1.0.2h

[Stephen Henson via RT]

This is a known issue which is fixed in the current snapshots. Commit
a1eef756cc1948ed4d1f addresses it.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4599
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Salz, Rich]

I understand, and I think Richard will provide the hooks you need.

But this is, as you say, stuff that is eight years old
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4619] compile errors with no-srp

[Richard Levitte via RT]

It's a spelling error. Fix in https://github.com/openssl/openssl/pull/1341

Cheers,
Richard

On Wed Jul 20 21:45:53 2016, c...@five-ten-sg.com wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Source from master on github,
>
> ./Configure --prefix=/usr/local --openssldir=/usr/local/etc/pki/tls
> enable-ec_nistp_64_gcc_128 zlib sctp enable-camellia enable-seed enable-
> rfc3779 enable-cms enable-md2 no-mdc2 no-rc5 no-ec2m no-gost no-srp -Wa,
> - --noexecstack -DPURIFY enable-deprecated shared linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> no-asan [default] OPENSSL_NO_ASAN (skip dir)
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [default]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> no-ec2m [option] OPENSSL_NO_EC2M (skip dir)
> no-egd [default] OPENSSL_NO_EGD (skip dir)
> no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
> no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
> no-gost [option] OPENSSL_NO_GOST (skip dir)
> no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir)
> no-rc5 [option] OPENSSL_NO_RC5 (skip dir)
> no-srp [option] OPENSSL_NO_SRP (skip dir)
> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
> no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
> no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip
> dir)
> no-zlib-dynamic [default]
>
>
> make depend
> make all
> 
>
> gcc -I. -Iinclude -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG
> - -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
> - -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> - -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> - -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> - -DPOLY1305_ASM -DPURIFY -DOPENSSLDIR="\"/usr/local/etc/pki/tls\""
> - -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wall -O3 -pthread
> -m64
> - -DL_ENDIAN -Wa,--noexecstack -fPIC -MMD -MF ssl/t1_ext.d.tmp -MT
> ssl/t1_ext.o -c -o ssl/t1_ext.o ssl/t1_ext.c
> ssl/statem/statem_clnt.c: In function 'tls_construct_cke_srp':
> ssl/statem/statem_clnt.c:2455: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2457: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2459: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2465: error: 'SSL_SESSION' has no member named
> 'srp_username'
> ssl/statem/statem_clnt.c:2466: error: 'SSL_SESSION' has no member named
> 'srp_username'
> ssl/statem/statem_clnt.c:2466: error: 'SSL' has no member named
> 'srp_ctx'
> ssl/statem/statem_clnt.c:2467: error: 'SSL_SESSION' has no member named
> 'srp_username'
> make[2]: *** [ssl/statem/statem_clnt.o] Error 1
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAleP41cACgkQL6j7milTFsHYBACdGbcmT0xsANaKhaFz7pGNoU2F
> R3cAnif6xhWLvWjTUMPkNfv/+rYV7yMc
> =NEzZ
> -END PGP SIGNATURE-
>
>


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4619
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Richard Levitte via RT]

On Fri Jul 22 12:52:18 2016, rs...@akamai.com wrote:
> And now, with subject clearly stated, I think we should not do this.

After some discussion, we decided to abandon this line of thought and get back
to accessors as off RT4602.

Closing this ticket.

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

[Hubert Kario via RT]

On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > been
> 
> > introduced in commit:
> I tried what I thought was a fix for this which is to simply delete the
> lines:
> 
> if (decrypt_len < 0)
> goto err;
> 
> from ssl/statem/statem_srvr.c
> 
> However your reproducer still indicates errors. I checked the message logs
> and it should be now sending as many alerts as the original. The difference
> however is that some of them will be sent immediately whereas originally
> they would be at the end of the handshake.
> 
> Could your reproducer possibly not be expecting this?


sorry, I copied this part:

> when the OpenSSL receives a Client Key Exchange message that has the
> encrypted
> premaster secret comprised only of zero bytes, or equal to server's modulus,
> the server just aborts the connection without sending an Alert message

from the DHE/ECDHE bug reports

the expected behaviour is to continue the connection, but the server should 
select a premaster secret that was not provided by the client, instead OpenSSL 
just closes the connection
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

[Hubert Kario via RT]

On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > been
> 
> > introduced in commit:
> I tried what I thought was a fix for this which is to simply delete the
> lines:
> 
> if (decrypt_len < 0)
> goto err;
> 
> from ssl/statem/statem_srvr.c
> 
> However your reproducer still indicates errors. I checked the message logs
> and it should be now sending as many alerts as the original. The difference
> however is that some of them will be sent immediately whereas originally
> they would be at the end of the handshake.
> 
> Could your reproducer possibly not be expecting this?

yes, it expects to be hitting the Bleichenbacher workaround - use of different 
premaster secret in case of problems with CKE message - as it's the same 
behaviour OpenSSL, NSS and GnuTLS exhibit

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

[Stephen Henson via RT]

On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> the issue is present in master 0ed26acce328ec16a3aa and looks to have
> been
> introduced in commit:
>

I tried what I thought was a fix for this which is to simply delete the lines:

if (decrypt_len < 0)
goto err;

from ssl/statem/statem_srvr.c

However your reproducer still indicates errors. I checked the message logs and
it should be now sending as many alerts as the original. The difference however
is that some of them will be sent immediately whereas originally they would be
at the end of the handshake.

Could your reproducer possibly not be expecting this?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

Hi, 

Good point, I'll look into that. Also, thanks for the reminder, that HOWTO 
needs a rewrite, badly. 

Cheers 
Richard 

On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> Hi,
> 
> unless I didn't look careful enough I think we might still be missing
> the current_cert (and current_issuer) from the X509_STORE_CTX, as
> advertised in
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> and used in e.g.
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> and many other places for verifying the proxy chain or is there a
> better/other solution for that?
> 
> Best wishes,
> Mischa
> 
> On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> wrote:
> > In addition to github PR 1294, there's now also PR 1339 which adds
> > the function to set the EXFLAG_PROXY flag on a given certificate.
> >
> > Also, PR 1295 has been updated. Instead of a function that returns a
> > lock, there is now a lock and an unlock function.
> >
> > To me, it seems that that covers what's being asked for. Perhaps not
> > exactly (the setters are for X509_STORE only), but should be
> > workable.
> >
> > (writing this from my mobile, sorry for the lack of github links)
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >
> > --
> > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.


-- 
Richard Levitte
levi...@openssl.org
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4624] Re: Bug#829272: Missing accessors

[msa...@nikhef.nl via RT]

Hi,

unless I didn't look careful enough I think we might still be missing
the current_cert (and current_issuer) from the X509_STORE_CTX, as
advertised in
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
and used in e.g.
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
and many other places for verifying the proxy chain or is there a
better/other solution for that?

Best wishes,
Mischa

On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT wrote:
> In addition to github PR 1294, there's now also PR 1339 which adds the 
> function to set the EXFLAG_PROXY flag on a given certificate. 
> 
> Also, PR 1295 has been updated. Instead of a function that returns a lock, 
> there is now a lock and an unlock function. 
> 
> To me, it seems that that covers what's being asked for. Perhaps not exactly 
> (the setters are for X509_STORE only), but should be workable. 
> 
> (writing this from my mobile, sorry for the lack of github links) 
> 
> -- 
> Richard Levitte
> levi...@openssl.org
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 
> -- 
> To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4624
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

In addition to github PR 1294, there's now also PR 1339 which adds the function 
to set the EXFLAG_PROXY flag on a given certificate. 

Also, PR 1295 has been updated. Instead of a function that returns a lock, 
there is now a lock and an unlock function. 

To me, it seems that that covers what's being asked for. Perhaps not exactly 
(the setters are for X509_STORE only), but should be workable. 

(writing this from my mobile, sorry for the lack of github links) 

-- 
Richard Levitte
levi...@openssl.org
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4511] s_server does not send Alert messages upon receiving malformed Client Key Exchange messages in DHE key exchange

[Stephen Henson via RT]

Fixed now in master and 1.0.2.

Thanks for the report,
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4511
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

[Hubert Kario via RT]

the issue is present in master 0ed26acce328ec16a3aa and looks to have been 
introduced in commit:

$ git bisect bad
5b8fa431ae8eb5a18ba913494119e394230d4b70 is the first bad commit
commit 5b8fa431ae8eb5a18ba913494119e394230d4b70
Author: David Benjamin 
Date:   Thu Jun 16 14:15:19 2016 -0400

Make RSA key exchange code actually constant-time.

Using RSA_PKCS1_PADDING with RSA_private_decrypt is inherently unsafe.
The API requires writing output on success and touching the error queue
on error. Thus, although the padding check itself is constant-time as of
294d1e36c2495ff00e697c9ff622856d3114f14f, and the logic after the
decryption in the SSL code is constant-time as of
adb46dbc6dd7347750df2468c93e8c34bcb93a4b, the API boundary in the middle
still leaks whether the padding check succeeded, giving us our
much-loved Bleichenbacher padding oracle.

Instead, PKCS#1 padding must be handled by the caller which uses
RSA_NO_PADDING, in timing-sensitive code integrated with the
Bleichenbacher mitigation. Removing PKCS#1 padding in constant time is
actually much simpler when the expected length is a constant (and if
it's not a constant, avoiding a padding oracle seems unlikely), so just
do it inline.

Signed-off-by: Kurt Roeckx 
Reviewed-by: Rich Salz 

GH: #1222

:04 04 bd98bdbeaeddbc22f8a37324aaa1f1a527712a02 
9cc68f63ca3b34ed1f13b05029c3b4bb968a21cb M  ssl

when the OpenSSL receives a Client Key Exchange message that has the encrypted 
premaster secret comprised only of zero bytes, or equal to server's modulus, 
the server just aborts the connection without sending an Alert message

OpenSSL 1.0.2 (b746aa3fe05b5b) and 1.0.1 (6adf409c7432b9) do send Alert 
messages in this situation

Reproducer:
===
(requires Python 2.6, 3.2 or later)
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \
-nodes -batch -subj /CN=localhost
openssl s_server -www -key localhost.key -cert localhost.crt
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python
tlsfuzzer/scripts/test-invalid-rsa-key-exchange-messages.py

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4511] s_server does not send Alert messages upon receiving malformed Client Key Exchange messages in DHE key exchange

[Hubert Kario via RT]

On Friday, 15 April 2016 13:22:52 CEST Hubert Kario via RT wrote:
> Using either current 1.0.1 or 1.0.2 branch (7a433893a and 9676402c3a
> respectively) openssl s_server command does not send Alert message upon
> receiving a malformed or invalid Client Key Exchange message in DHE key
> exchange.
> 
> That applies to messages that are longer and shorter than needed as well
> as messages that include client key shares bigger than the prime selected
> by server.

the issue is still present in master 0ed26acce328ec16a3aa
 
Reproducer:
===
(requires Python 2.6, 3.2 or later)
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
pushd .tlslite-ng
popd
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \
-nodes -batch -subj /CN=localhost openssl s_server -www -key localhost.key \
-cert localhost.crt
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python
tlsfuzzer/scripts/test-dhe-rsa-key-exchange-with-bad-messages.py


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4511
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Richard Levitte]

In message <6106b2ad-a457-df2e-2ff2-627a8fc1c...@nikhef.nl> on Fri, 22 Jul 2016 
16:10:45 +0200, Jan Just Keijser  said:

janjust> Hi Rich,
janjust> 
janjust> On 22/07/16 14:52, Salz, Rich via RT wrote:
janjust> > And now, with subject clearly stated, I think we should not do this.
janjust> >
janjust> 
janjust> 
janjust> the original question related to this ticket was the missing accessors
janjust> in OpenSSL 1.1. I fully agree that OpenSSL should not add support for
janjust> pre-RFC3820 proxy, but it should allow others to write code to support
janjust> it. That's the way OpenSSL 0.9.x and 1.0.x did it: the Globus and Voms
janjust> people added their own handlers to the OpenSSL callbacks in order to
janjust> support GT2, GT3 and RFC3820 (aka GT4) proxies. With OpenSSL 1.1, some
janjust> of these handlers/callbacks seem to have been removed.
janjust> 
janjust> If OpenSSL 1.1 does not allow this, then the existing grid codebase is
janjust> "stuck" with OpenSSL 1.0.x until all users start using RFC3820
janjust> proxies. Again, I support the notion that people should have started
janjust> using these back in 2008 but the reality is that we in "Grid land" are
janjust> stuck with "legacy" proxies for some time. It would be a shame if we
janjust> cannot use OpenSSL 1.1+ on the grid.

Ok,

I can't say that I quite agree, mostly because it means that
"everyone" will have to implement those same handled (I've had a look
at the globus, voms and canl code, and keep noticing copies of more or
less the exact same callback source in all of them).

But, I'm listening, and I've had some internal discussion around this.

There's already been discussions around accessor functions, and
https://github.com/openssl/openssl/pull/1294 covers quite a lot
(please have a look!  I get way too few comments), and what's primarly
needed outside of that is a way to set the EXFLAG_PROXY flag on a X509*.
Correct?  For function names, I'm thinking that something as easy as
X509_cache_proxy_flag(X509 *x)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Jan Just Keijser]

Hi Rich,

On 22/07/16 14:52, Salz, Rich via RT wrote:

And now, with subject clearly stated, I think we should not do this.




the original question related to this ticket was the missing accessors 
in OpenSSL 1.1. I fully agree that OpenSSL should not add support for 
pre-RFC3820 proxy, but it should allow others to write code to support 
it. That's the way OpenSSL 0.9.x and 1.0.x did it: the Globus and Voms 
people added their own handlers to the OpenSSL callbacks in order to 
support GT2, GT3 and RFC3820 (aka GT4) proxies. With OpenSSL 1.1, some 
of these handlers/callbacks seem to have been removed.


If OpenSSL 1.1 does not allow this, then the existing grid codebase is 
"stuck" with OpenSSL 1.0.x until all users start using RFC3820 proxies. 
Again, I support the notion that people should have started using these 
back in 2008 but the reality is that we in "Grid land" are stuck with 
"legacy" proxies for some time. It would be a shame if we cannot use 
OpenSSL 1.1+ on the grid.


JM2CW,

JJK / Jan Just Keijser

PS I'm a co-worker of Mischa Salle

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4590] accessors without const return arguments

[Stephen Henson via RT]

On Sat Jun 25 22:09:59 2016, open...@roumenpetrov.info wrote:
>
> Above is reason the request to remove const from return argument of get0
> methods.
>

We had a discussion about this and the preference was to have get methods
retain const for various reasons.

Instead the DSA_SIG/ECDSA_SIG structures now no longer pre-allocate r/s so they
aren't immediately freed when you set them.

> The issue is not only for ECDSA but also for DSA_SIG and RSA, DSA, DH
> keys where situation is similar.
>

Do you have some examples of how this affects other structures? For RSA/DSA/DH
keys the fields are NULL initially unless I've missed something.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4610] Incorrect handling of malformed Client Key Exchange messages for ECDHE_RSA key exchange

[Stephen Henson via RT]

This has now been addressed in master and 1.0.2.

Thanks for the report,
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4610
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4603] HMAC_Init_ex incompatible change (possibly doc bug)

[Stephen Henson via RT]

On Sat Jul 02 11:13:44 2016, k...@roeckx.be wrote:
>
> /* If we are changing MD then we must have a key */
> if (md != NULL && md != ctx->md && (key == NULL || len < 0))
> return 0;
>
> That means contrary to the documentation, the existing salt isn't
> reused
> when the md argument is non-zero (and changes).
>

This is a bug in the documentation which has since been addressed. In general
you can't change the digest while retaining the same key because in some cases
the original key is no longer available, though in some cases it did work and
others it produced the wrong value. Now we're being stricter and preventing
digest change.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4603
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

[Stephen Henson via RT]

On Tue Jul 19 22:23:56 2016, steve wrote:
>
> If there are multiple CRLs with the appropriate scope then the first
> one where
> the current time falls between lastUpdate and nextUpdate is used.
>
> It is possible to dynamically update CRLs but currently only the time
> criteria
> is used. So if the first one fails the time test the next is used.
> This isn't
> ideal and something relying on the most recent or the highest CRL
> number would
> be preferable.
>

Please try the attached patch. This should end up using the most recent CRL
instead of the first one it sees. I've done some checks and dynamic update
works with this change. Note that if you happen to have two CRLs with an
identical lastUpdate field (down to the second) then it will just use the first
CRL it encounters again. This shouldn't be a problem in practice.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4615
Please log in as guest with password guest if prompted



crl.pat
Description: Binary data
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Salz, Rich via RT]

And now, with subject clearly stated, I think we should not do this.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[msa...@nikhef.nl via RT]

On Fri, Jul 22, 2016 at 09:38:13AM +0200, Mattias Ellert wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > > 
> > > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > > 
> > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > > 
> > > > > 
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > > 
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > > 
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > > 
> > > 
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > > 
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > > 
> > > > Hi Richard, Mattias, others,
> > > > 
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > > 
> > > > Best wishes,
> > > > Mischa Sallé
> > > > 
> > 
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> > 
> > --
> > Richard Levitte
> > levi...@openssl.org
> 
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
> 
> For example see "grid-proxy-init -help":
> 
>     -draftCreates a draft (GSI-3) proxy
> -old  Creates a legacy globus proxy
> -rfc  Creates a RFC 3820 compliant proxy
> 
> The really tricky one is the old legacy version 2 proxy I think.

Hi,

there are 3 types of proxies, in chronological order:

- so called legacy proxies, which voms-proxy-init will call old and are
  also known as GT2 proxies.
  They have no special (critical) extension and can be recognized by:
1) being signed by an end-entity cert (i.e. a non-CA)
2) have the same subjectDN as the issuer with one extra CN RDN
   added, which can be either
a) "CN=proxy" for a 'inherit all' proxy
b) "CN=limited proxy" for a limited proxy (as in OID
   1.3.6.1.4.1.3536.1.1.1.9)
  These are widely used and we have therefore code in many places to
  handle them.

- the draft RFC proxies, also known as GT3 proxies.
  They contain an extension 1.3.6.1.4.1.3536.1.222
  At least voms-proxy-init does not mark it as critical. They are
  rarely used. The ordering in the extension is different in the sense
  that they usually put the proxyPolicy before the proxyPathlength (when
  finite, i.e. present) inside the extension, but RFC-style extensions
  also occur. In openssl.cnf style a GT3 extension would be something
  like this:
[ gt3_proxy ]
keyUsage = critical,digitalSignature,keyEncipherment
1.3.6.1.4.1.3536.1.222=critical,ASN1:SEQUENCE:gt3_seq_sect

# For a proxy pathlength of 42, leave out field2 for inf.
[ gt3_seq_sect ]
field1 = SEQUENCE:normal_policy
field2 = EXPLICIT:1C,INTEGER:42

# similarly for limited policy
[ normal_policy ]
p1 = OID:1.3.6.1.5.5.7.21.1

- RFC3820 compliant proxies, also known as GT4 proxies.
  They contain the standard critical extension 1.3.6.1.5.5.7.1.14

The default for at least voms-proxy-init (both from the voms-clients2
and voms-clients3) is to make the GT2 proxies, and this is why they are
still very-widely used (I think vast majority of proxies).

Mischa
-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   

[openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs

[Richard Levitte via RT]

Forgive me for being sloppy, I forgot to add a subject. Now added, it says what
the actual issue is.

On Fri Jul 22 11:32:27 2016, levitte wrote:
> Ticket derived from RT4602 (missing accessors)
>
> Reports have been coming in that in the grid world, there are two pre-
> rfc3820
> forms of proxy certs still being used.
>
> Old (pre-draft) format: Looks like a regular EE cert, but has been
> issued by
> another EE (real or proxy), and can be recognised by having the issuer
> name as
> subject name with an extra CN appended, either 'CN=proxy' or
> 'CN=limited proxy'
>
> draft format: looks like a RFC3820 proxy cert, but uses OID
> 1.3.6.1.4.1.3536.1.222 instead of the RFC3820 OID for proxyCertInfo.
>
> Cc to Mattias and Mischa, who have provided valuable info on this
> issue in
> RT4602. Guys, I hope it was ok to add you. If not, please tell me and
> I'll take
> you off this ticket.
>
> --
> Richard Levitte
> levi...@openssl.org


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4622]

[Richard Levitte via RT]

Ticket derived from RT4602 (missing accessors)

Reports have been coming in that in the grid world, there are two pre-rfc3820
forms of proxy certs still being used.

Old (pre-draft) format: Looks like a regular EE cert, but has been issued by
another EE (real or proxy), and can be recognised by having the issuer name as
subject name with an extra CN appended, either 'CN=proxy' or 'CN=limited proxy'

draft format: looks like a RFC3820 proxy cert, but uses OID
1.3.6.1.4.1.3536.1.222 instead of the RFC3820 OID for proxyCertInfo.

Cc to Mattias and Mischa, who have provided valuable info on this issue in
RT4602. Guys, I hope it was ok to add you. If not, please tell me and I'll take
you off this ticket.

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4622
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

On Fri Jul 22 07:38:25 2016, mattias.ell...@physics.uu.se wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > >
> > > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > >
> > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > >
> > > > >
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > >
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > >
> > >
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > >
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > >
> > > > Hi Richard, Mattias, others,
> > > >
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > >
> > > > Best wishes,
> > > > Mischa Sallé
> > > >
> >
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
>
> For example see "grid-proxy-init -help":
>
> -draft Creates a draft (GSI-3) proxy
> -old Creates a legacy globus proxy
> -rfc Creates a RFC 3820 compliant proxy
>
> The really tricky one is the old legacy version 2 proxy I think.

Ok, so after doing quite a bit of searching, I found some references to GT2
(old) in a 3.0 document:

http://toolkit.globus.org/toolkit/docs/3.0/gsi/GSI-message-specification-02.doc
(section 5)

As I understand it, the GT2 format is a simple EE cert, with just two
differences:

1. the issuer is also a EE (so it has the basic constraint CA set to false)...
or it's another GT2 proxy, which amounts to the same thing.
2. the subject name is the issuer name plus an appended 'CN=Proxy' or
'CN=LimitedProxy'

Good so far?

My main problem here is GT3 (draft) proxy certs. If I look at
https://tools.ietf.org/html/draft-ietf-pkix-proxy-10, they look exactly the
same as RFC3820 proxy certs, down to the extension OID. If I look at a really
old draft
(http://sigillum.pl/upload/pdf/Internet%20X.509%20Public%20Key%20Infrastructure.%20Proxy%20Certificate%20Profile.pdf),
the difference is *wild*, and if look at a random shell script
(https://www.nikhef.nl/~janjust/proxy-verify/genproxy) I found while searching
for OID 1.3.6.1.4.1.3536.1.222, I find a third variant that has a slightly
different proycertinfo extension...

Btw, this should really become a new ticket, along the lines of "OpenSSL
doesn't recognise earlier proxy certs".

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[Mattias Ellert via RT]

tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > 
> > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > 
> > > > 
> > > > I guess having a more restrictive accessor that only sets the
> > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > solution
> > > > of
> > > > having set/clear accessors for arbitrary flags since it was -
> > > > well
> > > > more
> > > > general.
> > > 
> > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > not
> > > set the
> > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > That may be
> > > worth a bug report of its own.
> > > 
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > > 
> > 
> > The answer to this is related to Mischa's reply, which
> > unfortunately
> > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > it
> > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > handling non-RFC proxies in OpenSSL.
> > 
> > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > 
> > > Hi Richard, Mattias, others,
> > > 
> > > I agree with you that it would be nice if OpenSSL could figure
> > > out
> > > itself whether a cert needs to be treated as a proxy, but
> > > currently
> > > that
> > > doesn't work reliably as far as I know.
> > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > also
> > > known as legacy proxies. Unfortunately these are still very
> > > widely
> > > used
> > > (majority of the proxies actually) and hence our code must be
> > > able to
> > > handle them correctly.
> > > 
> > > Best wishes,
> > > Mischa Sallé
> > > 
> 
> Ok... From looking at the voms code that was linked to earlier, I can
> see that
> legacy proxy certs are recognised by an older OID (called
> PROXYCERTINFO_V3 in
> the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> in that
> version, whether they are critical or not and so on, that I can
> reach? Or is
> the OID the only actual difference? If it's easy enough (and it
> currently does
> look quite easy), I can certainly see adding some code in OpenSSL to
> recognise
> those...
> 
> --
> Richard Levitte
> levi...@openssl.org

As far as I know there are three different kinds of proxies, usually
called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
respectively.

For example see "grid-proxy-init -help":

    -draftCreates a draft (GSI-3) proxy
-old  Creates a legacy globus proxy
-rfc  Creates a RFC 3820 compliant proxy

The really tricky one is the old legacy version 2 proxy I think.

Mattias

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev