Decoding SSL packets from netlog

144 views
Skip to first unread message

Adam Rice

unread,
Nov 21, 2016, 7:19:37 AM11/21/16
to net-dev
I have a netlog containing an SSL handshake with full byte information. I would like to decode the SSL packets in a similar way to what I can get with a packet capture in Wireshark.

Does anyone have a good way to do this?

I need to do this to track down the cause of http://crbug.com/657791 ("MacOS Sierra WebSocket: ERR_INSECURE_RESPONSE rate very high").

Ryan Sleevi

unread,
Nov 21, 2016, 7:51:43 AM11/21/16
to Adam Rice, net-dev

If you have full bytes, you have the decoded plaintext.

It sounds like you're wanting to feed a NetLog to Wireshark though, and NetLot doesn't support that. Use Wireshark with SSLKEYLOGFILE for that.


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAHixhFodQNmwTw4hwYpdQO3Mi1GKgytA92VcfdEGyAix5pYnTQ%40mail.gmail.com.

Adam Rice

unread,
Nov 21, 2016, 8:01:31 AM11/21/16
to Ryan Sleevi, net-dev
The handshake fails, so no plaintext is ever decoded. I want to look at the handshake to see if I can work out why it's failing. Also, I don't have access to the server myself, so I cannot get a packet capture.

David Benjamin

unread,
Nov 21, 2016, 12:27:17 PM11/21/16
to Adam Rice, Ryan Sleevi, net-dev
Which message were you hoping to decrypt? The only encrypted handshake message (aside from Channel ID which would only be on Google servers) in current versions of TLS is the Finished message. You're not going to be able to learn anything from looking at that, and it's very unlikely that WebSockets are breaking on the Finished message.

Which log on that bug are you looking at? The most recent one? I just see a bunch of ERR_CERT_AUTHORITY_INVALID which is after the handshake and suggests the certificate is just invalid. (We check certificates between completing the handshake and sending data.) If you want to look at the certificate, we already dump those into NetLog without needing to decrypt.

On Mon, Nov 21, 2016 at 8:01 AM 'Adam Rice' via net-dev <net...@chromium.org> wrote:
The handshake fails, so no plaintext is ever decoded. I want to look at the handshake to see if I can work out why it's failing. Also, I don't have access to the server myself, so I cannot get a packet capture.
On 21 November 2016 at 21:51, Ryan Sleevi <rsl...@chromium.org> wrote:

If you have full bytes, you have the decoded plaintext.

It sounds like you're wanting to feed a NetLog to Wireshark though, and NetLot doesn't support that. Use Wireshark with SSLKEYLOGFILE for that.

On Nov 21, 2016 4:19 AM, "'Adam Rice' via net-dev" <net...@chromium.org> wrote:
I have a netlog containing an SSL handshake with full byte information. I would like to decode the SSL packets in a similar way to what I can get with a packet capture in Wireshark.

Does anyone have a good way to do this?

I need to do this to track down the cause of http://crbug.com/657791 ("MacOS Sierra WebSocket: ERR_INSECURE_RESPONSE rate very high").

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

Adam Rice

unread,
Nov 21, 2016, 11:36:41 PM11/21/16
to David Benjamin, Ryan Sleevi, net-dev
To clarify, I'm mostly only interested in the unencrypted part of the handshake. Sorry for the confusion. As David said, there's only one bit of encrypted data received on the socket before the connection is cut, and from the netlog is appears that Chrome doesn't even read that from the socket before making the decision to sever the connection.

Having said that, everything about this bug is unlikely. I am going to try compiling a version of Chrome that uses ALPN even for WebSockets. This should enable me to rule out that as the cause.

I always assumed that the blob of base64 only contained the public key and so was useless to me. Sorry for not realising sooner that it also contains the certificate metadata. I have now figured out how to use openssl to decode it into human-readable form. Would it be unreasonable to request that the human-readable form was also included in the netlog?

I'm currently looking at the last log posted, https://bugs.chromium.org/p/chromium/issues/detail?id=657791#c31

On 22 November 2016 at 02:27, David Benjamin <davi...@chromium.org> wrote:
Which message were you hoping to decrypt? The only encrypted handshake message (aside from Channel ID which would only be on Google servers) in current versions of TLS is the Finished message. You're not going to be able to learn anything from looking at that, and it's very unlikely that WebSockets are breaking on the Finished message.

Which log on that bug are you looking at? The most recent one? I just see a bunch of ERR_CERT_AUTHORITY_INVALID which is after the handshake and suggests the certificate is just invalid. (We check certificates between completing the handshake and sending data.) If you want to look at the certificate, we already dump those into NetLog without needing to decrypt.

On Mon, Nov 21, 2016 at 8:01 AM 'Adam Rice' via net-dev <net...@chromium.org> wrote:
The handshake fails, so no plaintext is ever decoded. I want to look at the handshake to see if I can work out why it's failing. Also, I don't have access to the server myself, so I cannot get a packet capture.
On 21 November 2016 at 21:51, Ryan Sleevi <rsl...@chromium.org> wrote:

If you have full bytes, you have the decoded plaintext.

It sounds like you're wanting to feed a NetLog to Wireshark though, and NetLot doesn't support that. Use Wireshark with SSLKEYLOGFILE for that.

On Nov 21, 2016 4:19 AM, "'Adam Rice' via net-dev" <net...@chromium.org> wrote:
I have a netlog containing an SSL handshake with full byte information. I would like to decode the SSL packets in a similar way to what I can get with a packet capture in Wireshark.

Does anyone have a good way to do this?

I need to do this to track down the cause of http://crbug.com/657791 ("MacOS Sierra WebSocket: ERR_INSECURE_RESPONSE rate very high").

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

Adam Rice

unread,
Nov 22, 2016, 2:17:54 AM11/22/16
to David Benjamin, Ryan Sleevi, net-dev
Thanks everyone,

I discovered that the issue was fixed in canary, did a bisect and found it was fixed by CL https://chromium.googlesource.com/chromium/src.git/+/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b.

If someone has an idea what the root cause might be that would be useful because we could write a regression test. But I'm going to focus on trying to get the fix merged to M54.

Ryan Sleevi

unread,
Nov 22, 2016, 2:20:26 AM11/22/16
to Adam Rice, David Benjamin, net-dev

On Nov 21, 2016 8:36 PM, "'Adam Rice' via net-dev" <net...@chromium.org> wrote:
>
> Would it be unreasonable to request that the human-readable form was also included in the netlog?

Yeah. We should use the right tool for the right job. Just like Wireshark exists for advanced debugging, we shouldn't add a bunch of stuff to NetLog just for convenience, especially with the complexity it adds.

Reply all
Reply to author
Forward
0 new messages