TLS key export broken w/vneg about quant HOT 19 CLOSED

It may be a bug on Wireshark, @Lekensteyn can you look ?

from quant.

Ignoring the Initial packet makes the problem go away. The bug is in Wireshark, it should ignore the first packet when processing subsequent initial packets, but it does not. According to https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-6.2.1, the new inital packet has a new DCID (which is then used for decryption), but Wireshark still uses the first one. I'll work on a fix.

Edit: patch https://code.wireshark.org/review/33525

from quant.

The Wireshark patch has been merged in git master. Consider removing the QUIC_ prefix from the key log labels (effectively turning those into TLS 1.3 labels), these are the same. The (EARLY_)EXPORTER_SECRET are also no longer needed for QUIC decryption.

from quant.

@Lekensteyn thanks, will change the labels. You might also want to announce this change on the QUIC slack? At least picotls and quicly use the same exporter code (from quicly).

@adikabintang please check if a new wireshark works for you; I'll keep this open until then.

from quant.

added

from quant.

Hi, thank you for adding this feature. I tried to use this TLS key (specified by -l option in bin/client) to decrypt the message in wireshark but it failed and I cannot decrypt the message. In wireshark, it said like this:

Expert Info (Warning/Decryption): Failed to create decryption context: Decryption (checktag) failed: Checksum error

The TLS key log file contains something like this:

EXPORTER_SECRET 4dea5293ae84a606b14ac7109ae4b1fc48cffa2b9f1e17748e05949d8155ad43 437a8457b235d2be467ae212cf3775fe8de08ab41bf25c844f672c56f2efd9979ffb44bd071ab3e4990421e88506818f

I didn't change the code in bin/server.c and bin/client.c.

According to this, the labels example include CLIENT_EARLY_TRAFFIC_SECRET, CLIENT_HANDSHAKE_TRAFFIC_SECRET, etc. And according to this, EXPORTER_SECRET is also a label for TLS1.3.

Am I missing something?

from quant.

I never use the exporter functionality, so there was still a bug. I think I just fixed this is 5627399; would you try again?

from quant.

I have tried and I cannot decrypt the first connection (no TLS 0-RTT state cache yet):

On Initial packet:

Expert Info (Warning/Decryption): Failed to create decryption context: Decryption (checktag) failed: Checksum error

On Handshake, server to client:

Expert Info (Warning/Decryption): Failed to create decryption context: Decryption (checktag) failed: Checksum error

Expert Info (Warning/Decryption): Failed to create decryption context: Unable to retrieve cipher information

Expert Info (Warning/Decryption): Failed to decrypt packet number

However, on the second connection (when the TLS 0-RTT state cache is already available), wireshark can successfully decrypt the communication.

The log from the first connection (no TLS 0-RTT state cache) looks like this:

QUIC_SERVER_HANDSHAKE_TRAFFIC_SECRET <Client random> <secret>
QUIC_CLIENT_HANDSHAKE_TRAFFIC_SECRET <Client random> <secret>
QUIC_SERVER_TRAFFIC_SECRET_0 <Client random> <secret>
EXPORTER_SECRET <Client random> <secret>
QUIC_CLIENT_TRAFFIC_SECRET_0 <Client random> <secret>

and the log from the second connection looks like this:

QUIC_CLIENT_EARLY_TRAFFIC_SECRET <Client random> <secret>
EARLY_EXPORTER_SECRET <Client random> <secret>
QUIC_SERVER_HANDSHAKE_TRAFFIC_SECRET <Client random> <secret>
QUIC_CLIENT_HANDSHAKE_TRAFFIC_SECRET <Client random> <secret>
QUIC_SERVER_TRAFFIC_SECRET_0 <Client random> <secret>
EXPORTER_SECRET <Client random> <secret>
QUIC_CLIENT_TRAFFIC_SECRET_0 <Client random> <secret>

The wireshark version used is 3.1.0rc0-946-g55eeec7e6a62, run on Ubuntu 18.04.

from quant.

Have you tried with other QUIC clients? Because quicly, for example, generates the exact same TLS log lines for initial and 0-RTT connection attempts.

from quant.

I tried aioquic and quicly, and the secret log format looks similar. aioquic and quicly works for the first connection.

I am not sure if the current problem is caused by the secret log format since it looks the same as the log from aioquic and quicly. Moreover, quant works for the second connection.

If I look at traffic, on the first connection, it starts to unable to decrypt after the second initial packet which is right after the version negotiation.

Wireshark can decrypt the first initial packet. Then, after the version negotiation, the client chooses version 0x45474714 (in wireshark it's unknown, but it seems that it's quant version). After that, the client send the initial packet again with the protocol version it chooses from the version negotiation. Since this second initial packet, wireshark cannot decrypt.

Here is another screenshot on handshake packet:

from quant.

Thanks for digging into this! I think I know what it might be.

from quant.

I have confirmed that this issue only occurs when a version negotiation exchange happens at the beginning of a connection. That is why the second 0-RTT connection works, but a first connection also works if you disable version negotiation in the client.

I'm talking to other devs that use picotls about whether this is a bug in picotls.

from quant.

Let me know if you need a trace and TLS log file!

from quant.

Let me know if you need a trace and TLS log file!

Yes, you can share on #wireshark channel (on quic slack)

from quant.

quicly with vneg seems to have similar issues

from quant.

Thank you! I have tried the master several minutes ago (5e79558a8243c046ce3f279c635f9670be7f8f05) and it works now.

from quant.

FYI, I shortened the labels in ccf9ecd

from quant.

@Lekensteyn are you sure the shortened labels work? See #46

from quant.

@larseggert It should work, this was the change that dropped support for QUIC_ labels: wireshark/wireshark@cc50ec3

I'll have a look at the other issue. Thanks for the feedback!

from quant.