[ech] TLSProxy and ECH

[Matt Caswell]

On 21/03/2023 21:45, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 21/03/2023 20:51, Dmitry Belyavsky wrote:
>> I have added some basic test scenarios using TLSfuzzer in openssl 
>> project,
>> but I don't have capacity to improve this work yet.
> 
> Ah right, I see that now. Must give it a try. (I guess I
> just need to clone tlsfuzzer in the right place and it'll
> try run as part of ``make test``?)
> 
>>
>> I don't think it would be sufficient for including ECH upstream 
>> because it
>> is an external test, and usually the internal one is requred, but it 
>> could
>> be used as a starting point.
> 
> Fair point.

Right - I wouldn't recommend tlsfuzzer for this since we really need 
internal tests for this.

All our current TLS tests for this stuff are built using TLSProxy.

There *is* a potential alternative in the form of the QUIC fault 
injector which does much the same thing but for QUIC. It includes the 
ability to inject TLS faults into a QUIC TLS handshake. It does this 
from pure C code. I believe it would be possible to extend the concept 
to be able to do the same thing for standalone TLS. The hook to enable 
this is already present:

https://github.com/openssl/openssl/blob/83ff6cbd9a02ed713bf66f960ab9aea5fced49a3/ssl/statem/statem_lib.c#L39-L54

and

https://github.com/openssl/openssl/blob/83ff6cbd9a02ed713bf66f960ab9aea5fced49a3/ssl/statem/statem_lib.c#L66-L90

The framework around that hook would need to be implemented and that 
would be a significant investment of effort.

Some of the test framework for QUIC that uses the above hook is here:

https://github.com/openssl/openssl/blob/83ff6cbd9a02ed713bf66f960ab9aea5fced49a3/test/helpers/quictestlib.c#L489-L688


An example test using this approach for QUIC can be seen here. This test 
modifies the TLS EncryptedExtensions message to drop the transport 
parameters extension from the message:

https://github.com/openssl/openssl/blob/83ff6cbd9a02ed713bf66f960ab9aea5fced49a3/test/quicfaultstest.c#L165-L218

>>>>> My possibly incorrect understanding is that the TLSProxy
>>>>> is a bunch of perl code used for tests, that re-implements
>>>>> variants of the TLS handshake so they can contain e.g. badly
>>>>> encoded messages.

Not quite. TLSProxy (and the QUIC fault injector described above) sit in 
the middle between a normal server and a normal client. They modify the 
messages created by each in order to create bad encodings. It doesn't 
reimplement its own implementation of the handshake. Effectively it is 
performing a man-in-the-middle attack!

Obviously TLS is designed to prevent a man-in-the-middle attack from 
working. The TLSProxy framework works by replacing the normal MAC 
calculations with dummy ones so that TLSProxy can make arbitrary changes 
without the Finished message checks failing. It also uses NULL 
encryption. The QUIC fault injector works by using a callback to modify 
messages *before* they are encrypted/passed through the finished mac and 
sent to the peer (so the standard MAC and encryption algorithms can 
still be used).

 > I wanted to
check if that perl TLSProxy code is the long term plan or
if it's something felt to be approaching end of life?

For now TLSProxy is it. I would like to perhaps replace it with 
something more like the QUIC fault injector - but I don't expect that to 
happen in the short to medium term.

Matt