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

[openssl-users] Openssl Compilation Error

[Sonali Priyadarshini]

Hi all

I am compiling Openssl 1.0.h version in SLES 11 SP1 ,in make command I am
facing some errors.I have the instructions properly as given.

The error was:

/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
libcrypto.a(x86_64-gcc.o): relocation R_X86_64_32 against `.text' can not
be used when making a shared object; recompile with -fPIC
libcrypto.a(x86_64-gcc.o): could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [link_a.gnu] Error 1
make[4]: Leaving directory
`/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h'
make[3]: *** [do_linux-shared] Error 2
make[3]: Leaving directory
`/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h'
make[2]: *** [libcrypto.so.1.0.0] Error 2
make[2]: Leaving directory
`/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h'
make[1]: *** [shared] Error 2
make[1]: Leaving directory
`/home/build/ps/openssl-1.0.1h.tar/openssl-1.0.1h/crypto'
make: *** [build_crypto] Error 1


I followed this link

https://stackoverflow.com/questions/10368671/cannot-find-libcrypto-library-error

for solution.

Can anyone  please check this.The reason behind this error.

Thanks & regards

Sonali
___
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

[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

[openssl-users] Updated OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [3 Dec 2015] - Updated [4 Dec 2015]
=

[Updated 4 Dec 2015]: This advisory has been updated to include the details of
CVE-2015-1794, a Low severity issue affecting OpenSSL 1.0.2 which had a fix
included in the released packages but was missed from the advisory text.

NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE
0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS
PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS.

BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193)
==

Severity: Moderate

There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No
EC algorithms are affected. Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites.

This issue affects OpenSSL version 1.0.2.

OpenSSL 1.0.2 users should upgrade to 1.0.2e

This issue was reported to OpenSSL on August 13 2015 by Hanno
Böck. The fix was developed by Andy Polyakov of the OpenSSL
development team.

Certificate verify crash with missing PSS parameter (CVE-2015-3194)
===

Severity: Moderate

The signature verification routines will crash with a NULL pointer dereference
if presented with an ASN.1 signature using the RSA PSS algorithm and absent
mask generation function parameter. Since these routines are used to verify
certificate signature algorithms this can be used to crash any certificate
verification operation and exploited in a DoS attack. Any application which
performs certificate verification is vulnerable including OpenSSL clients and
servers which enable client authentication.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2e
OpenSSL 1.0.1 users should upgrade to 1.0.1q

This issue was reported to OpenSSL on August 27 2015 by Loïc Jonas Etienne
(Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL
development team.

X509_ATTRIBUTE memory leak (CVE-2015-3195)
==

Severity: Moderate

When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak
memory. This structure is used by the PKCS#7 and CMS routines so any
application which reads PKCS#7 or CMS data from untrusted sources is affected.
SSL/TLS is not affected.

This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2e
OpenSSL 1.0.1 users should upgrade to 1.0.1q
OpenSSL 1.0.0 users should upgrade to 1.0.0t
OpenSSL 0.9.8 users should upgrade to 0.9.8zh

This issue was reported to OpenSSL on November 9 2015 by Adam Langley
(Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen
Henson of the OpenSSL development team.

Race condition handling PSK identify hint (CVE-2015-3196)
=

Severity: Low

If PSK identity hints are received by a multi-threaded client then
the values are wrongly updated in the parent SSL_CTX structure. This can
result in a race condition potentially leading to a double free of the
identify hint data.

This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously
listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0
and has not been previously fixed in an OpenSSL 1.0.0 release.

OpenSSL 1.0.2 users should upgrade to 1.0.2d
OpenSSL 1.0.1 users should upgrade to 1.0.1p
OpenSSL 1.0.0 users should upgrade to 1.0.0t

The fix for this issue can be identified in the OpenSSL git repository by commit
ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0).

The fix was developed by Dr. Stephen Henson of the OpenSSL development team.

Anon DH ServerKeyExchange with 0 p parameter (CVE-2015-1794)


Severity: Low

If a client receives a ServerKeyExchange for an anonymous DH ciphersuite with
the value of p set to 0 then a seg fault can occur leading to a possible denial
of service attack.

This issue affects OpenSSL version 1.0.2.

OpenSSL 1.0.2 users should upgrade to 

Re: [openssl-users] [openssl-dev] [openssl.org #4166] Bug: OpenSSL 1.0.1l fails to verify SOME root CAs: error:num=20:unable to get local issuer certificate

[Viktor Dukhovni]

[ Redirecting to openssl-users ]

On Fri, Dec 04, 2015 at 03:25:35PM +, Oliver Schonrock via RT wrote:

> To Reproduce:
> $ openssl s_client -connect api.textmarketer.co.uk:443
> depth=2 C = US, O = "thawte, Inc.", OU = Certification Services
> Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN =
> thawte Primary Root CA
> verify error:num=20:unable to get local issuer certificate
> ...

Despite the CN string, the certificate presented by that server on
the wire is not a root certificate.  See the attached chain.

Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, 
OU=Certification Services Division, CN=Thawte Premium Server 
CA/emailAddress=premium-ser...@thawte.com
Validity
Not Before: Nov 17 00:00:00 2006 GMT
Not After : Dec 30 23:59:59 2020 GMT
Subject: C=US, O=thawte, Inc., OU=Certification Services Division, 
OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

> The same command on FreeBSD 10.2 (OpenSSL 1.0.1p) results in:
> $ openssl s_client -connect api.textmarketer.co.uk:443
> depth=2 C = US, O = "thawte, Inc.", OU = Certification Services
> Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN =
> thawte Primary Root CA
> verify return:1

In 1.0.1p OpenSSL looks in the trust store before consulting the
provided chain.  You likely have a better Thawte certificate there
than the one sent by the server.

-- 
Viktor.
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
21:b8:6b:cc:47:2f:b7:b0:d1:0e:15:eb:af:30:61:8f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=thawte, Inc., OU=Domain Validated SSL, CN=thawte DV SSL 
CA - G2
Validity
Not Before: May 25 00:00:00 2015 GMT
Not After : Jul 23 23:59:59 2017 GMT
Subject: CN=api.textmarketer.co.uk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a6:ca:50:c1:29:ad:4d:da:26:ca:de:ac:8e:05:
ba:ff:00:ae:18:3f:02:ad:39:66:ec:f6:16:23:f0:
80:94:cc:8c:d5:96:9c:63:bc:50:63:07:8b:ad:d5:
86:09:cf:2a:ff:9a:ca:ae:0e:88:07:9b:32:7b:4e:
b0:12:a1:df:a9:02:b5:96:9c:61:55:17:30:79:14:
2c:38:ea:18:07:b4:a1:2d:40:a2:5d:62:0b:bd:67:
41:0e:c9:4e:a3:bd:bf:ce:03:ac:0f:ac:fc:a2:7c:
23:6b:05:ea:88:78:7e:c6:2c:ac:6f:8c:67:2b:6f:
15:c7:cb:a7:ad:2e:8c:27:2f:4f:02:92:1d:6d:72:
15:f7:5d:bf:55:be:53:57:c5:0c:38:29:33:a7:f0:
97:02:c9:00:88:0e:bc:7e:2e:23:37:3b:54:ce:98:
24:fd:6c:cd:5b:d4:5e:fe:c4:8b:60:0e:c6:54:63:
7c:d6:ad:91:eb:53:ce:d6:b6:77:9d:9e:fa:20:a7:
20:7f:2f:00:59:4b:af:50:09:f4:8a:61:58:3d:b3:
b8:ba:ce:79:a7:66:00:c3:a3:a5:a2:71:ab:b3:6e:
40:66:32:c4:b4:2b:b1:37:f5:0c:93:66:68:54:5c:
ba:35:ef:75:62:70:9a:2b:d3:8f:b4:de:3c:79:a4:
ea:c3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name: 
DNS:api.textmarketer.co.uk
X509v3 Basic Constraints: 
CA:FALSE
X509v3 CRL Distribution Points: 

Full Name:
  URI:http://tn.symcb.com/tn.crl

X509v3 Certificate Policies: 
Policy: 2.23.140.1.2.1
  CPS: https://www.thawte.com/cps
  User Notice:
Explicit Text: https://www.thawte.com/repository

X509v3 Authority Key Identifier: 

keyid:9F:B8:C1:A9:6C:F2:F5:C0:22:2A:94:ED:5C:99:AC:D4:EC:D7:C6:07

X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: 
TLS Web Server Authentication, TLS Web Client Authentication
Authority Information Access: 
OCSP - URI:http://tn.symcd.com
CA Issuers - URI:http://tn.symcb.com/tn.crt

Signature Algorithm: sha256WithRSAEncryption
 84:85:37:ae:9c:6f:e8:3f:3b:3d:da:a4:a9:ff:ba:56:3d:ad:
 f9:bf:ea:8f:d8:9d:4b:35:ac:73:76:c4:f6:67:1b:c0:1f:fe:
 7e:3d:56:3b:70:e0:74:71:bd:0d:e0:cd:a7:03:61:8c:25:72:
 4c:6a:c2:db:d7:fd:14:7b:92:0a:8d:2b:0f:f7:c0:c2:0e:46:
 65:29:21:cf:b1:aa:ed:92:b0:db:e7:fe:54:de:fb:1a:a7:b0:
 61:14:fa:a6:14:ab:99:a3:26:8e:75:97:cf:de:fb:33:25:10:
 ef:23:da:91:14:d8:2a:d4:cf:0d:dc:e7:14:4b:9a:ed:31:34:
 e0:a1:7c:1e:2d:0f:e1:52:0d:83:3c:c8:eb:df:43:85:4b:96:
 03:e8:75:a6:46:9b:99:6e:02:e4:38:0b:9c:93:c2:8e:97:db:
 27:77:75:a6:e6:46:c1:02:bd:d4:14:a0:af:3e:f8:56:4f:94:
 

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

[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

[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 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