Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Michael Wojcik]

Sorry - I thought this topic had come up again (or that this was a new 
continuation of the older discussion). Now I see it was an old message that had 
been delayed. Apologies for the noise.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 07/01/2016 15:52, Michael Wojcik wrote:

The proposed change:

--
static inline unsigned int constant_time_msb(unsigned int a)
{
-return 0 - (a >> (sizeof(a) * 8 - 1));
+   return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}
-

produces an implementation-defined value in C99. See the final sentence of ISO 
9899-1999 6.5.7 #5:

 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an 
unsigned type
 or if E1 has a signed type and a nonnegative value, the value of the 
result is the integral
 part of the quotient of E1 / 2**E2. If E1 has a signed type and a negative 
value, the
 resulting value is implementation-defined.

Some implementations fill with the sign bit in this case; some fill with 0. 
It's possible the standard allows some other behavior.

Ignoring the CHAR_BITS issue, the shift portion of the original version looks 
correct to me, assuming no padding bits. (The latter assumption might as well 
be made, because it's unlikely the other bit-fiddling constant-time functions 
work under an implementation with padding bits, and such implementations are 
uncommon.) For an unsigned left operand, that right-shift should produce either 
0 or 1, corresponding to the value of the MSB.

That leaves us (in the original code) with the "0 -" part. The intent here is 
to have the function return either 0 (if the shift operation results in 0) or high-values 
(i.e., an unsigned int with all bits set). Your new code could return 1 under some 
implementations for values with the MSB set, so it's not equivalent.

Should the "0 -" part work correctly? The usual arithmetic conversions (6.3.1.8 
#1) convert the 0 to 0U (i.e., 0 as an unsigned int), because int and unsigned int have 
the same rank. So we either 0U - 0U, which is trivially 0, or 0U - 1U. The result of the 
latter is -1, which is outside the range of unsigned int; so the resulting value is 
computed by adding UINT_MAX+1 to it (notionally - this addition is per the normal rules 
of arithmetic, not constrained by the C implementation). The result is UINT_MAX, which is 
within the range of unsigned integer.

So if you see incorrect values from the original code, that looks like another 
compiler bug, unless I'm missing something in the standard, or your 
implementation doesn't conform to C99. (I don't think the relevant sections 
where changed by C11, but I could be wrong.) Unfortunately, while your 
alternative might work around it for some cases, it isn't guaranteed to produce 
the correct result on all implementations.

Note also that changing "sizeof(a)" to "sizeof(int)" has no effect. Each unsigned integer type has 
the same width as the corresponding integer type. That change just makes the code longer and more fragile if the type 
of "a" is changed later. (And the parentheses around "a" in the original are unnecessary - sizeof 
is an operator, not a function.)



This has all been discussed to death.  On the compiler in
question, *both* versions work, but some particular
invocations of this function inlined into certain other
inline functions several levels deep triggers a compiler
bug where the compiler in question throws away a different
arithmetic operation elsewhere in the code and ends up
producing the wrong result.  Changing from the portable
implementation to the old non-portable implementation
happens to avoid that compiler bug, by pure chance.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Michael Wojcik]

The proposed change:

--
static inline unsigned int constant_time_msb(unsigned int a)
{
-return 0 - (a >> (sizeof(a) * 8 - 1));
+   return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}
-

produces an implementation-defined value in C99. See the final sentence of ISO 
9899-1999 6.5.7 #5:

The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an 
unsigned type
or if E1 has a signed type and a nonnegative value, the value of the result 
is the integral
part of the quotient of E1 / 2**E2. If E1 has a signed type and a negative 
value, the
resulting value is implementation-defined.

Some implementations fill with the sign bit in this case; some fill with 0. 
It's possible the standard allows some other behavior.

Ignoring the CHAR_BITS issue, the shift portion of the original version looks 
correct to me, assuming no padding bits. (The latter assumption might as well 
be made, because it's unlikely the other bit-fiddling constant-time functions 
work under an implementation with padding bits, and such implementations are 
uncommon.) For an unsigned left operand, that right-shift should produce either 
0 or 1, corresponding to the value of the MSB.

That leaves us (in the original code) with the "0 -" part. The intent here is 
to have the function return either 0 (if the shift operation results in 0) or 
high-values (i.e., an unsigned int with all bits set). Your new code could 
return 1 under some implementations for values with the MSB set, so it's not 
equivalent.

Should the "0 -" part work correctly? The usual arithmetic conversions (6.3.1.8 
#1) convert the 0 to 0U (i.e., 0 as an unsigned int), because int and unsigned 
int have the same rank. So we either 0U - 0U, which is trivially 0, or 0U - 1U. 
The result of the latter is -1, which is outside the range of unsigned int; so 
the resulting value is computed by adding UINT_MAX+1 to it (notionally - this 
addition is per the normal rules of arithmetic, not constrained by the C 
implementation). The result is UINT_MAX, which is within the range of unsigned 
integer.

So if you see incorrect values from the original code, that looks like another 
compiler bug, unless I'm missing something in the standard, or your 
implementation doesn't conform to C99. (I don't think the relevant sections 
where changed by C11, but I could be wrong.) Unfortunately, while your 
alternative might work around it for some cases, it isn't guaranteed to produce 
the correct result on all implementations.

Note also that changing "sizeof(a)" to "sizeof(int)" has no effect. Each 
unsigned integer type has the same width as the corresponding integer type. 
That change just makes the code longer and more fragile if the type of "a" is 
changed later. (And the parentheses around "a" in the original are unnecessary 
- sizeof is an operator, not a function.)

-- 
Michael Wojcik
Technology Specialist, Micro Focus

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

> 1. With compiler optimization disabled, OpenSSL 1.0.2d function worked
> as it is.

Another indication in favour of compiler bug is that it worked when you
added printf. It's similar to quantum physics when by measuring you
force particle to specific state. But understand me correctly. I'm not
saying that quantum physics apply in this case, it's just a *fun* way to
look at it. As compiler doesn't know what printf does, it's forced to
normalize value for "measurement". Same essentially applies to
volatilization. I mean variables declared volatile are meant for
*external* consumption/"measurement".

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi All,

1. With compiler optimization disabled, OpenSSL 1.0.2d function worked as
it is.
2. Looks like in the below functions, typecast to unsigned char to is not
going well when compiler optimization is enabled. Hence functions are
modified to assign the return value to a volatile unsigned char and then
return the volatile value. Things worked fine.

static inline unsigned char constant_time_lt_8(unsigned int a, unsigned int
b)
static inline unsigned char constant_time_ge_8(unsigned int a, unsigned int
b)
static inline unsigned char constant_time_is_zero_8(unsigned int a)
static inline unsigned char constant_time_eq_8(unsigned int a, unsigned int
b)
static inline unsigned char constant_time_eq_int_8(int a, int b)
static inline unsigned char constant_time_select_8(unsigned char mask,

Matt, Jakob, Andy your explanations were really useful to route cause the
issue to compiler specific. Thanks every one for the valuable time and
fruitful discussion.

Regards
Jaya






On Sun, Dec 13, 2015 at 11:13 AM, Jayalakshmi bhat <
bhat.jayalaks...@gmail.com> wrote:

> Hi All,
>
>
>
> Thanks for all the responses. As mentioned by Matt in the discussion
> thread,constant_time_msb performs the copy the msb of the input to all of
> the other bits so the return value should either be one of 0x or
> 0x.
>
>
>
> I found another interesting thing,constant_time_msb worked as it is
> without any changes, after I added a printf in constant_time_is_zero_8 test
> routine to print the return value. I added the printf just before comparing
> the return value with the expected value.
>
>
>
> I have confirmed the failures by removing the printf and printing any
> thing else other than the returned value.
>
>
>
> Now based on the discussions here and print results I am thinking, after
> constant_time_msb operation probably overflow bit is set in case of
> 0x. And it is not cleared before comparing, hence compare fails.
> When I add a printf to print the return value probably overflow flag got
> cleared and things worked.
>
>
>
> I am planning to attach the debugger to check the flags. I will get back
> with debugger results.
>
>
>
> I have attached the test file.
>
>
>
> Regards
>
> Jaya
>
>
>
> On Fri, Dec 11, 2015 at 11:30 AM, Jeffrey Walton 
> wrote:
>
>> > 3. The compiler wasn't written by a fanatic who put
>> >   the "right shift of negative signed values is
>> >   undefined" rule above common sense.
>> >
>> > This is only implementation-defined behavior, not undefined behavior.
>> It is
>> > not permitted to crash the system or launch the missiles.  (n1256.pdf
>> 6.5.7
>> > paragraph 5.)
>>
>> The potential problem with implementation defined is its not
>> guaranteed to produce consistent results. Different compilers or
>> different versions of the same compiler may arrive at different
>> results.
>>
>> In this light, the crash might be welcomed to make it easy to find the
>> trouble spot :)
>> ___
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi All,



Thanks for all the responses. As mentioned by Matt in the discussion
thread,constant_time_msb performs the copy the msb of the input to all of
the other bits so the return value should either be one of 0x or
0x.



I found another interesting thing,constant_time_msb worked as it is without
any changes, after I added a printf in constant_time_is_zero_8 test routine
to print the return value. I added the printf just before comparing the
return value with the expected value.



I have confirmed the failures by removing the printf and printing any thing
else other than the returned value.



