[openssl-users] free certs: bad idea wosign/startcom/startssl/startencrypt; good alt's

[Johann v . Preußen]

this is a re-worked report i prepared that some might find useful.*

CAUTION:* there are several seriously troubling events surrounding WoSign *^1 * 
(AKA startcom, AKA startssl, and AKA startencrypt) and any of their 
affiliated/subsidiary businesses:


1. wosign purchased startcom/startssl/startencrypt [DBA's of 'Start Commercial
   LTD' (an Israeli company); hereinafter '*startcom*'] last year. although
   obfuscation by the parties makes determining the actual control-transfer
   date impossible, the change-over may have begun in 2014. both companies long
   completely and publicly denied any change of control even as late as
   2016.JUL despite it being a matter of public record that:
1.   the entire stock issuance from 15 startcom shareholders including
   founder Revital (AKA 'Eddy') Nigg's majority ownership was transferred
   in 2015.NOV;
2.   beneficiary of the stock deal was 'StartCom CA Limited' a UK company
   (09744347);
3.   the UK company is wholly-owned by 'StartCom CA Limited' (yes, exactly
   the same name again) a Hong Kong company (CRN 2271553) with a sole
   director being Wang *^1 *; and
4.   the Hong Kong entity is then owned by wosign.
2. in fact, to-date neither firm has actually admitted what has happened re
   transfer of control, domiciling of operations, and changes in management
   personnel. this reticence is despite some aspects of the transactions
   becoming common knowledge in the security community;
3. wosign attempted (rather poorly it turned out) to make it appear that wosign
   was actually a subsidiary of startcom and startcom's remnant personnel and
   former shareholders abetted this *^2 *;
4. startcom is an Israeli company and -- as one would expect -- was subjected
   to strict auditing and monitoring by the Israeli government to the benefit
   of all the recipients of their certs ... until the ownership change that is;
5. wosign is a mainland Chinese (PRC) company which completely controls
   startcom operations in IL, UK, CN, and US;
6. earlier this year and last wosign -- amongst other deceptive actions -- 
   tried to circumvent certain mandated changes to certificate authority (CA)

   practice by back-/forward-dating certs and issuing certs with duplicate
   serial numbers while their CA compliance auditors Ernst and Young (Hong
   Kong) were complicit in covering up these and other forbidden practices *^3 
*;
7. in response to all these discoveries, mozilla's firefox version 51 and all
   look-alikes using their gecko engine have stopped accepting any new (issued
   on/after 2016.OCT.21) certs that trace back to
   wosign/startcom/startssl/startencrypt root/intermediate/cross-signed certs
   and have banned Hong Kong Ernst and Young CPA's from certifying any CA 
audits;
8. unless wosign and its subsidiaries come up with new root certificates and
   provide acceptable audit results for their CP/CPS/operations by 2017.MAR,
   all of wosign-affiliated root/intermediate/cross-signed certs will be
   removed from mozilla's certificate store; and
9. mozilla has stated that if it detects any further fraud such as exhibited in
   Item 6, /supra/, all security updates to all its software versions will
   immediately remove wosign-based "trusted" certs from the mozilla root
   certificate store on the device being updated which will cause the universe
   of wosign-issued certs to become un-trusted in the mozilla browser family no
   matter when they were issued.

*OBVIOUS CONCLUSION: *do not just walk away from wosign, startcom, qihoo, et 
alii but *RUN! *i can think of nothing worse than trusting a PRC firm with my 
sites' security. OK, if that hyperbole is not enough, try my personal idea of 
what should be network no-go and it pretty much lies in the swath West of Japan 
and East of Germany.


*THE ALTERNATIVE: *the immediate free cert replacement avenue is through 
letsencrypt.org that uses the cert issuance/renewal protocol ACME. although 
letsencrypt will not be found in most (if any) browser "trusted" root 
certificate stores, they use cross-signed intermediate CA certs from a root that 
is. there are an ever-growing number of open-source scripts (bash, perl, python, 
go, ...) available to automate the process which one can even customize for your 
particular needs.


there are letsencrypt plug-ins/modules for apache to make your set-up less 
painful. you can use the nginx process with a lua module to /really /fully 
automate _/everything!/_ if you want to go /de luxe/ there is the openresty 
bundle that combines nginx with lua and adds a host of other nginx "add-in" 
enhancements automatically and some more rarely required that one specifies.


if you have looked at openresty or other bundles before and been turned off 
because there was nothing for your favorite distro/pkg-mgr and the thoughts of 
maintaining a 2kb configure line immediately switched your focus over to happy 
hour, look again! with openresty repo's are 

Re: [openssl-users] free certs: bad idea wosign/startcom/startssl/startencrypt; good alt's

[Salz, Rich]

Folks might find this article, *and the things it links to* as useful starting 
points.
   
https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/

I am not sure if general discussion of CA trust issues is appropriate for 
openssl-users.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 1.1.0b fails to negotiate with an old OpenSSL client

[Michael Kocum]

1.1.0b fails to negotiate from an old program that uses OpenSSL.
The same old program can connect to 1.0.2h without any problem.

Here is the debug log of the server. Maybe someone can point me in the right 
direction what the problem might be.

openssl s_server -debug -state -bugs -serverpref -tlsextdebug -accept 25 -cert 
selfsigned.pem
Using default temp DH parameters
ACCEPT
SSL_accept:before SSL initialization
read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
 - 80 c8 01 03 01.
read from 0x14fffe0 [0x1509b58] (197 bytes => 197 (0xC5))
 - 00 9f 00 00 00 20 00 c0-14 00 c0 0a 00 00 39 00   . 9.
0010 - 00 38 00 c0 0f 00 c0 05-00 00 35 00 00 88 00 00   .85.
0020 - 87 00 00 84 00 c0 12 00-c0 08 00 00 16 00 00 13   
0030 - 00 c0 0d 00 c0 03 00 00-0a 07 00 c0 00 c0 13 00   
0040 - c0 09 00 00 33 00 00 32-00 c0 0e 00 c0 04 00 00   3..2
0050 - 2f 00 00 9a 00 00 99 00-00 45 00 00 44 00 00 96   /E..D...
0060 - 00 00 41 00 00 07 05 00-80 03 00 80 00 c0 11 00   ..A.
0070 - c0 07 00 c0 0c 00 c0 02-00 00 05 00 00 04 01 00   
0080 - 80 00 00 15 00 00 12 00-00 09 06 00 40 00 00 14   @...
0090 - 00 00 11 00 00 08 00 00-06 04 00 80 00 00 03 02   
00a0 - 00 80 00 00 ff 30 16 85-97 e0 9f e3 aa b1 07 47   .0.G
00b0 - 99 a5 7c 38 20 cd 51 39-a1 14 2f 60 50 87 26 62   ..|8 .Q9../`P.&b
00c0 - 0e c8 73 53 86..sS.
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write certificate
SSL_accept:SSLv3/TLS write key exchange
write to 0x14fffe0 [0x1512d58] (1281 bytes => 1281 (0x501))
 - 16 03 01 00 51 02 00 00-4d 03 01 2c 21 40 97 a5   Q...M..,!@..
0010 - 67 b2 a4 a7 63 cc f0 58-af 24 a4 ca 61 d8 fa bf   g...c..X.$..a...
0020 - a8 50 84 29 20 54 70 1e-f5 8e c2 20 bf ad ba d7   .P.) Tp 
0030 - fa 23 5b 77 eb 0f 30 a2-49 61 f9 ca 9f 28 3f 14   .#[w..0.Ia...(?.
0040 - bb d7 cd cf 5c 1b 69 d8-6b db 0e f7 c0 14 00 00   \.i.k...
0050 - 05 ff 01 00 01 00 16 03-01 03 6e 0b 00 03 6a 00   ..n...j.
0060 - 03 67 00 03 64 30 82 03-60 30 82 02 48 02 09 00   .g..d0..`0..H...
0070 - c0 99 99 49 38 26 56 04-30 0d 06 09 2a 86 48 86   ...I8&V.0...*.H.
0080 - f7 0d 01 01 05 05 00 30-72 31 0b 30 09 06 03 55   ...0r1.0...U
0090 - 04 06 13 02 41 54 31 0b-30 09 06 03 55 04 08 13   AT1.0...U...
00a0 - 02 41 54 31 0b 30 09 06-03 55 04 07 13 02 41 54   .AT1.0...UAT
00b0 - 31 0d 30 0b 06 03 55 04-0a 13 04 54 45 53 54 31   1.0...UTEST1
00c0 - 0d 30 0b 06 03 55 04 0b-13 04 54 45 53 54 31 0d   .0...UTEST1.
00d0 - 30 0b 06 03 55 04 03 13-04 54 45 53 54 31 1c 30   0...UTEST1.0
00e0 - 1a 06 09 2a 86 48 86 f7-0d 01 09 01 16 0d 74 65   ...*.Hte
00f0 - 73 74 40 74 65 73 74 2e-63 6f 6d 30 1e 17 0d 31   st@test.com0...1
0100 - 33 30 31 31 30 31 37 31-38 34 33 5a 17 0d 31 37   30110171843Z..17
0110 - 30 31 30 39 31 37 31 38-34 33 5a 30 72 31 0b 30   0109171843Z0r1.0
0120 - 09 06 03 55 04 06 13 02-41 54 31 0b 30 09 06 03   ...UAT1.0...
0130 - 55 04 08 13 02 41 54 31-0b 30 09 06 03 55 04 07   UAT1.0...U..
0140 - 13 02 41 54 31 0d 30 0b-06 03 55 04 0a 13 04 54   ..AT1.0...UT
0150 - 45 53 54 31 0d 30 0b 06-03 55 04 0b 13 04 54 45   EST1.0...UTE
0160 - 53 54 31 0d 30 0b 06 03-55 04 03 13 04 54 45 53   ST1.0...UTES
0170 - 54 31 1c 30 1a 06 09 2a-86 48 86 f7 0d 01 09 01   T1.0...*.H..
0180 - 16 0d 74 65 73 74 40 74-65 73 74 2e 63 6f 6d 30   ..test@test.com0
0190 - 82 01 22 30 0d 06 09 2a-86 48 86 f7 0d 01 01 01   .."0...*.H..
01a0 - 05 00 03 82 01 0f 00 30-82 01 0a 02 82 01 01 00   ...0
01b0 - d3 32 55 70 37 65 9c 8d-63 cf 8c 65 fb ac cf 44   .2Up7e..c..e...D
01c0 - 70 33 64 ae 9c db e6 3a-1d c5 be 66 f1 9a d0 79   p3d:...f...y
01d0 - c3 6b 54 23 0e 3a 62 56-75 b2 c5 73 38 7c 02 4f   .kT#.:bVu..s8|.O
01e0 - ee 54 e3 99 e9 23 23 c8-ed f9 56 ea 0d 58 4f c0   .T...##...V..XO.
01f0 - 39 ea 55 57 7d e4 6a 24-25 c3 50 f0 49 79 f7 8a   9.UW}.j$%.P.Iy..
0200 - 3d f1 a4 dc 5f 0f 3f e4-1c 1c 24 0b 7c 8a 70 ef   =..._.?...$.|.p.
0210 - 22 80 bd 63 1d 3f 59 fd-aa 38 1d d4 9b be e8 f8   "..c.?Y..8..
0220 - b3 6b cd 4f 0b 6f f4 91-db 3c 0a 57 c1 d4 78 f7   .k.O.o...<.W..x.
0230 - 55 b1 f5 d4 f8 e6 27 6e-a6 24 8d d5 b0 59 ad 57   U.'n.$...Y.W
0240 - 74 78 16 cf 96 4f f3 1b-0f f7 00 2e f2 10 78 a1   tx...Ox.
0250 - 46 2a 70 00 f1 17 ae 9f-c8 79 5f 2c e9 fd bb 93   F*p..y_,
0260 - 1d e1 61 08 35 e7 8a 8a-93 16 70 ea d7 34 33 41   ..a.5.p..43A
0270 - 60 74 ab 9d 0c f3 19 a0-e5 0b 89 54 6f eb e7 de   `t.To...
0280 - 6e 09 b3 fd 8e e7 c4 6c-91 1b a7 c6 d4 72 39 09   n..l.r9.
0290 - 74 f4 8c c5 6a 44 01 8a-e0 68 44 55 ea 7d 4e 13   t...jD...hDU.}N.
02a0 - 9f 2f ac fc 8a 39 e7 ee-d4 ce 04 00 10 cf 50 6b   ./...9Pk
02b0 - 02 03 01 00 

Re: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL client

[Salz, Rich]

The old version is probably using DH keys that are too small.

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

[openssl-users] Enabling FIPS on an custom embedded system.

[Eric Tremblay]

Hi all,



I have built the FIPS module into our Platform but I am stuck at the point
to enable it.



We need FIPS to be enabled « Platform wide » not just for one application.



I have read the documentation and search on the web for answer but it seem
that I would have

to modify a package or write a small application just to enable FIPS.



Is there another way to enable it on startup of Linux ?  or maybe something
in OpenSSH ?



I also read about the OPENSSL_Config in the User Guide but I’m not sure
if/who and how it is called.



I am working with OpenSSL 1.0.2j and FIPS 2.0.9.



Thanks



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

Re: [openssl-users] Enabling FIPS on an custom embedded system.

[Steve Marquess]

On 10/26/2016 04:37 PM, Eric Tremblay wrote:
> Hi all,
> 
> __ __
> 
> I have built the FIPS module into our Platform but I am stuck at the
> point to enable it.
> 
> __ __
> 
> We need FIPS to be enabled « Platform wide » not just for one
> application.
> 
> __ __
> 
> I have read the documentation and search on the web for answer but it
> seem that I would have 
> 
> to modify a package or write a small application just to enable FIPS.
> 
> __ __
> 
> Is there another way to enable it on startup of Linux ?  or maybe
> something in OpenSSH ?
> 
> __ __
> 
> I also read about the OPENSSL_Config in the User Guide but I’m not sure
> if/who and how it is called.
> 
> __ __
> 
> I am working with OpenSSL 1.0.2j and FIPS 2.0.9.
> 
> __ __
> 
> Thanks
> 
> __ __
> 
> Eric
> 
> 
> 


Hmmm ... where to start.

First there is really no such thing as "enabling FIPS" for a platform.
The FIPS module is executable code that runs in the context of a
process, and to be righteous FIPS-wise each process (that uses
cryptography) must invoke the FIPS_mode_set() call that performs the
mandatory POST (Power Up Self Test). Note that is true even when the
FIPS module is embedded in a shared library (the "FIPS enabled"
OpenSSL), as each process using said shared library maps writable data
into its own private address space.

So to make the sweeping claim that a "platform" is FIPS enabled, you
must make sure that *every* process for that platform enables FIPS mode
via a FIPS_mode_set() call (whether directly or indirectly). Note that
for your typical general purpose (e.g. Windows or Linux-like) operating
system that is an essentially unachievable goal, as not all of the many
crypto-using applications are readily converted to use the FIPS enabled
OpenSSL (for instance OpenSSH needs non-trivial hacks). Likewise
kernel-mode crypto can't be addressed with the OpenSSL FIPS module.

For that reason the wise and prudent vendor does not attempt to "enable
FIPS" for an entire platform (for Level 1 validations), but rather only
makes claims about specific individual applications running on that
platform.

In the case where all processes of interest are compatible with the FIPS
capable OpenSSL (specifically, not referencing any other crypto
implementations, or non-approved cryptographic operations), then
OPENSSL_config() can in principle be used to indirectly call
FIPS_mode_set() for each such application. That is only *after* every
such application/process has *first* been modified for compatibility
with the FIPS capable OpenSSL. Very few applications not already
designed to support the OpenSSL FIPS module will be compatible without
some degree of modification.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Enabling FIPS on an custom embedded system.

[Eric Tremblay]

Hi Steve,

Thanks for the quick reply.

That is what I had understand from my reading but wasn't sure.

My next question is about OpenSSH.  There is no official support in OpenSSH
for FIPS at the moment right ?

Thanks

Eric



On Wed, Oct 26, 2016 at 5:04 PM, Steve Marquess 
wrote:

> On 10/26/2016 04:37 PM, Eric Tremblay wrote:
> > Hi all,
> >
> > __ __
> >
> > I have built the FIPS module into our Platform but I am stuck at the
> > point to enable it.
> >
> > __ __
> >
> > We need FIPS to be enabled « Platform wide » not just for one
> > application.
> >
> > __ __
> >
> > I have read the documentation and search on the web for answer but it
> > seem that I would have 
> >
> > to modify a package or write a small application just to enable FIPS.
> >
> > __ __
> >
> > Is there another way to enable it on startup of Linux ?  or maybe
> > something in OpenSSH ?
> >
> > __ __
> >
> > I also read about the OPENSSL_Config in the User Guide but I’m not sure
> > if/who and how it is called.
> >
> > __ __
> >
> > I am working with OpenSSL 1.0.2j and FIPS 2.0.9.
> >
> > __ __
> >
> > Thanks
> >
> > __ __
> >
> > Eric
> >
> >
> >
>
>
> Hmmm ... where to start.
>
> First there is really no such thing as "enabling FIPS" for a platform.
> The FIPS module is executable code that runs in the context of a
> process, and to be righteous FIPS-wise each process (that uses
> cryptography) must invoke the FIPS_mode_set() call that performs the
> mandatory POST (Power Up Self Test). Note that is true even when the
> FIPS module is embedded in a shared library (the "FIPS enabled"
> OpenSSL), as each process using said shared library maps writable data
> into its own private address space.
>
> So to make the sweeping claim that a "platform" is FIPS enabled, you
> must make sure that *every* process for that platform enables FIPS mode
> via a FIPS_mode_set() call (whether directly or indirectly). Note that
> for your typical general purpose (e.g. Windows or Linux-like) operating
> system that is an essentially unachievable goal, as not all of the many
> crypto-using applications are readily converted to use the FIPS enabled
> OpenSSL (for instance OpenSSH needs non-trivial hacks). Likewise
> kernel-mode crypto can't be addressed with the OpenSSL FIPS module.
>
> For that reason the wise and prudent vendor does not attempt to "enable
> FIPS" for an entire platform (for Level 1 validations), but rather only
> makes claims about specific individual applications running on that
> platform.
>
> In the case where all processes of interest are compatible with the FIPS
> capable OpenSSL (specifically, not referencing any other crypto
> implementations, or non-approved cryptographic operations), then
> OPENSSL_config() can in principle be used to indirectly call
> FIPS_mode_set() for each such application. That is only *after* every
> such application/process has *first* been modified for compatibility
> with the FIPS capable OpenSSL. Very few applications not already
> designed to support the OpenSSL FIPS module will be compatible without
> some degree of modification.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marqu...@openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> 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] Enabling FIPS on an custom embedded system.

[Scott Neugroschl]

No.   You can check with the OpenSSH mailing list, but I’m pretty darned sure 
the answer is no.


---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 
583-2874|Fax 805 583-0124 |





From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Eric Tremblay
Sent: Wednesday, October 26, 2016 3:06 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Enabling FIPS on an custom embedded system.

Hi Steve,

Thanks for the quick reply.

That is what I had understand from my reading but wasn't sure.

My next question is about OpenSSH.  There is no official support in OpenSSH for 
FIPS at the moment right ?

Thanks

Eric



On Wed, Oct 26, 2016 at 5:04 PM, Steve Marquess 
mailto:marqu...@openssl.com>> wrote:
On 10/26/2016 04:37 PM, Eric Tremblay wrote:
> Hi all,
>
> __ __
>
> I have built the FIPS module into our Platform but I am stuck at the
> point to enable it.
>
> __ __
>
> We need FIPS to be enabled « Platform wide » not just for one
> application.
>
> __ __
>
> I have read the documentation and search on the web for answer but it
> seem that I would have 
>
> to modify a package or write a small application just to enable FIPS.
>
> __ __
>
> Is there another way to enable it on startup of Linux ?  or maybe
> something in OpenSSH ?
>
> __ __
>
> I also read about the OPENSSL_Config in the User Guide but I’m not sure
> if/who and how it is called.
>
> __ __
>
> I am working with OpenSSL 1.0.2j and FIPS 2.0.9.
>
> __ __
>
> Thanks
>
> __ __
>
> Eric
>
>
>


Hmmm ... where to start.

First there is really no such thing as "enabling FIPS" for a platform.
The FIPS module is executable code that runs in the context of a
process, and to be righteous FIPS-wise each process (that uses
cryptography) must invoke the FIPS_mode_set() call that performs the
mandatory POST (Power Up Self Test). Note that is true even when the
FIPS module is embedded in a shared library (the "FIPS enabled"
OpenSSL), as each process using said shared library maps writable data
into its own private address space.

So to make the sweeping claim that a "platform" is FIPS enabled, you
must make sure that *every* process for that platform enables FIPS mode
via a FIPS_mode_set() call (whether directly or indirectly). Note that
for your typical general purpose (e.g. Windows or Linux-like) operating
system that is an essentially unachievable goal, as not all of the many
crypto-using applications are readily converted to use the FIPS enabled
OpenSSL (for instance OpenSSH needs non-trivial hacks). Likewise
kernel-mode crypto can't be addressed with the OpenSSL FIPS module.

For that reason the wise and prudent vendor does not attempt to "enable
FIPS" for an entire platform (for Level 1 validations), but rather only
makes claims about specific individual applications running on that
platform.

In the case where all processes of interest are compatible with the FIPS
capable OpenSSL (specifically, not referencing any other crypto
implementations, or non-approved cryptographic operations), then
OPENSSL_config() can in principle be used to indirectly call
FIPS_mode_set() for each such application. That is only *after* every
such application/process has *first* been modified for compatibility
with the FIPS capable OpenSSL. Very few applications not already
designed to support the OpenSSL FIPS module will be compatible without
some degree of modification.

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
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] 1.1.0b fails to negotiate with an old OpenSSL client

[Matt Caswell]

On 26/10/16 21:06, Michael Kocum wrote:
> 1.1.0b fails to negotiate from an old program that uses OpenSSL.
> The same old program can connect to 1.0.2h without any problem.
> 
> Here is the debug log of the server. Maybe someone can point me in the right 
> direction what the problem might be.
> 
> openssl s_server -debug -state -bugs -serverpref -tlsextdebug -accept 25 
> -cert selfsigned.pem
> Using default temp DH parameters
> ACCEPT
> SSL_accept:before SSL initialization
> read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
>  - 80 c8 01 03 01.
> read from 0x14fffe0 [0x1509b58] (197 bytes => 197 (0xC5))
>  - 00 9f 00 00 00 20 00 c0-14 00 c0 0a 00 00 39 00   . 9.
> 0010 - 00 38 00 c0 0f 00 c0 05-00 00 35 00 00 88 00 00   .85.
> 0020 - 87 00 00 84 00 c0 12 00-c0 08 00 00 16 00 00 13   
> 0030 - 00 c0 0d 00 c0 03 00 00-0a 07 00 c0 00 c0 13 00   
> 0040 - c0 09 00 00 33 00 00 32-00 c0 0e 00 c0 04 00 00   3..2
> 0050 - 2f 00 00 9a 00 00 99 00-00 45 00 00 44 00 00 96   /E..D...
> 0060 - 00 00 41 00 00 07 05 00-80 03 00 80 00 c0 11 00   ..A.
> 0070 - c0 07 00 c0 0c 00 c0 02-00 00 05 00 00 04 01 00   
> 0080 - 80 00 00 15 00 00 12 00-00 09 06 00 40 00 00 14   @...
> 0090 - 00 00 11 00 00 08 00 00-06 04 00 80 00 00 03 02   
> 00a0 - 00 80 00 00 ff 30 16 85-97 e0 9f e3 aa b1 07 47   .0.G
> 00b0 - 99 a5 7c 38 20 cd 51 39-a1 14 2f 60 50 87 26 62   ..|8 .Q9../`P.&b
> 00c0 - 0e c8 73 53 86..sS.

