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.@.?.>.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@xxxxxxxxxxx> wrote:
Send openssl-users mailing list submissions to
openssl-users@xxxxxxxxxxx
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@xxxxxxxxxxx
You can reach the person managing the list at
openssl-users-owner@xxxxxxxxxxx
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@xxxxxxxxxx>
To: Skip Carter <skip@xxxxxxxxxxx>, "openssl-users@xxxxxxxxxxx"
<openssl-users@xxxxxxxxxxx>
Subject: Re: What to do with deprecation errors
Message-ID: <8260BB64-B12E-4779-B9DF-903D23E47FD3@xxxxxxxxxx>
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@xxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: What to do with deprecation errors
Message-ID: <7513a526-2840-6a4e-cf9a-99666ffc1330@xxxxxxxxxxx>
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@xxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: To disable CBC ciphers
Message-ID: <d91267e8-4681-9a77-23fa-d790200e2259@xxxxxxxxxx>
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@xxxxxxxxx <mailto:murugesh.pitchaiah@xxxxxxxxx>>
> 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@xxxxxxxxx
> <mailto:kaushalshriyan@xxxxxxxxx>> 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@xxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Reg issue in alert message
Message-ID:
<CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@xxxxxxxxxxxxxx>
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@xxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: Reg issue in alert message
Message-ID: <3c26e4ec-32e4-f3df-c1ae-0ed1cdeb5848@xxxxxxxxxxx>
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@xxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: What to do with deprecation errors
Message-ID: <1540230631.4886.20.camel@xxxxxxxxxxx>
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@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users
------------------------------
End of openssl-users Digest, Vol 47, Issue 35
*********************************************
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