Now based on the discussions here and print results I am thinking, after
constant_time_msb operation probably overflow bit is set in case of
0x. And it is not cleared before comparing, hence compare fails.
When I add a printf to print the return value probably overflow flag got
cleared and things worked.



I am planning to attach the debugger to check the flags. I will get back
with debugger results.



I have attached the test file.



Regards

Jaya



On Fri, Dec 11, 2015 at 11:30 AM, Jeffrey Walton  wrote:

> > 3. The compiler wasn't written by a fanatic who put
> >   the "right shift of negative signed values is
> >   undefined" rule above common sense.
> >
> > This is only implementation-defined behavior, not undefined behavior.
> It is
> > not permitted to crash the system or launch the missiles.  (n1256.pdf
> 6.5.7
> > paragraph 5.)
>
> The potential problem with implementation defined is its not
> guaranteed to produce consistent results. Different compilers or
> different versions of the same compiler may arrive at different
> results.
>
> In this light, the crash might be welcomed to make it easy to find the
> trouble spot :)
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


constant_time_test.7z
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jeffrey Walton]

> 3. The compiler wasn't written by a fanatic who put
>   the "right shift of negative signed values is
>   undefined" rule above common sense.
>
> This is only implementation-defined behavior, not undefined behavior.  It is
> not permitted to crash the system or launch the missiles.  (n1256.pdf 6.5.7
> paragraph 5.)

The potential problem with implementation defined is its not
guaranteed to produce consistent results. Different compilers or
different versions of the same compiler may arrive at different
results.

In this light, the crash might be welcomed to make it easy to find the
trouble spot :)
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

On 12/11/15 17:41, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Andy Polyakov
>> Sent: Friday, December 11, 2015 10:07
>> To: openssl-users@openssl.org
>> Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in
>> OpenSSL 1.0.2d
>>
>>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>>>> }
>>>
>>>
>>> ... Both versions
>>> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
>>> bits).
>>
>> Hardcoded 8 is not reference to char C type, but to units in which
>> sizeof(variable) is measured. For example when we say ILP32 or LP64,
>> what do we mean and what role does 8 play in the drama?
> 
> The distinction you're drawing is meaningless.

Right, I've let practical myself talk too soon, sorry. Yet we do adhere
to ILP notion when describing platform requirement, so 8 is kind of
implied anyway. But in case one chooses to switch to CHAR_BIT. I want to
remind that not all platforms OpenSSL [still] supports are sufficiently
standard compliant. There are platforms that are *partially* compliant
or stuck between standards. But I'd say that it would be safe to assume
that if CHAR_BIT is not defined, then it's 8.

> (Also, such platforms are generally DSPs which are not likely to be
> able to run OpenSSL anyway.)

As fun fact, OpenSSL does run on TI C6000 series DSP and even optimized
for C64x+ and forward.

Anyway, this has little to do with problem at hand, as all assumptions
made implicitly or explicitly do apply to the platform in question. If
it turns to be compiler bug, then no argument about standard compliance
would justify it. And we'll face the usual dilemma, do we give in and
arrange a kludge (e.g. with #ifdef _MSC_VER), or send user to said
compiler vendor... Latter is kind of counter-productive, former is
...

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>>> }
>>
>>
>> ... Both versions
>> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
>> bits).
> 
> Hardcoded 8 is not reference to char C type, but to units in which
> sizeof(variable) is measured. For example when we say ILP32 or LP64,
> what do we mean and what role does 8 play in the drama?

Well, one can argue that language standard doesn't actually dictate the
unit of sizeof(variable) to be 8-bit wide (only that it's *at least* 8,
right?), but we do so to say live in an "ILP" world and 8 is ubiquitous.

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Andy Polyakov
> Sent: Friday, December 11, 2015 10:07
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in
> OpenSSL 1.0.2d
> 
> >> static inline unsigned int constant_time_msb(unsigned int a) {
> >> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> >> }
> >
> >
> > ... Both versions
> > look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
> > bits).
> 
> Hardcoded 8 is not reference to char C type, but to units in which
> sizeof(variable) is measured. For example when we say ILP32 or LP64,
> what do we mean and what role does 8 play in the drama?

The distinction you're drawing is meaningless. The result of the sizeof 
operator is defined in terms of the C char type. Please refer to the C 
specification.

For example, referring to ISO 9899:1999 (because C11 is not widely used), 
please see 6.5.3.4, "The sizeof operator", items 2 and 3, and particularly the 
first sentence of #3: "When applied to an operand that has type char, unsigned 
char, or signed char, (or a qualified version thereof) the result is 1." 
sizeof(any-char-type) is ALWAYS 1, by definition.

Also note, from 6.5.3.4 #2: "The sizeof operator yields the size (in bytes) of 
its operand". In C, "byte" is a synonym for "char". It is NOT a synonym for 
"octet". The number of bits in a char (or byte) in C is specified by CHAR_BIT 
in . CHAR_BIT must be >= 8. (See 5.42.4.2.1, etc.)

Using a literal 8 here assumes CHAR_BIT == 8. It would be better, in terms of 
portability, to include  and use CHAR_BIT here. However, my guess is 
that getting OpenSSL working on platforms where CHAR_BIT > 8 would require 
substantial effort and would likely be pointless; if no one's asking for it, no 
one's likely to use it. (Also, such platforms are generally DSPs which are not 
likely to be able to run OpenSSL anyway.)

All of these points have already been made in this thread, except for the C&V 
citations (and with occasional errors such as "the unit for sizeof is chars not 
bytes" - that's a contradictory statement, since "byte" is a term of art in the 
C specification and is identical to "char").

-- 
Michael Wojcik
Technology Specialist, Micro Focus

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

>> static inline unsigned int constant_time_msb(unsigned int a) {
>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>> }
> 
> 
> ... Both versions
> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
> bits).

Hardcoded 8 is not reference to char C type, but to units in which
sizeof(variable) is measured. For example when we say ILP32 or LP64,
what do we mean and what role does 8 play in the drama?

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

>>> C does not make such a guarantee, though recent-ish POSIX does.  (This
>>> system is a windows one, thought, right?)
>> There are DSPs that only support 32 bit, they don't have a concept
>> of 8 bit.  But I think there is various code that assumes that
>> char is 8 bit, and I doubt you can get OpenSSL working on such a
>> system.
>>
> Target in question is traditional 32 bit ARM with 32 bit
> instructions and 8 bit char.
> 
> Looks like a hard to fix compiler bug to me.

While assessment that code presented in disassembler output lacks a
number of &0xFF is absolutely correct, it's not *necessarily* proof of a
compiler bug (but read to the end, please). Trouble is that since
functions are static compiler is free to trim them as it suits local
goal in any given module. For example consider disassembler output for
constant_time_eq_8 from x86_64 test/constant_time_test.o compiled by gcc
4.8:

:
xor%esi,%edi
lea-0x1(%rdi),%eax
not%edi
and%edi,%eax
sar$0x1f,%eax
retq

Note no mask either! [Note that it even replaced 0-(a>>(sizeof(a)*8-1))
with arithmetic shift!] However! This does *not* mean that suggestion
about compiler bug is rejected, it only means that you can't use lack of
&0xFF in presented disassembler output as definitive proof.

constant_time_msb was pinpointed as culprit. But I can certify that
binary code generated for 0 - (a >> (sizeof(a) * 8 - 1)) *alone* is
actually correct. It should be and is

mov rX, rY, lsr #31
rsb rZ, rX, #0

[Unless compiler recognizes it as equivalent of arithmetic shift, like
gcc did above]. But as it gets inlined in *real* usage cases, compiler
will subject it to all possible kind of optimizations and in process can
loose track of things, which would be definition of compiler bug. In
other words one can't dismiss the suggestion that it is a compiler
bug... More reliable to way to tell if it's indeed a compiler bug is to
disable optimizations. So I'd suggest to do that. Not to do that and
leave it like that if it works, but to *determine* if we are looking at
compiler bug or not.

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 11/12/2015 00:16, Kurt Roeckx wrote:

On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote:

C does not make such a guarantee, though recent-ish POSIX does.  (This
system is a windows one, thought, right?)

There are DSPs that only support 32 bit, they don't have a concept
of 8 bit.  But I think there is various code that assumes that
char is 8 bit, and I doubt you can get OpenSSL working on such a
system.


Target in question is traditional 32 bit ARM with 32 bit
instructions and 8 bit char.

Looks like a hard to fix compiler bug to me.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Kurt Roeckx]

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
> 
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }

This looks a revert of commit
d2fa182988afa33d9e950358de406cc9fb36d000

It was changed because of the implementation defined behaviour,
and we would like to avoid that.  See RT ticket #3558.


Kurt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Kurt Roeckx]

On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote:
> C does not make such a guarantee, though recent-ish POSIX does.  (This
> system is a windows one, thought, right?)

There are DSPs that only support 32 bit, they don't have a concept
of 8 bit.  But I think there is various code that assumes that
char is 8 bit, and I doubt you can get OpenSSL working on such a
system.


Kurt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 10/12/2015 19:13, Benjamin Kaduk wrote:

On 12/10/2015 12:09 PM, openssl-us...@dukhovni.org wrote:

On Dec 10, 2015, at 12:45 PM, Jakob Bohm  wrote:

On 10/12/2015 18:33, Viktor Dukhovni wrote:

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:



static inline unsigned int constant_time_msb(unsigned int a) {
-  return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}


