0

I'm testing a new proxy and monitoring the connection using Wireshark, but I'm not seeing any certificate at all. my goal is to find out exactly what sensitive and identifiable data is leaving my router after using this proxy, emphasizing on the certificate used in securing the connection.

in Wireshark, I've tried these filters but no result is shown, after using each filter, I tried reconnecting to the proxies and opened a bunch of websites but still no result came up.

tls.handshake.certificate

tls.handshake.type == 11

so how is this possible? am I missing something obvious?

this is how the data stream looks like

enter image description here

there are only TLS 1.1 (rarely), TLS 1.2, TLS 1.3 and TCP packets.

this is what I see when I manually open up a TLS 1.3 packet.

enter image description here

p.s when I check for the SNI, only 1 SNI will be ever shown and it's the proxy server's address.

ssl.handshake.extension.type == "server_name"

Cipher Suits, from another TLS 1.3 packet

enter image description here

According to this answer Does an HTTPS proxy encrypt traffic between proxy client and server for HTTP requests?

and with the info provided above, does it mean that the proxy server I'm using is also a SSL server?

As user Steffen Ullrich mentioned, TLS v1.3 encrypts the handshake and thus the certificate isn't visible in Wireshark, but here is a TLS v1.2 and I can't see its certificate either, why?

I don't know for sure but I'm assuming every TLS encrypted packet carries handshake data like certificate it was encrypted with, along with it?

7
  • 1
    Handshake messages containing the certificates (both from server and client) are encrypted in TLS 1.3, which means that you cannot see these without breaking the encryption. "1 SNI will be ever shown and it's the proxy server's address" - looks like not only the connection to the server is TLS but in addition also the connection to the proxy. So there would be 2 layers of encryption to break before you get to the certificates of server or client :( Nov 7, 2022 at 6:20
  • @SteffenUllrich thank you very much, super helpful for understanding that, btw I added a small part to the end of my question, would you please take a look and if possible, post your reply along with this helpful comment as answer so i can accept it? thanks again!
    – user285140
    Nov 7, 2022 at 6:36
  • The output you show is not from the TLS handshake (Content-Type: Application Data), but the certificate is part of the TLS handshake, which is done before any application data are transferred. Nov 7, 2022 at 6:41
  • Okay, so with that, I think I can safely conclude that since I can't see any result in Wireshark after applying tls.handshake.type == 11 filter, that means the proxy I'm using uses only TLS v1.3. it initiates the first connection to its server using TLS v1.3 too, then encapsulates any subsequent packets inside TLS v1.3, including TLS V1.2, TLS v1.1, TCP, DNS etc. that's why no certificate is ever seen in Wireshark even after running it for like 10 hours. please correct me if I'm wrong.
    – user285140
    Nov 7, 2022 at 6:47
  • Based on your documentation on what you did and your interpretation on what you see, your conclusion looks correct. But note that this all relies on you doing and interpreting things correctly, there is no way to check myself. Apart from that the proxy to use is likely configured in the application which should use it and clues on how the proxy is configured might help too. Nov 7, 2022 at 7:18

1 Answer 1

0

I don't know what you've done to your Wireshark configuration, but here's what the default display settings (except ISTR I tweaked the time column long ago) show for a TLS1.2 handshake on my test system, with the record containing the cert selected and the cert within that record selected and partially expanded:

enter image description here

1
  • Well I'm using a TLS proxy (software) that intercepts all system and application connections using a TUN adapter and reroutes them over the proxy. when I monitor my WiFi network adapter (the one that sends the final packets out to the Internet), and apply this filter tls.handshake.type == 11, I see no result.
    – user285140
    Nov 7, 2022 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy