s_server/s_client on checking middlebox compatibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

s_server/s_client on checking middlebox compatibility

John Jiang
Is it possible to check if peer implements middlebox compatibility by s_server/s_client?
It looks the test tools don't care this point.
For example, if a server doesn't send change_cipher_spec after HelloRetryRequest, s_client still feels fine.That's not bad. But can I setup these tools to check middlebox compatibility?
Reply | Threaded
Open this post in threaded view
|

Re: s_server/s_client on checking middlebox compatibility

Matt Caswell-2


On 26/02/2019 06:22, John Jiang wrote:
> Is it possible to check if peer implements middlebox compatibility by
> s_server/s_client?
> It looks the test tools don't care this point.
> For example, if a server doesn't send change_cipher_spec after
> HelloRetryRequest, s_client still feels fine.That's not bad. But can I setup
> these tools to check middlebox compatibility?

By default s_server/s_client will have middlebox compatibility on. You can turn
it off using the option "-no_middlebox". There is no option to directly tell you
if an endpoint is using middlebox compatibility mode or not. You could figure it
out indirectly by using the "-debug" option. This shows you the raw data that is
being sent/received by the endpoints. Assuming TLSv1.3 has been negotiated then
a remote peer is using middlebox compatibility if you see a sequence like this
during the handshake:

read from 0x557afedffb60 [0x557afee057d3] (5 bytes => 5 (0x5))
0000 - 14 03 03 00 01                                    .....
read from 0x557afedffb60 [0x557afee057d8] (1 bytes => 1 (0x1))
0000 - 01


Matt
Reply | Threaded
Open this post in threaded view
|

Re: s_server/s_client on checking middlebox compatibility

Hubert Kario
In reply to this post by John Jiang
On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> Is it possible to check if peer implements middlebox compatibility by
> s_server/s_client?
> It looks the test tools don't care this point.
> For example, if a server doesn't send change_cipher_spec after
> HelloRetryRequest, s_client still feels fine.That's not bad. But can I
> setup these tools to check middlebox compatibility?

As Matt said, there's no human-readable output that shows that.

tlsfuzzer does verify if the server sends ChangeCipherSpec and at what
point in the connection (all scripts expect it right after ServerHello or
right after HelloRetryRequest depending on connection).

You can use
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-conversation.py
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-hrr.py
and
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-session-resumption.py
respectively to test regular handshake, one with HelloRetryRequest
and one that performs session resumption.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: s_server/s_client on checking middlebox compatibility

John Jiang
I had tried TLS Fuzzer, and it worked for me.
I just wished that OpenSSL can do the similar things.

Thanks!

On Tue, Feb 26, 2019 at 9:56 PM Hubert Kario <[hidden email]> wrote:
On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> Is it possible to check if peer implements middlebox compatibility by
> s_server/s_client?
> It looks the test tools don't care this point.
> For example, if a server doesn't send change_cipher_spec after
> HelloRetryRequest, s_client still feels fine.That's not bad. But can I
> setup these tools to check middlebox compatibility?

As Matt said, there's no human-readable output that shows that.

tlsfuzzer does verify if the server sends ChangeCipherSpec and at what
point in the connection (all scripts expect it right after ServerHello or
right after HelloRetryRequest depending on connection).

You can use
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-conversation.py
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-hrr.py
and
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-session-resumption.py
respectively to test regular handshake, one with HelloRetryRequest
and one that performs session resumption.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
Reply | Threaded
Open this post in threaded view
|

Re: s_server/s_client on checking middlebox compatibility

Hubert Kario
On Wednesday, 27 February 2019 03:24:38 CET John Jiang wrote:
> I had tried TLS Fuzzer, and it worked for me.
> I just wished that OpenSSL can do the similar things.

The problem is that the middlebox compatibility mode is not defined strictly
by the standard, and while all the popular TLS libraries (OpenSSL, Mozilla
NSS, GnuTLS) agree on where the CCS should be inserted in the handshake,
placing it in other locations may be necessary for some specific middleboxes.

IOW, there is no one correct location for CCS, so if openssl just reported
that the CCS was received (or if it was received at one specific place in
handshake), it could be misleading.

Also, let's be clear, middlebox compatibility mode is a thing because of bugs
in other implementations, so it's better to spend time on basically anything
else than polishing stuff around it

> On Tue, Feb 26, 2019 at 9:56 PM Hubert Kario <[hidden email]> wrote:
> > On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> > > Is it possible to check if peer implements middlebox compatibility by
> > > s_server/s_client?
> > > It looks the test tools don't care this point.
> > > For example, if a server doesn't send change_cipher_spec after
> > > HelloRetryRequest, s_client still feels fine.That's not bad. But can I
> > > setup these tools to check middlebox compatibility?
> >
> > As Matt said, there's no human-readable output that shows that.
> >
> > tlsfuzzer does verify if the server sends ChangeCipherSpec and at what
> > point in the connection (all scripts expect it right after ServerHello or
> > right after HelloRetryRequest depending on connection).
> >
> > You can use
> >
> > https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-conve
> > rsation.py
> > https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-hrr.
> > py and
> >
> > https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-tls13-sessi
> > on-resumption.py respectively to test regular handshake, one with
> > HelloRetryRequest and one that performs session resumption.
> >
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc (849 bytes) Download Attachment