The replacement is not right.  This function is supposed to return
0xfff for inputs with the high bit set, and 0x000 for inputs
with the high bit not set.  Could you try:

 static inline unsigned int constant_time_msb(unsigned int a) {
   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
 }

Just in case the compiler is promoting "a" to the (larger?) size
of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
while a signed "a" would be promoted "correctly".


Look again, he is casting a to signed, then doing an
arithmetic right shift to extend the msb (sign bit)
to the rest of the word.  This works on 3 conditions:

I saw what he's doing.  casting (a) to an int, instead of leaving
it unsigned is not an improvement.  On the assumption that it made
a difference for this compiler, I proposed an alternative that tests
whether promotion to the type of the shift's right operand is taking
place.  It would be good to know whether explicitly casting the shift
width to an int helps.  Also that 8 could be replaced by CHAR_BIT
just in case.


Yeah, sizeof returning a size_t that is wider than int, causing
promotion of the left argument of the shift operator prior to evaluation
seems a plausible explanation for this behavior.

Please stop the misinformed guesswork and read the
disassembly posted.

The compiler in question gets confused by the long
sequence of nested inline expressions and looses the
truncation from 32 bit unsigned to 8 bit unsigned
char in the shuffle.

Changing back to the old form of constant_time_msb
simplifies the parse tree just enough to avoid the bug.

Unfortunately, as a comment in the 1.0.2 source code
explains, the old form relies on a language feature
not guaranteed by the C standard, which is probably
why the implementation was changed to the one
currently in 1.0.2.

And to those who still don't understand how the old
implementation worked:

1. By casting the unsigned a to a signed int, the msb
  of interest becomes the sign bit.

2. By shifting right the 2's complement signed int by
  the number of non-sign bits (31 on this target),
  the sign bit gets replicated to the other bits so
  negative values (those with the msb set) become -1,
  while positive values (those with the msb clear)
  become +0.

3. Casting back to unsigned int results in the
  desired value of 0x or 0x .

On the ARM platform, shifting right by 31 bits can be
done to the second input of any arithmetic
instruction, thus making it execute in 0.5 instruction
time if combined with some other operation.  Thus the
compiler moves the shift backwards through some
arithmetic steps in the zero testing, resulting in the
code you see in the posted disassembly.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/10/2015 12:09 PM, openssl-us...@dukhovni.org wrote:
>> On Dec 10, 2015, at 12:45 PM, Jakob Bohm  wrote:
>>
>> On 10/12/2015 18:33, Viktor Dukhovni wrote:
>>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
>>>
>>>
 static inline unsigned int constant_time_msb(unsigned int a) {
 -  return 0 - (a >> (sizeof(a) * 8 - 1));
 + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
 }

>>> The replacement is not right.  This function is supposed to return
>>> 0xfff for inputs with the high bit set, and 0x000 for inputs
>>> with the high bit not set.  Could you try:
>>>
>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>>   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
>>> }
>>>
>>> Just in case the compiler is promoting "a" to the (larger?) size
>>> of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
>>> while a signed "a" would be promoted "correctly".
>>>
>> Look again, he is casting a to signed, then doing an 
>> arithmetic right shift to extend the msb (sign bit) 
>> to the rest of the word.  This works on 3 conditions:
> I saw what he's doing.  casting (a) to an int, instead of leaving
> it unsigned is not an improvement.  On the assumption that it made
> a difference for this compiler, I proposed an alternative that tests
> whether promotion to the type of the shift's right operand is taking
> place.  It would be good to know whether explicitly casting the shift
> width to an int helps.  Also that 8 could be replaced by CHAR_BIT
> just in case.
>

Yeah, sizeof returning a size_t that is wider than int, causing
promotion of the left argument of the shift operator prior to evaluation
seems a plausible explanation for this behavior.

-Ben
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[openssl-users]

> On Dec 10, 2015, at 12:45 PM, Jakob Bohm  wrote:
> 
> On 10/12/2015 18:33, Viktor Dukhovni wrote:
>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
>> 
>> 
>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>> -  return 0 - (a >> (sizeof(a) * 8 - 1));
>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>>> }
>>> 
>> The replacement is not right.  This function is supposed to return
>> 0xfff for inputs with the high bit set, and 0x000 for inputs
>> with the high bit not set.  Could you try:
>> 
>> static inline unsigned int constant_time_msb(unsigned int a) {
>>   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
>> }
>> 
>> Just in case the compiler is promoting "a" to the (larger?) size
>> of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
>> while a signed "a" would be promoted "correctly".
>> 
> Look again, he is casting a to signed, then doing an 
> arithmetic right shift to extend the msb (sign bit) 
> to the rest of the word.  This works on 3 conditions:

I saw what he's doing.  casting (a) to an int, instead of leaving
it unsigned is not an improvement.  On the assumption that it made
a difference for this compiler, I proposed an alternative that tests
whether promotion to the type of the shift's right operand is taking
place.  It would be good to know whether explicitly casting the shift
width to an int helps.  Also that 8 could be replaced by CHAR_BIT
just in case.

-- 
Viktor.



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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/10/2015 11:45 AM, Jakob Bohm wrote:
> 3. The compiler wasn't written by a fanatic who put
>   the "right shift of negative signed values is
>   undefined" rule above common sense.

This is only implementation-defined behavior, not undefined behavior. 
It is not permitted to crash the system or launch the missiles. 
(n1256.pdf 6.5.7 paragraph 5.)

-Ben
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 10/12/2015 18:33, Viktor Dukhovni wrote:

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:


static inline unsigned int constant_time_msb(unsigned int a) {
-  return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}

The replacement is not right.  This function is supposed to return
0xfff for inputs with the high bit set, and 0x000 for inputs
with the high bit not set.  Could you try:

 static inline unsigned int constant_time_msb(unsigned int a) {
   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
 }

Just in case the compiler is promoting "a" to the (larger?) size
of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
while a signed "a" would be promoted "correctly".

Look again, he is casting a to signed, then doing an
arithmetic right shift to extend the msb (sign bit)
to the rest of the word.  This works on 3 conditions:

1. The platform is actually using twos complement.
2. The signed right shift function invoked by the C
  compiler is a sign-preserving ("arithmetic") shift.
3. The compiler wasn't written by a fanatic who put
  the "right shift of negative signed values is
  undefined" rule above common sense.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 10/12/2015 17:53, Matt Caswell wrote:

On 10/12/15 11:55, Jayalakshmi bhat wrote:

Hi Matt,

Thanks for the patch. Unfortunately patch did not work. I continued
debugging and found that issue was in constant_time_msb.

static inline unsigned int constant_time_msb(unsigned int a) {
-*return 0 - (a >> (sizeof(a) * 8 - 1));*
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}

Thanks. Have you analysed why the original version failed? Both versions
look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
bits). I'd really like to understand that before replacing it with
something else which apparently does the same thing. Perhaps you could
post some sample values for "a" and the return value, before and after
your change.

Looking at the provided disassembly, it looks like the
1.0.2 version triggers a compiler bug which (at least)
forgets to mask the result down to 8 bits after inlining
in test_is_zero_8().   The missing mask with FF occurs
in multiple functions in the disassembly.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Viktor Dukhovni]

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:

> static inline unsigned int constant_time_msb(unsigned int a) {
> -  return 0 - (a >> (sizeof(a) * 8 - 1));
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }

The replacement is not right.  This function is supposed to return
0xfff for inputs with the high bit set, and 0x000 for inputs
with the high bit not set.  Could you try:

static inline unsigned int constant_time_msb(unsigned int a) {
  return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
}

Just in case the compiler is promoting "a" to the (larger?) size
of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
while a signed "a" would be promoted "correctly".

--
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 10/12/15 17:04, Benjamin Kaduk wrote:
> On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote:
>> Hi Matt,
>>
>> Thanks for the patch. Unfortunately patch did not work. I continued
>> debugging and found that issue was in constant_time_msb.
>>
>> static inline unsigned int constant_time_msb(unsigned int a) {
>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> 
> Hmm, right-shifting a negative value is implementation-defined behavior,
> so I don't think that this construct would necessarily be portable to
> all systems.  It's not clear to me what purpose the "0 - " was supposed
> to perform in the original version, though.

This function is supposed to copy the msb of the input to all of the
other bits...so the return value should either be one of 0x or
0x (obviously dependent on how big an int is). In the original
version the shift would give you just the msb, i.e. a value of 0 or 1.
After the "0 -" you get 0 or -1 (0x).

Interestingly I just checked the header file where this function is
defined and found this:

/*
 * Returns the given value with the MSB copied to all the other
 * bits. Uses the fact that arithmetic shift shifts-in the sign bit.
 * However, this is not ensured by the C standard so you may need to
 * replace this with something else on odd CPUs.
 */

This doesn't match up with the implementation - so I suspect the comment
predates the implementation - but Jaya's fix would put it back that way.

Matt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;

Hmm, right-shifting a negative value is implementation-defined behavior,
so I don't think that this construct would necessarily be portable to
all systems.  It's not clear to me what purpose the "0 - " was supposed
to perform in the original version, though.

In any case, it seems that the '8' literal there ought to be CHAR_BIT
().  I am curious what value CHAR_BIT has in the environment
that Jaya is running in.

-Ben

> } 
>
> Changed constant_time_msb implementation as shown above. All the tests
> passed. I have attached the dis-assembly of the code for both
> successful case and failure case.  This was requested by Jakob. 
>

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jeffrey Walton]

