[openssl-users] Reg issue in alert message

ramakrushna mishra rama.krushna7 at gmail.com
Tue Oct 23 11:32:17 UTC 2018


Hi Matt,

Thanks for your response.
 My client is built with openssl 1.0.0e  and server with openssl 1.1.1.
 I have tried to collect information with wireshark, but I think as my
server and client are running on same machine , it is not capturing
anything. I have also tried with tshark on linux and got no traces again.

I have this trouble both on nt64and linuxx86_64. Do we have any other
mechanism to capture the traces ?

We have internal tracing enabled and I can see following information in our
tracing.
**********************************************************************************
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL State: 16
before SSL initialization
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- ctrl to 00000000 [02457660] (6 bytes => 0 (0x0))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:before
SSL initialization
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- read to 00000000 [02463953] (5 bytes => 5 (0x5))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
0000 - 16 03 01 00 b2                                    .....
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- read to 00000000 [02463958] (178 bytes => 178 (0xB2))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
0000 - 01 00 00 ae 03 03 10 b1-1e 8f f0 07 d6 28 d9 02   .............(..
0010 - b7 91 b4 3d 14 5a af 3e-09 96 2a cf ee 8b ca 30   ...=.Z.>..*....0
0020 - cc 68 9f 2c 2e 6e 00 00-62 00 a5 00 a3 00 a1 00   .h.,.n..b.......
0030 - 9f 00 6b 00 6a 00 69 00-68 00 39 00 38 00 37 00   ..k.j.i.h.9.8.7.
0040 - 36 00 9d 00 3d 00 35 00-a4 00 a2 00 a0 00 9e 00   6...=.5.........
0050 - 67 00 40 00 3f 00 3e 00-33 00 32 00 31 00 30 00   g. at .?.>.3.2.1.0.
0060 - 9a 00 99 00 98 00 97 00-9c 00 3c 00 2f 00 96 00   ..........<./...
0070 - 05 00 04 00 16 00 13 00-10 00 0d 00 0a 00 15 00   ................
0080 - 12 00 0f 00 0c 00 09 00-ff *56 00* 01 00 00 23 00   .........V....#.
0090 - 23 00 00 00 0d 00 16 00-14 06 01 06 02 05 01 05   #...............
00a0 - 02 04 01 04 02 03 01 03-02 02 01 02 02 00 0f 00   ................
00b0 - 01 01                                             ..
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:before
SSL initialization
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- write to 00000000 [024725E0] (7 bytes => 7 (0x7))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
0000 - 15 03 03 00 02 02 56                              ......V
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION ---  write:fatal:unknown
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:error in
error
********************
In the above dump , "56 00 " is present in the cipher suites sent in client
hello.
So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
client hello.
However there is no earlier failure to this handshake.

As per your comment, client should only send it if it witnessed some
earlier failure.
In that case, I have following additional doubt.

-- this set up is working when server is running with TLSv1.2 and only
failing when server has both TLSv1,2 and TLSv1.3 ( i.e with openssl1.1.1).
So are there any changes in openssl1.1.1 which will effect this behavior
when compared to openssl1.0.0e version ?


Thanks and Regards,
Ram Krushna


On Mon, Oct 22, 2018 at 11:21 PM <openssl-users-request at openssl.org> wrote:

> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. Re: What to do with deprecation errors (Salz, Rich)
>    2. Re: What to do with deprecation errors (Matt Caswell)
>    3. Re: To disable CBC ciphers (Jakob Bohm)
>    4. Reg issue in alert message (ramakrushna mishra)
>    5. Re: Reg issue in alert message (Matt Caswell)
>    6. Re: What to do with deprecation errors (Skip Carter)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 Oct 2018 02:08:23 +0000
> From: "Salz, Rich" <rsalz at akamai.com>
> To: Skip Carter <skip at taygeta.com>, "openssl-users at openssl.org"
>         <openssl-users at openssl.org>
> Subject: Re: [openssl-users] What to do with deprecation errors
> Message-ID: <8260BB64-B12E-4779-B9DF-903D23E47FD3 at akamai.com>
> Content-Type: text/plain; charset="utf-8"
>
> >    DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP
> *group,
>
> That is "proof" that the pre-processor doesn?t have the right -I flags.
> Try running with the -v option or something.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 22 Oct 2018 08:55:28 +0100
> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] What to do with deprecation errors
> Message-ID: <7513a526-2840-6a4e-cf9a-99666ffc1330 at openssl.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 21/10/2018 20:01, Skip Carter wrote:
> > Thats what I originally thought.
> >
> > I experimented with manually invoking the pre-compiler (cpp) and this
> > is what I get:
> >
> >
> > DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,
> >                     ?
> > BIGNUM *p,
> > ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
> > ???????????????????????????????????????????????BN_CTX *ctx))
> > the macro is not firing, shouldn't I get:
> >
> > extern int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,
> >         ?                                              BIGNUM *p,
> > ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
> > ???
> > ????????????????????????????????????????????BN_CTX *ctx);
> >
> >
> > On Sun, 2018-10-21 at 18:28 +0000, Salz, Rich via openssl-users wrote:
> >>> ???And I still have the problem with those macros.
> >>
> >> ??
> >> The problem is almost definitely this:??the files that you are
> >> compiling (not openssl) are picking up the wrong header files from
> >> openssl.
> >>
>
> Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in it?
>
> Matt
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 22 Oct 2018 15:34:20 +0200
> From: Jakob Bohm <jb-openssl at wisemo.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] To disable CBC ciphers
> Message-ID: <d91267e8-4681-9a77-23fa-d790200e2259 at wisemo.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 20/10/2018 15:59, Kaushal Shriyan wrote:
> >
> >
> > On Wed, Oct 17, 2018 at 7:00 PM murugesh pitchaiah
> > <murugesh.pitchaiah at gmail.com <mailto:murugesh.pitchaiah at gmail.com>>
> > wrote:
> >
> >     Hi,
> >
> >     You may list down what ciphers configured : "openssl ciphers"
> >     Choose CBC ciphers and add them to the list of 'ssl_ciphers' with "!"
> >     prefix appended to current ssl_ciphers.
> >
> >     > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
> >
> >     Ref:
> >
> https://serverfault.com/questions/692119/meaning-of-ssl-ciphers-line-on-nginx-conf
> >
> >     Thanks,
> >     Murugesh P.
> >
> >
> >     On 10/17/18, Kaushal Shriyan <kaushalshriyan at gmail.com
> >     <mailto:kaushalshriyan at gmail.com>> wrote:
> >     > Hi,
> >     >
> >     > I have the below ssl settings in nginx.conf file and VAPT test
> >     has reported
> >     > us to disable CBC ciphers
> >     >
> >     > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;
> >     >> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> >     >
> >     >
> >     > openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
> >     CentOS
> >     > Linux release 7.3.1611 (Core)
> >     >
> >     > I will appreciate if someone can pitch in to help me understand
> >     to disable
> >     > CBC ciphers
> >     >
> >
> >
> > Thanks Murugesh. I did checked openssl ciphers
> > https://www.openssl.org/docs/man1.0.2/apps/ciphers.html and could not
> see
> > !AAA_CBC_BBB as mentioned in your email.
> >
> >     ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
> >
> >
> > Correct me if i am understanding it wrong. Basically i want to disable
> > Cipher Block Chaining (CBC) mode cipher encryption. Openssl and OS
> > version are as below :-
> >
> >     openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
> >     CentOS
> >     Linux release 7.3.1611 (Core)
> >
> >
> > Any tools which i can run to find out vulnerabilities in the above
> > openssl and OS version? Please guide and i look forward to hearing
> > from you. Thanks in Advance.
> You need to replace AAA and BBB with actual strings corresponding to
> each of the unwanted cipher suites.
>
> The advisor that tells you to disable "CBC ciphers" is mostly wrong.
> There is nothing inherently bad about correctly using ciphers in CBC
> mode, however some TLS protocol versions happen to use CBC cipher
> suites in a problematic way, while having no secure non-CBC cipher
> suites.? More recent TLS versions (such as TLS 1.2) have less
> problematic (but not perfect) CBC usage and also offers some
> overhyped US government ciphers such as the AES_GCM family.
>
> 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
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 22 Oct 2018 19:26:55 +0530
> From: ramakrushna mishra <rama.krushna7 at gmail.com>
> To: openssl-users at openssl.org
> Subject: [openssl-users] Reg issue in alert message
> Message-ID:
>         <CAHgr=kJyCXVY9QssB2CO3hY=
> GsEwiEcvzwQ-Pyd3VKqSm51XLA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I am facing an issue after openssl upgrade to 1.1.1.
> I have a odbc client with maximum version support up to TLSv1.2 and  my
> database is running with TLSv1.2,TLsv1.3.
>
> The handhake is failing and I am getting following contents on my BIO dump.
> "15 03 03 00 02 02 56" .
> If i have understood correctly this is for alert message and But I could
> not find any reference to alert description at (
> https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )
> corresponding to 56.
>
> So, Could you please help me figure out what does this correspond to ?
>
> Moreover I have following doubt.
>
> -- If my TLSv1.2 client does not handle the  "downgrade sentinel " present
> in server hello ( TLSv1.3 , will it create any problem ?
> -- In the above example client is receving error such as "SSL Handshake
> Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> alert inappropriate fallback]." ? Could you please help me to hint me about
> how to debug this ?
>
> Thanks and Regards,
> Ram Krushna
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20181022/cb04af81/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Mon, 22 Oct 2018 15:10:55 +0100
> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Reg issue in alert message
> Message-ID: <3c26e4ec-32e4-f3df-c1ae-0ed1cdeb5848 at openssl.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 22/10/2018 14:56, ramakrushna mishra wrote:
> > Hi,
> >
> > I am facing an issue after openssl upgrade to 1.1.1.?
> > I have a odbc client with maximum version support up to TLSv1.2 and? my
> > database is running with TLSv1.2,TLsv1.3.?
> >
> > The handhake is failing and I am getting following contents on my BIO
> dump.?
> > "15 03 03 00 02 02 56" .?
> > If i have understood correctly this is for alert message and But I could
> > not find any reference to alert description at (
> > https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )?
> > corresponding to 56.
>
> 56 hex == 86 decimal == inappropriate_fallback
>
> i.e. this doesn't tell you any further information than you have below.
>
> >
> > So, Could you please help me figure out what does this correspond to ??
> >
> > Moreover I have following doubt.?
> >
> > -- If my TLSv1.2 client does not handle the? "downgrade sentinel "
> > present in server hello ( TLSv1.3 , will it create any problem ?
>
> No, this should not be a problem.
>
> > -- In the above example client is receving error such as "SSL Handshake
> > Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> > alert inappropriate fallback]." ? Could you please help me to hint me
> > about how to debug this ?
>
> What version of OpenSSL are you using for the client?
>
> Is it possible for you to send me a wireshark trace of the failing
> handshake?
>
> In particular I am interested to see if the TLS_FALLBACK_SCSV
> ciphersuite is present in the ClientHello (RFC 7507). The
> TLS_FALLBACK_SCSV is only supposed to be sent if the client has already
> attempted an earlier handshake that failed, and it is now trying a
> downgraded protocol version. So, does the wireshark trace reveal the
> client attempting an initial handshake that is failing for some other
> reason, followed by a second attempt that fails with the inappropriate
> fallback error?
>
>
> Matt
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 22 Oct 2018 10:50:31 -0700
> From: Skip Carter <skip at taygeta.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] What to do with deprecation errors
> Message-ID: <1540230631.4886.20.camel at taygeta.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Yes the macro is there, its just not being expanded by the pre-
> compiler.
>
>
> On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote:
> >
> > On 21/10/2018 20:01, Skip Carter wrote:
> >
> > Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in
> > it?
> >
> > Matt
> --
> Skip Carter
> Taygeta Scientific Inc.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 47, Issue 35
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181023/07d3d698/attachment-0001.html>


More information about the openssl-users mailing list