Reg issue in alert message

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Reg issue in alert message

ramakrushna mishra
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 <[hidden email]> wrote:
Send openssl-users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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" <[hidden email]>
To: Skip Carter <[hidden email]>, "[hidden email]"
        <[hidden email]>
Subject: Re: [openssl-users] What to do with deprecation errors
Message-ID: <[hidden email]>
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 <[hidden email]>
To: [hidden email]
Subject: Re: [openssl-users] What to do with deprecation errors
Message-ID: <[hidden email]>
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 <[hidden email]>
To: [hidden email]
Subject: Re: [openssl-users] To disable CBC ciphers
Message-ID: <[hidden email]>
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
> <[hidden email] <mailto:[hidden email]>>
> 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 <[hidden email]
>     <mailto:[hidden email]>> 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 <[hidden email]>
To: [hidden email]
Subject: [openssl-users] Reg issue in alert message
Message-ID:
        <CAHgr=kJyCXVY9QssB2CO3hY=[hidden email]>
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 <[hidden email]>
To: [hidden email]
Subject: Re: [openssl-users] Reg issue in alert message
Message-ID: <[hidden email]>
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 <[hidden email]>
To: [hidden email]
Subject: Re: [openssl-users] What to do with deprecation errors
Message-ID: <[hidden email]>
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
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Reg issue in alert message

Matt Caswell-2


On 23/10/2018 12:32, ramakrushna mishra wrote:
> Hi Matt,
>
> Thanks for your response.
>  My client is built with openssl 1.0.0e

1.0.0e is very old and out of support. It should be considered insecure.
You should upgrade this to a more recent version.

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

Ok, the internal tracing is enough to see what is happening.


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

This suggests there is a bug in the client application. This can only
happen if the client application calls SSL_CTX_set_mode() or
SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.

This is incorrect if there has been no previously failed handshake at a
higher protocol version. From the documentation:

    SSL_MODE_SEND_FALLBACK_SCSV

    Send TLS_FALLBACK_SCSV in the ClientHello.
    To be set only by applications that reconnect with a downgraded
    protocol version; see draft-ietf-tls-downgrade-scsv-00 for details.

    DO NOT ENABLE THIS if your application attempts a normal handshake.
    Only use this in explicit fallback retries, following the guidance
    in draft-ietf-tls-downgrade-scsv-00.

(Note the reference to draft-ietf-tls-downgrade-scsv-00 in the docs
really should be updated to RFC7507 as that document is now known).

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

The purpose of sending TLS_FALLBACK_SCSV is to signal to the server "I
have attempted to connect to this server with a higher protocol version
than this one, but it failed". If this is unexpected to the server
because the server supports a higher protocol version then the server
assumes that a downgrade attack is taking place and aborts the connection.

Your client is declaring that it is prepared to speak TLSv1.2 ("03 03"
in the dump above) and is also declaring by sending TLS_FALLBACK_SCSV
that it first tried TLSv1.3 but it failed. This is clearly false since
OpenSSL 1.0.0e does not support TLSv1.3. A 1.1.1 server with TLSv1.3
enabled will then correctly abort the connection because it knows this
scenario should not have happened. A 1.1.1 server with TLSv1.3 disabled
should correctly complete the connection. This will not have happened
with any previous versions of OpenSSL because 1.1.1 is the first one to
support TLSv1.3.

Hope that helps,

Matt



>
>
> Thanks and Regards,
> Ram Krushna
>
>
> On Mon, Oct 22, 2018 at 11:21 PM <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Send openssl-users mailing list submissions to
>             [hidden email] <mailto:[hidden email]>
>
>     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
>             [hidden email]
>     <mailto:[hidden email]>
>
>     You can reach the person managing the list at
>             [hidden email]
>     <mailto:[hidden email]>
>
>     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" <[hidden email] <mailto:[hidden email]>>
>     To: Skip Carter <[hidden email] <mailto:[hidden email]>>,
>     "[hidden email] <mailto:[hidden email]>"
>             <[hidden email] <mailto:[hidden email]>>
>     Subject: Re: [openssl-users] What to do with deprecation errors
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     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 <[hidden email] <mailto:[hidden email]>>
>     To: [hidden email] <mailto:[hidden email]>
>     Subject: Re: [openssl-users] What to do with deprecation errors
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     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 <[hidden email] <mailto:[hidden email]>>
>     To: [hidden email] <mailto:[hidden email]>
>     Subject: Re: [openssl-users] To disable CBC ciphers
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     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
>     > <[hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     > 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 <[hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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 <[hidden email]
>     <mailto:[hidden email]>>
>     To: [hidden email] <mailto:[hidden email]>
>     Subject: [openssl-users] Reg issue in alert message
>     Message-ID:
>            
>     <CAHgr=kJyCXVY9QssB2CO3hY=[hidden email]
>     <mailto:[hidden email]>>
>     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 <[hidden email] <mailto:[hidden email]>>
>     To: [hidden email] <mailto:[hidden email]>
>     Subject: Re: [openssl-users] Reg issue in alert message
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     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 <[hidden email] <mailto:[hidden email]>>
>     To: [hidden email] <mailto:[hidden email]>
>     Subject: Re: [openssl-users] What to do with deprecation errors
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     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
>     [hidden email] <mailto:[hidden email]>
>     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
Reply | Threaded
Open this post in threaded view
|

Re: Reg issue in alert message

Viktor Dukhovni
On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:

> > So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
> > client hello.
>
> This suggests there is a bug in the client application. This can only
> happen if the client application calls SSL_CTX_set_mode() or
> SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.

I have a somewhat plausible, if dicey hunch:

    Perhaps some application developers got confused between
    the similar functions SSL_CTX_set_session_cache_mode(3)
    and SSL_CTX_set_mode(3) and called the wrong one?

It just so happens that we have:

    include/openssl/ssl.h:# define SSL_MODE_SEND_FALLBACK_SCSV 0x00000080U
    include/openssl/ssl.h:# define SSL_SESS_CACHE_NO_AUTO_CLEAR            0x0080

which means that someone calling:

    SSL_CTX_set_mode(ctx, SSL_SESS_CACHE_NO_AUTO_CLEAR);

instead of:

    SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_NO_AUTO_CLEAR);

ends up doing exactly the wrong thing.  Of course just as likely
or more, the documentation of SSL_MODE_SEND_FALLBACK_SCSV may have
been misunderstood, despite all the warnings.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Reg issue in alert message

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Viktor Dukhovni
> Sent: Tuesday, October 23, 2018 10:02
>
> On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:
>
> > > So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
> > > client hello.
> >
> > This suggests there is a bug in the client application. This can only
> > happen if the client application calls SSL_CTX_set_mode() or
> > SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.
>
> I have a somewhat plausible, if dicey hunch:
>
>     Perhaps some application developers got confused between
>     the similar functions SSL_CTX_set_session_cache_mode(3)
>     and SSL_CTX_set_mode(3) and called the wrong one?

Certainly possible, but I wouldn't discount the possibility that someone simply thought setting SSL_MODE_SEND_FALLBACK_SCSV was the Right Thing. There was a fair bit of confusion around the Fallback SCSV when it first appeared (we had questions from customers that indicated they didn't understand it, and I had to read the ID to make sure I did). And, of course, TLS is mightly confusing in general.

It is interesting to note that those two options happen to have the same value, though, particularly given the similarity of the two function names.

This is one of those cases where C's weak type system is a problem. Though it would be nice if OpenSSL used enums rather than macros for these things.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



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