On Thu, Dec 10, 2015 at 6:55 AM, Jayalakshmi bhat
 wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -return 0 - (a >> (sizeof(a) * 8 - 1));
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }

Forgive me for commenting... That looks questionable to me. C has some
non-intuitive rules, and usually one casts to an unsigned type during
shifts to avoid undefined behavior.

I would definitely build out a test case for it. Ensure the test cases
include a value with and without the high bit set on a 2's compliment
machine. Then, run it under GCC or Clang's Undefined Behavior
sanitizer. For GCC you need 4.9 or above. For Clang, you need 3.2 or
above.

I *think* Ben or Richard has a test build configuration that applies
the sanitizers.

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 10/12/15 11:55, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
> 
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }


Thanks. Have you analysed why the original version failed? Both versions
look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
bits). I'd really like to understand that before replacing it with
something else which apparently does the same thing. Perhaps you could
post some sample values for "a" and the return value, before and after
your change.

Thanks

Matt


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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi Matt,

Thanks for the patch. Unfortunately patch did not work. I continued
debugging and found that issue was in constant_time_msb.

static inline unsigned int constant_time_msb(unsigned int a) {
-*return 0 - (a >> (sizeof(a) * 8 - 1));*
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}

Changed constant_time_msb implementation as shown above. All the tests
passed. I have attached the dis-assembly of the code for both successful
case and failure case.  This was requested by Jakob.

Regards
Jaya

On Thu, Dec 10, 2015 at 2:48 AM, Matt Caswell  wrote:

>
>
> On 09/12/15 23:13, Benjamin Kaduk wrote:
> > On 12/09/2015 05:04 PM, Matt Caswell wrote:
> >>
> >> On 09/12/15 11:44, Jayalakshmi bhat wrote:
> >>> Hi Matt,
> >>>
> >>> I could build and execute the constant_time_test. I have attached the
> .c
> >>> file and test results. 34 tests have failed. All failures are
> >>> around constant_time_eq_8. This is the function I had mentioned in the
> >>> earlier mails.
> >> Not quite all. There is also a failure right at the beginning of your
> >> log in constant_time_is_zero_8. Although it looks very similar to the
> >> constant_time_eq_8 failure.
> >>
> >> As to the failure it is very strange. This is the function doing the
> test:
> >>
> >>  int test_binary_op_8(unsigned
> >> char (*op) (unsigned int a, unsigned int b),
> >> const char *op_name, unsigned int a,
> >> unsigned int b, int is_true)
> >> {
> >> unsigned char c = op(a, b);
> >> if (is_true && c != CONSTTIME_TRUE_8) {
> >> printf( "Test failed for %s(%du, %du): expected %u "
> >> "(TRUE), got %u at line %d\n", op_name, a, b,
> >> CONSTTIME_TRUE_8, c,__LINE__);
> >> return 1;
> >> } else if (!is_true && c != CONSTTIME_FALSE_8) {
> >> printf( "Test failed for  %s(%du, %du): expected %u "
> >> "(FALSE), got %u at line %d\n", op_name, a, b,
> >> CONSTTIME_FALSE_8, c,__LINE__);
> >> return 1;
> >> }
> >>  printf( "Test passed for %s(%du, %du): expected %u got %u at line
> %d
> >> with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
> >> c,__LINE__,is_true?"TRUE":"FALSE");
> >> return 0;
> >> }
> >>
> >>
> >> and the output we see in the log file is:
> >>
> >> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
> >> 4294967295 at line 85
> >>
> >> That big number in the output is actually 0x7FFF in hex. The
> >> variable that it is printing here is "c" which is declared as an
> >> "unsigned char".
> >>
> >> Please someone correct me if I'm wrong but doesn't the C spec guarantee
> >> that a "char" is 8 bits? In which case how can the value of "c" be
> >> greater than 255?
> >
> > C does not make such a guarantee, though recent-ish POSIX does.  (This
> > system is a windows one, thought, right?)
> >
> > In any case, due to C's type promotion rules, it's very difficult to
> > actually use types narrower than 'int', since integers get auto-promoted
> > to int at integer conversion time.  This has extra-fun interactions with
> > varargs functions, depending on the platform ABI in use.  (Always cast
> > NULL to a pointer type when passing to a varargs function; this does
> > cause real bugs.)  Since c is unsigned, it is odd to see it get promoted
> > to (int)-1, since C type conversions are supposed to be
> > value-preserving, but it is certainly possible that the windows ABI is
> > doing something I don't expect.  Adjusting things so that the format
> > specifier and the type passed to printf match (whether by casting c to
> > int or qualifying the format specifier) might help.
>
> Thanks Ben.
>
> It's not 100% clear to me that we are dealing with a system where a char
> has more than 8 bits, but it certainly seems like a plausible
> explanation for what is going on. Especially when you look at the
> implementation of constant_time_eq_8:
>
> static inline unsigned char constant_time_eq_8(unsigned int a, unsigned
> int b)
> {
> return (unsigned char)(constant_time_eq(a, b));
> }
>
> The function "constant_time_eq" here returns an "unsigned int". The
> whole purpose of "constant_time_eq_8" is to provide a convenience
> function to create an 8 bit mask. If the number of bits in an unsigned
> char > 8 then this code is going to fail!
>
> Jaya - please could you try the attached patch to see if that resolves
> the problem. Please try re-executing both your SSL/TLS tests and the
> constant_time test. Let me know how you get on.
>
> Thanks
>
> Matt
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


changes.7z
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 09/12/15 23:13, Benjamin Kaduk wrote:
> On 12/09/2015 05:04 PM, Matt Caswell wrote:
>>
>> On 09/12/15 11:44, Jayalakshmi bhat wrote:
>>> Hi Matt,
>>>
>>> I could build and execute the constant_time_test. I have attached the .c
>>> file and test results. 34 tests have failed. All failures are
>>> around constant_time_eq_8. This is the function I had mentioned in the
>>> earlier mails.
>> Not quite all. There is also a failure right at the beginning of your
>> log in constant_time_is_zero_8. Although it looks very similar to the
>> constant_time_eq_8 failure.
>>
>> As to the failure it is very strange. This is the function doing the test:
>>
>>  int test_binary_op_8(unsigned
>> char (*op) (unsigned int a, unsigned int b),
>> const char *op_name, unsigned int a,
>> unsigned int b, int is_true)
>> {
>> unsigned char c = op(a, b);
>> if (is_true && c != CONSTTIME_TRUE_8) {
>> printf( "Test failed for %s(%du, %du): expected %u "
>> "(TRUE), got %u at line %d\n", op_name, a, b,
>> CONSTTIME_TRUE_8, c,__LINE__);
>> return 1;
>> } else if (!is_true && c != CONSTTIME_FALSE_8) {
>> printf( "Test failed for  %s(%du, %du): expected %u "
>> "(FALSE), got %u at line %d\n", op_name, a, b,
>> CONSTTIME_FALSE_8, c,__LINE__);
>> return 1;
>> }
>>  printf( "Test passed for %s(%du, %du): expected %u got %u at line %d
>> with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
>> c,__LINE__,is_true?"TRUE":"FALSE");
>> return 0;
>> }
>>
>>
>> and the output we see in the log file is:
>>
>> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
>> 4294967295 at line 85
>>
>> That big number in the output is actually 0x7FFF in hex. The
>> variable that it is printing here is "c" which is declared as an
>> "unsigned char".
>>
>> Please someone correct me if I'm wrong but doesn't the C spec guarantee
>> that a "char" is 8 bits? In which case how can the value of "c" be
>> greater than 255?
> 
> C does not make such a guarantee, though recent-ish POSIX does.  (This
> system is a windows one, thought, right?)
> 
> In any case, due to C's type promotion rules, it's very difficult to
> actually use types narrower than 'int', since integers get auto-promoted
> to int at integer conversion time.  This has extra-fun interactions with
> varargs functions, depending on the platform ABI in use.  (Always cast
> NULL to a pointer type when passing to a varargs function; this does
> cause real bugs.)  Since c is unsigned, it is odd to see it get promoted
> to (int)-1, since C type conversions are supposed to be
> value-preserving, but it is certainly possible that the windows ABI is
> doing something I don't expect.  Adjusting things so that the format
> specifier and the type passed to printf match (whether by casting c to
> int or qualifying the format specifier) might help.

Thanks Ben.

It's not 100% clear to me that we are dealing with a system where a char
has more than 8 bits, but it certainly seems like a plausible
explanation for what is going on. Especially when you look at the
implementation of constant_time_eq_8:

static inline unsigned char constant_time_eq_8(unsigned int a, unsigned
int b)
{
return (unsigned char)(constant_time_eq(a, b));
}

The function "constant_time_eq" here returns an "unsigned int". The
whole purpose of "constant_time_eq_8" is to provide a convenience
function to create an 8 bit mask. If the number of bits in an unsigned
char > 8 then this code is going to fail!

Jaya - please could you try the attached patch to see if that resolves
the problem. Please try re-executing both your SSL/TLS tests and the
constant_time test. Let me know how you get on.

Thanks

Matt

From 9649f5fac40438608f010d1cd25d0d553e2c0fae Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Thu, 10 Dec 2015 09:33:24 +
Subject: [PATCH] Fix constant time assumption that char is 8 bits

The constant time code assumes that a char is 8 bits. In reality the C
standard does not guarantee this, so it could be longer than this. There was
a reported issue due to this on WinCE.
---
 crypto/constant_time_locl.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/crypto/constant_time_locl.h b/crypto/constant_time_locl.h
index c786aea..08f4647 100644
--- a/crypto/constant_time_locl.h
+++ b/crypto/constant_time_locl.h
@@ -49,6 +49,8 @@
 
 # include "e_os.h"  /* For 'inline' */
 
+# define CONSTTIME_8BITMASK  0xff
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -142,7 +144,7 @@ static inline unsigned int constant_time_lt(unsigned int a, unsigned int b)
 
 static inline unsigned char constant_time_lt_8(unsigned int a, unsigned int b)
 {
-return (unsigned char)(constant_time_lt(a, b));
+return (unsigned char)(constant_time_lt(a, b) & CONSTTIME_8BITMASK);
 }
 
 static inline unsigned int constant_time_ge(unsigned int a, un

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 10/12/15 04:47, Viktor Dukhovni wrote:
> On Wed, Dec 09, 2015 at 11:04:35PM +, Matt Caswell wrote:
> 
>> unsigned char c = op(a, b);
>> if (is_true && c != CONSTTIME_TRUE_8) {
>> printf( "Test failed for %s(%du, %du): expected %u "
>> "(TRUE), got %u at line %d\n", op_name, a, b,
>> CONSTTIME_TRUE_8, c,__LINE__);
> 
> It is best to not leave "c" to the vagaries of stdarg argument
> handling.  Rather, it would better to explicitly convert it to an
> unsigned long, and print that.
> 
>> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
>> 4294967295 at line 85
> 
>> That big number in the output is actually 0x7FFF in hex.
> 
> Actually it is 0x, that is a 32-bit "-1".

Doh! Thanks. Looks like a bug in the online converter I was using:
http://www.binaryhexconverter.com/decimal-to-hex-converter

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Viktor Dukhovni]

On Wed, Dec 09, 2015 at 11:04:35PM +, Matt Caswell wrote:

> unsigned char c = op(a, b);
> if (is_true && c != CONSTTIME_TRUE_8) {
> printf( "Test failed for %s(%du, %du): expected %u "
> "(TRUE), got %u at line %d\n", op_name, a, b,
> CONSTTIME_TRUE_8, c,__LINE__);

It is best to not leave "c" to the vagaries of stdarg argument
handling.  Rather, it would better to explicitly convert it to an
unsigned long, and print that.

> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
> 4294967295 at line 85

> That big number in the output is actually 0x7FFF in hex.

Actually it is 0x, that is a 32-bit "-1".

> Please someone correct me if I'm wrong but doesn't the C spec guarantee
> that a "char" is 8 bits? In which case how can the value of "c" be
> greater than 255?

Well, it isn't greater, but the integral promotion for printf seems
to forget that c is unsigned.

> BTW can we modify the code above to print the value of sizeof(c)?

That is 1 by definition.  What we don't know on sufficiently odd
systems is whether a char is 8 bits or not.  The unit for sizeof
is chars not bytes.  So there's no point printing that.  You might
be interested in the CHAR_BIT macro from  instead, but
I don't think that's relevant at this time.

-- 
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/09/2015 05:04 PM, Matt Caswell wrote:
>
> On 09/12/15 11:44, Jayalakshmi bhat wrote:
>> Hi Matt,
>>
>> I could build and execute the constant_time_test. I have attached the .c
>> file and test results. 34 tests have failed. All failures are
>> around constant_time_eq_8. This is the function I had mentioned in the
>> earlier mails.
> Not quite all. There is also a failure right at the beginning of your
> log in constant_time_is_zero_8. Although it looks very similar to the
> constant_time_eq_8 failure.
>
> As to the failure it is very strange. This is the function doing the test:
>
>  int test_binary_op_8(unsigned
> char (*op) (unsigned int a, unsigned int b),
> const char *op_name, unsigned int a,
> unsigned int b, int is_true)
> {
> unsigned char c = op(a, b);
> if (is_true && c != CONSTTIME_TRUE_8) {
> printf( "Test failed for %s(%du, %du): expected %u "
> "(TRUE), got %u at line %d\n", op_name, a, b,
> CONSTTIME_TRUE_8, c,__LINE__);
> return 1;
> } else if (!is_true && c != CONSTTIME_FALSE_8) {
> printf( "Test failed for  %s(%du, %du): expected %u "
> "(FALSE), got %u at line %d\n", op_name, a, b,
> CONSTTIME_FALSE_8, c,__LINE__);
> return 1;
> }
>   printf( "Test passed for %s(%du, %du): expected %u got %u at line %d
> with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
> c,__LINE__,is_true?"TRUE":"FALSE");
> return 0;
> }
>
>
> and the output we see in the log file is:
>
> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
> 4294967295 at line 85
>
> That big number in the output is actually 0x7FFF in hex. The
> variable that it is printing here is "c" which is declared as an
> "unsigned char".
>
> Please someone correct me if I'm wrong but doesn't the C spec guarantee
> that a "char" is 8 bits? In which case how can the value of "c" be
> greater than 255?

C does not make such a guarantee, though recent-ish POSIX does.  (This
system is a windows one, thought, right?)

In any case, due to C's type promotion rules, it's very difficult to
actually use types narrower than 'int', since integers get auto-promoted
to int at integer conversion time.  This has extra-fun interactions with
varargs functions, depending on the platform ABI in use.  (Always cast
NULL to a pointer type when passing to a varargs function; this does
cause real bugs.)  Since c is unsigned, it is odd to see it get promoted
to (int)-1, since C type conversions are supposed to be
value-preserving, but it is certainly possible that the windows ABI is
doing something I don't expect.  Adjusting things so that the format
specifier and the type passed to printf match (whether by casting c to
int or qualifying the format specifier) might help.

-Ben

> Am I missing something?
>
> BTW can we modify the code above to print the value of sizeof(c)?
>
> Matt
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 09/12/15 11:44, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> I could build and execute the constant_time_test. I have attached the .c
> file and test results. 34 tests have failed. All failures are
> around constant_time_eq_8. This is the function I had mentioned in the
> earlier mails.

Not quite all. There is also a failure right at the beginning of your
log in constant_time_is_zero_8. Although it looks very similar to the
constant_time_eq_8 failure.

As to the failure it is very strange. This is the function doing the test:

 int test_binary_op_8(unsigned
char (*op) (unsigned int a, unsigned int b),
const char *op_name, unsigned int a,
unsigned int b, int is_true)
{
unsigned char c = op(a, b);
if (is_true && c != CONSTTIME_TRUE_8) {
printf( "Test failed for %s(%du, %du): expected %u "
"(TRUE), got %u at line %d\n", op_name, a, b,
CONSTTIME_TRUE_8, c,__LINE__);
return 1;
} else if (!is_true && c != CONSTTIME_FALSE_8) {
printf( "Test failed for  %s(%du, %du): expected %u "
"(FALSE), got %u at line %d\n", op_name, a, b,
CONSTTIME_FALSE_8, c,__LINE__);
return 1;
}
printf( "Test passed for %s(%du, %du): expected %u got %u at line %d
with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
c,__LINE__,is_true?"TRUE":"FALSE");
return 0;
}


and the output we see in the log file is:

Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
4294967295 at line 85

That big number in the output is actually 0x7FFF in hex. The
variable that it is printing here is "c" which is declared as an
"unsigned char".

Please someone correct me if I'm wrong but doesn't the C spec guarantee
that a "char" is 8 bits? In which case how can the value of "c" be
greater than 255?

Am I missing something?

BTW can we modify the code above to print the value of sizeof(c)?

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

Could you extract the disassembly of one of the failed
calls to constant_time_eq_8() in the test program, perhaps
the compiler generates incorrect code for this deeply
nested group of near-edge arithmetic operations?

On 09/12/2015 12:44, Jayalakshmi bhat wrote:

Hi Matt,

I could build and execute the constant_time_test. I have attached the 
.c file and test results. 34 tests have failed. All failures are 
around constant_time_eq_8. This is the function I had mentioned in the 
earlier mails.


On Tue, Dec 8, 2015 at 4:26 PM, Matt Caswell > wrote:




On 08/12/15 17:27, Jakob Bohm wrote:
> On 08/12/2015 11:57, Matt Caswell wrote:
>> On 07/12/15 05:18, Jayalakshmi bhat wrote:
>>> Hi All,
>>>
>>> Is there inputs or suggestions.
>> Have you run the tests on this platform? i.e. "make test"
>>
>> I'm particular interested to know if the constant_time_test passed.
> He can't.  WinCE is not a self-hosting platform,
> everything is done by cross-compiling on a PC.

Can we copy the text exe across?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 08/12/15 17:27, Jakob Bohm wrote:
> On 08/12/2015 11:57, Matt Caswell wrote:
>> On 07/12/15 05:18, Jayalakshmi bhat wrote:
>>> Hi All,
>>>
>>> Is there inputs or suggestions.
>> Have you run the tests on this platform? i.e. "make test"
>>
>> I'm particular interested to know if the constant_time_test passed.
> He can't.  WinCE is not a self-hosting platform,
> everything is done by cross-compiling on a PC.

Can we copy the text exe across?

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 08/12/2015 11:57, Matt Caswell wrote:

On 07/12/15 05:18, Jayalakshmi bhat wrote:

Hi All,

Is there inputs or suggestions.

Have you run the tests on this platform? i.e. "make test"

I'm particular interested to know if the constant_time_test passed.

He can't.  WinCE is not a self-hosting platform,
everything is done by cross-compiling on a PC.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 07/12/15 05:18, Jayalakshmi bhat wrote:
> Hi All,
> 
> Is there inputs or suggestions.

Have you run the tests on this platform? i.e. "make test"

I'm particular interested to know if the constant_time_test passed.

Matt


> 
> Thanks and Regards
> Jaya
> 
> On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat
> mailto:bhat.jayalaks...@gmail.com>> wrote:
> 
> Hi Matt,
> 
> s3_cbc.c uses the function constant_time_eq_8. I pulled only this
> function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I
> renamed this function as constant_time_eq_8_local and used it in
> s3_cbc.c instead of constant_time_eq_8. This renaming was just to
> avoid multiple definitions. 
> 
> OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below: 
> *
> *
> *
> #define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >>
> (sizeof(int)*8-1) ) )
> #define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned
> char)(DUPLICATE_MSB_TO_ALL(x)))
> *
> *
> *
> *static unsigned char constant_time_eq_8(unsigned a, unsigned b)*
> *{*
> *unsigned c = a ^ b;*
> *c--;*
> *return DUPLICATE_MSB_TO_ALL_8(c);*
> *}*
> 
> OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below.
> 
> static inline unsigned int constant_time_msb(unsigned int a)
> {
> return 0 - (a >> (sizeof(a) * 8 - 1));
> }
> 
> static inline unsigned int constant_time_is_zero(unsigned int a)
> {
> return constant_time_msb(~a & (a - 1));
> }
> 
> static inline unsigned int constant_time_eq(unsigned int a, unsigned
> int b)
> {
> return constant_time_is_zero(a ^ b);
> }
> 
> static inline unsigned char constant_time_eq_8(unsigned int a,
> unsigned int b)
> {
> return (unsigned char)(constant_time_eq(a, b));
> }
> 
> 
> Regards
> Jaya
> 
> On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 04/12/15 11:31, Jayalakshmi bhat wrote:
> > Hi Matt,
> >
> > Thanks a lot for the response.
> >
> > Is your application a client or a server? Are both ends using
> > OpenSSL 1.0.2d? If not, what is the other end using?
> >>>Our device has both TLS client,server apps. As client, device 
> communicates with radius server, LDAP server etc.As
> > server device is accessed using various web browsers.
> > Hence both the end will not be OpenSSL 1.0.2d.
> >
> > How exactly are you doing that? Which specific cipher are you 
> seeing fail?
> >>> We have provided user option to select TLS protocol versions 
> similar to the browsers. Depending upon the user configurations we set the 
> protocol flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the 
> SSL context using SSL_CTX_clear_options/SSL_CTX_set_options.
> >>> We have provided user option to chose ciphers as well.
> > All these are in the application space,no changes have been done and
> > they have been working good with OpenSSL 1.0.1c. Only the library is
> > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC 
> ciphers
> > and with both the ciphers issue is seen.
> >
> > Are you able to provide a packet capture?
> >>> Please find the attached traces for server mode.
> > What O/S is this on?
> >>>This is built for WinCE and Vxworks
> 
> Thanks. Please could you also send the exact patch that you
> applied that
> resolved the issue?
> 
> Matt
> ___
> openssl-users mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 
> 
> 
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi Jakob,

