[ech] TLSProxy and ECH
matt at openssl.org
Wed Mar 22 11:31:52 UTC 2023
On 21/03/2023 21:45, Stephen Farrell wrote:
> On 21/03/2023 20:51, Dmitry Belyavsky wrote:
>> I have added some basic test scenarios using TLSfuzzer in openssl
>> 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
>> 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:
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:
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:
>>>>> 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.
More information about the ech