The above indicates that the client has sent an SSLv2 Compatible
ClientHello, although has indicated support for TLSv1.0. OpenSSL 1.1.0
doesn't support SSLv2, but it *does* still support the (very old) SSLv2
Compat ClientHello format. Unfortunately an SSLv2 compat hello does
*not* have an extensions section, which is important for communicating
info such as supported curves etc when using EC based ciphersuites.


> SSL_accept:before SSL initialization
> SSL_accept:SSLv3/TLS read client hello
> SSL_accept:SSLv3/TLS write server hello
> SSL_accept:SSLv3/TLS write certificate
> SSL_accept:SSLv3/TLS write key exchange
> write to 0x14fffe0 [0x1512d58] (1281 bytes => 1281 (0x501))
>  - 16 03 01 00 51 02 00 00-4d 03 01 2c 21 40 97 a5   Q...M..,!@..
> 0010 - 67 b2 a4 a7 63 cc f0 58-af 24 a4 ca 61 d8 fa bf   g...c..X.$..a...
> 0020 - a8 50 84 29 20 54 70 1e-f5 8e c2 20 bf ad ba d7   .P.) Tp 
> 0030 - fa 23 5b 77 eb 0f 30 a2-49 61 f9 ca 9f 28 3f 14   .#[w..0.Ia...(?.
> 0040 - bb d7 cd cf 5c 1b 69 d8-6b db 0e f7 c0 14 00 00   \.i.k...
> 0050 - 05 ff 01 00 01 00 