Here are more details,

OS   WinCE 6.0
CPU ARMARCH4.
Family  ARM
Compiler   ARM CC
VersionMicrosoft (R) C/C++ Optimizing Compiler Version 14.01.60511 for
ARM

Regards
Jaya

On Fri, Dec 4, 2015 at 5:35 AM, Jakob Bohm  wrote:

> For clarity, which version of WinCE, and which CPU (Arm,
> MIPS, PPC, x86, SH3, SH4, ...)?
>
> Which Microsoft Compiler version (EVC3, EVC4, one of the
> Visual Studio projects, 3rd party compiler) and which
> exact compiler version (reported by running the compiler
> executable (named according to CPU) with no arguments.
>
> I ask because your proposed fix may be affected by compiler and/or CPU
> quirks.
>
> On 04/12/2015 12:31, Jayalakshmi bhat wrote:
>
> Hi Matt,
>
> Thanks a lot for the response.
>
> Is your application a client or a server? Are both ends using OpenSSL 1.0.2d?
> If not, what is the other end using?
> >>Our device has both TLS client,server apps. As client, device
> communicates with radius server, LDAP server etc.As server device is
> accessed using various web browsers.
> Hence both the end will not be OpenSSL 1.0.2d.
>
> How exactly are you doing that? Which specific cipher are you seeing fail?
> >> We have provided user option to select TLS protocol versions similar to
> the browsers. Depending upon the user configurations we set the protocol
> flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL
> context using SSL_CTX_clear_options/SSL_CTX_set_options.
> >> We have provided user option to chose ciphers as well.
> All these are in the application space,no changes have been done and they
> have been working good with OpenSSL 1.0.1c. Only the library is upgraded to
> OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers and with
> both the ciphers issue is seen.
>
> Are you able to provide a packet capture?
> >> Please find the attached traces for server mode.
> What O/S is this on?
> >>This is built for WinCE and Vxworks
>
> Regards
> Jaya
>
>
>
> On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell  wrote:
>
>> Hello Jaya
>>
>> We're going to need some more information. There isn't a generic problem
>> with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so
>> there is something specific about your environment that is causing the
>> issue. Comments inserted below.
>>
>> On 04/12/15 06:53, Jayalakshmi bhat wrote:
>> > Hi All,
>> >
>> >
>> >
>> > Recently we have ported OpenSSL 1.0.2d. Everything works perfect except
>> > the below explained issue.
>>
>> Is your application a client or a server? Are both ends using OpenSSL
>> 1.0.2d? If not, what is the other end using?
>>
>>
>> > When we enable only TLS 1.0 protocol and select CBC ciphers,
>>
>> How exactly are you doing that? Which specific cipher are you seeing fail?
>>
>>
>> > Now my question is whatever I did is it correct?
>>
>> That would not be a recommended solution
>>
>> > Or Do need to replace
>> > complete s3_cbc.c with OpenSSL 1.0.1e?
>>
>> No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2.
>>
>> Some other questions:
>>
>> Are you able to provide a packet capture?
>> How did you build OpenSSL...i.e. what "Configure" options did you use?
>> What O/S is this on?
>>
>> Matt
>> ___
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Nounou Dadoun]

I have to do some testing tomorrow and I'll post my results and a packet 
capture .. N

From: openssl-users [openssl-users-boun...@openssl.org] on behalf of 
Jayalakshmi bhat [bhat.jayalaks...@gmail.com]
Sent: December 6, 2015 9:18 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in 
OpenSSL 1.0.2d

Hi All,

Is there inputs or suggestions.

Thanks and Regards
Jaya

On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat 
mailto:bhat.jayalaks...@gmail.com>> wrote:
Hi Matt,

s3_cbc.c uses the function constant_time_eq_8. I pulled only this function 
definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I renamed this function as 
constant_time_eq_8_local and used it in s3_cbc.c instead of constant_time_eq_8. 
This renaming was just to avoid multiple definitions.

OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below:

#define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >> (sizeof(int)*8-1) ) )
#define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned char)(DUPLICATE_MSB_TO_ALL(x)))

static unsigned char constant_time_eq_8(unsigned a, unsigned b)
{
unsigned c = a ^ b;
c--;
return DUPLICATE_MSB_TO_ALL_8(c);
}

OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below.

static inline unsigned int constant_time_msb(unsigned int a)
{
return 0 - (a >> (sizeof(a) * 8 - 1));
}

static inline unsigned int constant_time_is_zero(unsigned int a)
{
return constant_time_msb(~a & (a - 1));
}

static inline unsigned int constant_time_eq(unsigned int a, unsigned int b)
{
return constant_time_is_zero(a ^ b);
}

static inline unsigned char constant_time_eq_8(unsigned int a, unsigned int b)
{
return (unsigned char)(constant_time_eq(a, b));
}


Regards
Jaya

On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell 
mailto:m...@openssl.org>> wrote:


On 04/12/15 11:31, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks a lot for the response.
>
> Is your application a client or a server? Are both ends using
> OpenSSL 1.0.2d? If not, what is the other end using?
>>>Our device has both TLS client,server apps. As client, device communicates 
>>>with radius server, LDAP server etc.As
> server device is accessed using various web browsers.
> Hence both the end will not be OpenSSL 1.0.2d.
>
> How exactly are you doing that? Which specific cipher are you seeing fail?
>>> We have provided user option to select TLS protocol versions similar to the 
>>> browsers. Depending upon the user configurations we set the protocol flags 
>>> (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context 
>>> using SSL_CTX_clear_options/SSL_CTX_set_options.
>>> We have provided user option to chose ciphers as well.
> All these are in the application space,no changes have been done and
> they have been working good with OpenSSL 1.0.1c. Only the library is
> upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers
> and with both the ciphers issue is seen.
>
> Are you able to provide a packet capture?
>>> Please find the attached traces for server mode.
> What O/S is this on?
>>>This is built for WinCE and Vxworks

Thanks. Please could you also send the exact patch that you applied that
resolved the issue?

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi All,

Is there inputs or suggestions.

Thanks and Regards
Jaya

On Fri, Dec 4, 2015 at 11:37 AM, Jayalakshmi bhat <
bhat.jayalaks...@gmail.com> wrote:

> Hi Matt,
>
> s3_cbc.c uses the function constant_time_eq_8. I pulled only this
> function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I renamed
> this function as constant_time_eq_8_local and used it in s3_cbc.c instead
> of constant_time_eq_8. This renaming was just to avoid
> multiple definitions.
>
> OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below:
>
> *#define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >>
> (sizeof(int)*8-1) ) )#define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned
> char)(DUPLICATE_MSB_TO_ALL(x)))*
>
> *static unsigned char constant_time_eq_8(unsigned a, unsigned b)*
> * {*
> * unsigned c = a ^ b;*
> * c--;*
> * return DUPLICATE_MSB_TO_ALL_8(c);*
> * }*
>
> OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below.
>
> static inline unsigned int constant_time_msb(unsigned int a)
> {
> return 0 - (a >> (sizeof(a) * 8 - 1));
> }
>
> static inline unsigned int constant_time_is_zero(unsigned int a)
> {
> return constant_time_msb(~a & (a - 1));
> }
>
> static inline unsigned int constant_time_eq(unsigned int a, unsigned int b)
> {
> return constant_time_is_zero(a ^ b);
> }
>
> static inline unsigned char constant_time_eq_8(unsigned int a, unsigned
> int b)
> {
> return (unsigned char)(constant_time_eq(a, b));
> }
>
>
> Regards
> Jaya
>
> On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell  wrote:
>
>>
>>
>> On 04/12/15 11:31, Jayalakshmi bhat wrote:
>> > Hi Matt,
>> >
>> > Thanks a lot for the response.
>> >
>> > Is your application a client or a server? Are both ends using
>> > OpenSSL 1.0.2d? If not, what is the other end using?
>> >>>Our device has both TLS client,server apps. As client, device
>> communicates with radius server, LDAP server etc.As
>> > server device is accessed using various web browsers.
>> > Hence both the end will not be OpenSSL 1.0.2d.
>> >
>> > How exactly are you doing that? Which specific cipher are you seeing
>> fail?
>> >>> We have provided user option to select TLS protocol versions similar
>> to the browsers. Depending upon the user configurations we set the protocol
>> flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL
>> context using SSL_CTX_clear_options/SSL_CTX_set_options.
>> >>> We have provided user option to chose ciphers as well.
>> > All these are in the application space,no changes have been done and
>> > they have been working good with OpenSSL 1.0.1c. Only the library is
>> > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers
>> > and with both the ciphers issue is seen.
>> >
>> > Are you able to provide a packet capture?
>> >>> Please find the attached traces for server mode.
>> > What O/S is this on?
>> >>>This is built for WinCE and Vxworks
>>
>> Thanks. Please could you also send the exact patch that you applied that
>> resolved the issue?
>>
>> Matt
>> ___
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi Jakob

CPU is ARMARCH4. WinCE version is 6.0. I will get the compiler details
shortly.

Regards
Jaya

On Fri, Dec 4, 2015 at 6:05 PM, Jakob Bohm  wrote:

> For clarity, which version of WinCE, and which CPU (Arm,
> MIPS, PPC, x86, SH3, SH4, ...)?
>
> Which Microsoft Compiler version (EVC3, EVC4, one of the
> Visual Studio projects, 3rd party compiler) and which
> exact compiler version (reported by running the compiler
> executable (named according to CPU) with no arguments.
>
> I ask because your proposed fix may be affected by compiler and/or CPU
> quirks.
>
> On 04/12/2015 12:31, Jayalakshmi bhat wrote:
>
> Hi Matt,
>
> Thanks a lot for the response.
>
> Is your application a client or a server? Are both ends using OpenSSL 1.0.2d?
> If not, what is the other end using?
> >>Our device has both TLS client,server apps. As client, device
> communicates with radius server, LDAP server etc.As server device is
> accessed using various web browsers.
> Hence both the end will not be OpenSSL 1.0.2d.
>
> How exactly are you doing that? Which specific cipher are you seeing fail?
> >> We have provided user option to select TLS protocol versions similar to
> the browsers. Depending upon the user configurations we set the protocol
> flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL
> context using SSL_CTX_clear_options/SSL_CTX_set_options.
> >> We have provided user option to chose ciphers as well.
> All these are in the application space,no changes have been done and they
> have been working good with OpenSSL 1.0.1c. Only the library is upgraded to
> OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers and with
> both the ciphers issue is seen.
>
> Are you able to provide a packet capture?
> >> Please find the attached traces for server mode.
> What O/S is this on?
> >>This is built for WinCE and Vxworks
>
> Regards
> Jaya
>
>
>
> On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell  wrote:
>
>> Hello Jaya
>>
>> We're going to need some more information. There isn't a generic problem
>> with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so
>> there is something specific about your environment that is causing the
>> issue. Comments inserted below.
>>
>> On 04/12/15 06:53, Jayalakshmi bhat wrote:
>> > Hi All,
>> >
>> >
>> >
>> > Recently we have ported OpenSSL 1.0.2d. Everything works perfect except
>> > the below explained issue.
>>
>> Is your application a client or a server? Are both ends using OpenSSL
>> 1.0.2d? If not, what is the other end using?
>>
>>
>> > When we enable only TLS 1.0 protocol and select CBC ciphers,
>>
>> How exactly are you doing that? Which specific cipher are you seeing fail?
>>
>>
>> > Now my question is whatever I did is it correct?
>>
>> That would not be a recommended solution
>>
>> > Or Do need to replace
>> > complete s3_cbc.c with OpenSSL 1.0.1e?
>>
>> No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2.
>>
>> Some other questions:
>>
>> Are you able to provide a packet capture?
>> How did you build OpenSSL...i.e. what "Configure" options did you use?
>> What O/S is this on?
>>
>> Matt
>> ___
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi Matt,

s3_cbc.c uses the function constant_time_eq_8. I pulled only this
function definition from OpenSSL 1.0.1e into OpenSSL 1.0.2d. I renamed this
function as constant_time_eq_8_local and used it in s3_cbc.c instead of
constant_time_eq_8. This renaming was just to avoid multiple definitions.

OpenSSL 1.0.1e has the function constant_time_eq_8 defined as below:

*#define DUPLICATE_MSB_TO_ALL(x) ( (unsigned)( (int)(x) >>
(sizeof(int)*8-1) ) )#define DUPLICATE_MSB_TO_ALL_8(x) ((unsigned
char)(DUPLICATE_MSB_TO_ALL(x)))*

*static unsigned char constant_time_eq_8(unsigned a, unsigned b)*
* {*
* unsigned c = a ^ b;*
* c--;*
* return DUPLICATE_MSB_TO_ALL_8(c);*
* }*

OpenSSL 1.0.2d has the function constant_time_eq_8 defined as below.

static inline unsigned int constant_time_msb(unsigned int a)
{
return 0 - (a >> (sizeof(a) * 8 - 1));
}

static inline unsigned int constant_time_is_zero(unsigned int a)
{
return constant_time_msb(~a & (a - 1));
}

static inline unsigned int constant_time_eq(unsigned int a, unsigned int b)
{
return constant_time_is_zero(a ^ b);
}

static inline unsigned char constant_time_eq_8(unsigned int a, unsigned int
b)
{
return (unsigned char)(constant_time_eq(a, b));
}


Regards
Jaya

On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell  wrote:

>
>
> On 04/12/15 11:31, Jayalakshmi bhat wrote:
> > Hi Matt,
> >
> > Thanks a lot for the response.
> >
> > Is your application a client or a server? Are both ends using
> > OpenSSL 1.0.2d? If not, what is the other end using?
> >>>Our device has both TLS client,server apps. As client, device
> communicates with radius server, LDAP server etc.As
> > server device is accessed using various web browsers.
> > Hence both the end will not be OpenSSL 1.0.2d.
> >
> > How exactly are you doing that? Which specific cipher are you seeing
> fail?
> >>> We have provided user option to select TLS protocol versions similar
> to the browsers. Depending upon the user configurations we set the protocol
> flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL
> context using SSL_CTX_clear_options/SSL_CTX_set_options.
> >>> We have provided user option to chose ciphers as well.
> > All these are in the application space,no changes have been done and
> > they have been working good with OpenSSL 1.0.1c. Only the library is
> > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers
> > and with both the ciphers issue is seen.
> >
> > Are you able to provide a packet capture?
> >>> Please find the attached traces for server mode.
> > What O/S is this on?
> >>>This is built for WinCE and Vxworks
>
> Thanks. Please could you also send the exact patch that you applied that
> resolved the issue?
>
> Matt
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi Matt,

I replaced constant_time_eq_8 usage in s3_cbc.c with the implementation
available in OpenSSL 1.0.1e. Things worked fine.

Regards
Jaya

On Fri, Dec 4, 2015 at 7:04 PM, Matt Caswell  wrote:

>
>
> On 04/12/15 11:31, Jayalakshmi bhat wrote:
> > Hi Matt,
> >
> > Thanks a lot for the response.
> >
> > Is your application a client or a server? Are both ends using
> > OpenSSL 1.0.2d? If not, what is the other end using?
> >>>Our device has both TLS client,server apps. As client, device
> communicates with radius server, LDAP server etc.As
> > server device is accessed using various web browsers.
> > Hence both the end will not be OpenSSL 1.0.2d.
> >
> > How exactly are you doing that? Which specific cipher are you seeing
> fail?
> >>> We have provided user option to select TLS protocol versions similar
> to the browsers. Depending upon the user configurations we set the protocol
> flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL
> context using SSL_CTX_clear_options/SSL_CTX_set_options.
> >>> We have provided user option to chose ciphers as well.
> > All these are in the application space,no changes have been done and
> > they have been working good with OpenSSL 1.0.1c. Only the library is
> > upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers
> > and with both the ciphers issue is seen.
> >
> > Are you able to provide a packet capture?
> >>> Please find the attached traces for server mode.
> > What O/S is this on?
> >>>This is built for WinCE and Vxworks
>
> Thanks. Please could you also send the exact patch that you applied that
> resolved the issue?
>
> Matt
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Nounou Dadoun]

Just coincidentally we may have an issue in a pending release that looks much 
like this scenario as well;
In our case, the server is 1.0.2d and the client is not.

 I'll update details as I get them .. N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn


This email, including any files attached hereto (the "email"), contains 
privileged and confidential information and is only for the intended 
addressee(s). If this email has been sent to you in error, such sending does 
not constitute waiver of privilege and we request that you kindly delete the 
email and notify the sender. Any unauthorized use or disclosure of this email 
is prohibited. Avigilon and certain other trade names used herein are the 
registered and/or unregistered trademarks of Avigilon Corporation and/or its 
affiliates in Canada and other jurisdictions worldwide.



-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Matt Caswell
Sent: Friday, December 04, 2015 5:35 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in 
OpenSSL 1.0.2d

On 04/12/15 11:31, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> Thanks a lot for the response. 
> 
> Is your application a client or a server? Are both ends using OpenSSL 
> 1.0.2d? If not, what is the other end using?
>>>Our device has both TLS client,server apps. As client, device 
>>>communicates with radius server, LDAP server etc.As
> server device is accessed using various web browsers. 
> Hence both the end will not be OpenSSL 1.0.2d.
> 
> How exactly are you doing that? Which specific cipher are you seeing fail?
>>> We have provided user option to select TLS protocol versions similar to the 
>>> browsers. Depending upon the user configurations we set the protocol flags 
>>> (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context 
>>> using SSL_CTX_clear_options/SSL_CTX_set_options.
>>> We have provided user option to chose ciphers as well. 
> All these are in the application space,no changes have been done and 
> they have been working good with OpenSSL 1.0.1c. Only the library is 
> upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC 
> ciphers and with both the ciphers issue is seen.
> 
> Are you able to provide a packet capture?
>>> Please find the attached traces for server mode.
> What O/S is this on?
>>>This is built for WinCE and Vxworks

Thanks. Please could you also send the exact patch that you applied that 
resolved the issue?

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 04/12/15 11:31, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> Thanks a lot for the response. 
> 
> Is your application a client or a server? Are both ends using
> OpenSSL 1.0.2d? If not, what is the other end using?
>>>Our device has both TLS client,server apps. As client, device communicates 
>>>with radius server, LDAP server etc.As
> server device is accessed using various web browsers. 
> Hence both the end will not be OpenSSL 1.0.2d.
> 
> How exactly are you doing that? Which specific cipher are you seeing fail?
>>> We have provided user option to select TLS protocol versions similar to the 
>>> browsers. Depending upon the user configurations we set the protocol flags 
>>> (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL context 
>>> using SSL_CTX_clear_options/SSL_CTX_set_options.
>>> We have provided user option to chose ciphers as well. 
> All these are in the application space,no changes have been done and
> they have been working good with OpenSSL 1.0.1c. Only the library is
> upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers
> and with both the ciphers issue is seen.
> 
> Are you able to provide a packet capture?
>>> Please find the attached traces for server mode.
> What O/S is this on?
>>>This is built for WinCE and Vxworks

Thanks. Please could you also send the exact patch that you applied that
resolved the issue?

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

For clarity, which version of WinCE, and which CPU (Arm,
MIPS,PPC, x86, SH3, SH4, ...)?

Which Microsoft Compiler version (EVC3, EVC4, one of the
Visual Studio projects, 3rd party compiler) and which
exact compiler version (reported by running the compiler
executable (named according to CPU) with no arguments.

I ask because your proposed fix may be affected by compiler and/or CPU 
quirks.


On 04/12/2015 12:31, Jayalakshmi bhat wrote:

Hi Matt,

Thanks a lot for the response.

Is your application a client or a server? Are both ends using OpenSSL 
1.0.2d? If not, what is the other end using?
>>Our device has both TLS client,server apps. As client, device communicates with radius 
server, LDAP server etc.As server device is accessed using various 
web browsers.

Hence both the end will not be OpenSSL 1.0.2d.

How exactly are you doing that? Which specific cipher are you seeing fail?
>> We have provided user option to select TLS protocol versions similar to the browsers. 
Depending upon the user configurations we set the protocol flags 
(SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL 
context using SSL_CTX_clear_options/SSL_CTX_set_options.

>> We have provided user option to chose ciphers as well.
All these are in the application space,no changes have been done and 
they have been working good with OpenSSL 1.0.1c. Only the library is 
upgraded to OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC 
ciphers and with both the ciphers issue is seen.


Are you able to provide a packet capture?
>> Please find the attached traces for server mode.
What O/S is this on?
>>This is built for WinCE and Vxworks

Regards
Jaya



On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell > wrote:


Hello Jaya

We're going to need some more information. There isn't a generic
problem
with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so
there is something specific about your environment that is causing the
issue. Comments inserted below.

On 04/12/15 06:53, Jayalakshmi bhat wrote:
> Hi All,
>
>
>
> Recently we have ported OpenSSL 1.0.2d. Everything works perfect
except
> the below explained issue.

Is your application a client or a server? Are both ends using OpenSSL
1.0.2d? If not, what is the other end using?


> When we enable only TLS 1.0 protocol and select CBC ciphers,

How exactly are you doing that? Which specific cipher are you
seeing fail?


> Now my question is whatever I did is it correct?

That would not be a recommended solution

> Or Do need to replace
> complete s3_cbc.c with OpenSSL 1.0.1e?

No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2.

Some other questions:

Are you able to provide a packet capture?
How did you build OpenSSL...i.e. what "Configure" options did you use?
What O/S is this on?

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




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



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi Matt,

Thanks a lot for the response.

Is your application a client or a server? Are both ends using OpenSSL 1.0.2d?
If not, what is the other end using?
>>Our device has both TLS client,server apps. As client, device
communicates with radius server, LDAP server etc.As server device is
accessed using various web browsers.
Hence both the end will not be OpenSSL 1.0.2d.

How exactly are you doing that? Which specific cipher are you seeing fail?
>> We have provided user option to select TLS protocol versions similar to
the browsers. Depending upon the user configurations we set the protocol
flags (SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2) in the SSL
context using SSL_CTX_clear_options/SSL_CTX_set_options.
>> We have provided user option to chose ciphers as well.
All these are in the application space,no changes have been done and they
have been working good with OpenSSL 1.0.1c. Only the library is upgraded to
OpenSSL 1.0.2d.I have used AES256-CBC and AES128 CBC ciphers and with both
the ciphers issue is seen.

Are you able to provide a packet capture?
>> Please find the attached traces for server mode.
What O/S is this on?
>>This is built for WinCE and Vxworks

Regards
Jaya



On Fri, Dec 4, 2015 at 3:02 PM, Matt Caswell  wrote:

> Hello Jaya
>
> We're going to need some more information. There isn't a generic problem
> with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so
> there is something specific about your environment that is causing the
> issue. Comments inserted below.
>
> On 04/12/15 06:53, Jayalakshmi bhat wrote:
> > Hi All,
> >
> >
> >
> > Recently we have ported OpenSSL 1.0.2d. Everything works perfect except
> > the below explained issue.
>
> Is your application a client or a server? Are both ends using OpenSSL
> 1.0.2d? If not, what is the other end using?
>
>
> > When we enable only TLS 1.0 protocol and select CBC ciphers,
>
> How exactly are you doing that? Which specific cipher are you seeing fail?
>
>
> > Now my question is whatever I did is it correct?
>
> That would not be a recommended solution
>
> > Or Do need to replace
> > complete s3_cbc.c with OpenSSL 1.0.1e?
>
> No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2.
>
> Some other questions:
>
> Are you able to provide a packet capture?
> How did you build OpenSSL...i.e. what "Configure" options did you use?
> What O/S is this on?
>
> Matt
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


server.pcapng
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

Hello Jaya

We're going to need some more information. There isn't a generic problem
with CBC ciphers and TLS1.0 in 1.0.2d (it's working fine for me) - so
there is something specific about your environment that is causing the
issue. Comments inserted below.

On 04/12/15 06:53, Jayalakshmi bhat wrote:
> Hi All,
> 
>  
> 
> Recently we have ported OpenSSL 1.0.2d. Everything works perfect except
> the below explained issue.

Is your application a client or a server? Are both ends using OpenSSL
1.0.2d? If not, what is the other end using?


> When we enable only TLS 1.0 protocol and select CBC ciphers,

How exactly are you doing that? Which specific cipher are you seeing fail?


> Now my question is whatever I did is it correct?

That would not be a recommended solution

> Or Do need to replace
> complete s3_cbc.c with OpenSSL 1.0.1e?

No. You cannot just copy and paste stuff from 1.0.1 to 1.0.2.

Some other questions:

Are you able to provide a packet capture?
How did you build OpenSSL...i.e. what "Configure" options did you use?
What O/S is this on?

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users