This is the ServerHello that the server is sending back to the client.
The "c0 14" near the end of line 0040 indicates that the server has
selected TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as the ciphersuite.


>  16 03-01 03 6e 0b 00 03 6a 00   ..n...j.
> 0060 - 03 67 00 03 64 30 82 03-60 30 82 02 48 02 09 00   .g..d0..`0..H...
...snip...lots of uninteresting lines

This is Certificate message sent from server to client.


>   16 03 01 01 2a 0c 00   .8...*..
> 03d0 - 01 26 03 00 1d 20 4f b4-34 86 a8 a0 0a 45 5b 80   .&... O.4E[.
> 03e0 - b0 79 9e bf 4b 91 ed ae-2c b7 ee 64 ff 39 78 c8   .y..K...,..d.9x.
> 03f0 - a0 e7 37 e6 a5 13 01 00-1a 9f 48 8e 91 73 55 3e   ..7...H..sU>
> 0400 - 86 16 04 7e a9 b2 49 16-d6 f6 b3 c2 17 d1 4e 11   ...~..I...N.
> 0410 - c4 67 7c 81 e6 49 a2 04-d7 bc 42 04 8c 2a 0f da   .g|..IB..*..
> 0420 - a0 75 7d 80 98 5b 1a 0f-e2 48 55 06 95 38 0d a6   .u}..[...HU..8..
> 0430 - 84 f0 42 37 6b ee ca e9-e5 7e 13 11 d7 f9 3e f4   ..B7k~>.
> 0440 - b2 ae f1 01 e6 56 ab 7b-46 3b bd 66 de aa ad d7   .V.{F;.f
> 0450 - 41 59 2b 80 2d 76 98 a0-82 c8 d1 00 05 e8 11 da   AY+.-v..
> 0460 - c3 4b c5 15 23 c0 ba 66-8c 9b fc 80 33 c4 e8 f9   .K..#..f3...
> 0470 - 1f c7 82 ba b1 58 0c 87-54 42 b4 ce ed 66 4e 4e   .X..TB...fNN
> 0480 - 3e 51 d4 9f 5f 1e 20 18-b1 5e 6a b9 bb e7 6c b2   >Q.._. ..^j...l.
> 0490 - 2d 27 52 90 70 9f b0 97-cb 6d 23 0b 9d 1c e6 9d   -'R.pm#.
> 04a0 - 71 2a ab 9b a9 42 c9 16-ce a1 86 63 96 fe b2 b6   q*...B.c
> 04b0 - 49 69 5c 80 7b 9d 3d 40-a8 4a 70 51 0a a1 99 a8   Ii\.{.=@.JpQ
> 04c0 - b8 72 52 39 6b 8c c6 91-13 36 fb d5 fe 7d 2b db   .rR9k6...}+.
> 04d0 - 45 3d 73 d9 be de fd 40-19 ed ec 41 84 d5 17 a7   E=s@...A
> 04e0 - 6e 32 05 51 5b e6 56 44-40 2b e8 54 d9 36 cc bb   n2.Q[.VD@+.T.6..
> 04f0 - 77 17 cd f3 7c e7 00 60-

This is the ServerKeyExchange

The "00 1d" on line 03d0 tells you the curve that the server has
selected. That corresponds to Curve 25519 This is a modern curve
which an old client will not understand. The server has selected it
because it didn't get an extension from the client saying what curves it
supports, so it just picked

Re: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL client

[Michael Kocum]

>This is very likely to be your problem. To test the theory, try adding
>"-named_curve P-256" onto your s_server line. P-256 is a much more
>widely supported curve.

Yes, this fixed the problem. 

Thank you for your support in this case.

--
Michael Kocum [DataEnter]
mich...@dataenter.co.at


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