This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Help analyzing SSL

0

Hi,

I have an intermittent problem with SSL on our local network. We have a proxy on the network but all ssl traffic should be untouched.

The hand-off of http traffic is achieved through these iptable rules (where .23 is the proxy):

iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 3
ip rule add fwmark 3 table 2
ip route add default via 192.168.0.23 dev br0 table 2

When the problem happens, I can't for example open an SSL site from Chrome, but going to Firefox magically helps. Then the trouble disappears and I can use that site again. Sometimes refreshing the page helps. Other people in the office with the same wired connections may have no problem going to the site though. Weird stuff like that.

So, I took a capture of the traffic while the problem was happening, but I can't understand due to insufficient knowledge in the area what is abnormal in the sequence.

How could I post the capture?

EDIT: I've put the capture here: https://docs.google.com/file/d/0B8FF7jZJwuoUNExMdHB2eFZ1WU0/edit?usp=sharing

Thanks for any help!

asked 08 Oct '13, 09:12

surge's gravatar image

surge
1●1●1●2
accept rate: 0%

edited 08 Oct '13, 09:20

The capture file contains only traffic for the POP3S port (995). So, yes it is SSL, but unrelated to a proxy and/or a browser (chrome). Maybe a user downloaded his mail via POP3S. Are you sure you posted the right capture file?

(08 Oct '13, 09:40) Kurt Knochner ♦

Oops, yeah, not sure what I was thinking. Should have at least looked at the remote address and seen that it's one of mine :)

Anyway, I was able capture another set, this time (i hope) more to the point.

Here it is: https://docs.google.com/file/d/0B8FF7jZJwuoUVmFzNmFrQkQ3QWc/edit?usp=sharing

I already see that the proxy somehow wedges in on the ssl conversation ("Gremlins ate your request" is a message from our proxy), but i'm not sure why.

Thanks for any insight.

(08 Oct '13, 10:24) surge

One Answer:

0

If you look at the content, you will see this:

400 Bad Request
Server: squid
Mime-Version: 1.0
Date: Tue, 08 Oct 2013 17:01:29 GMT
Content-Type: text/html
Content-Length: 3677
X-Squid-Error: ERR_INVALID_REQ 0
X-Cache: MISS from ipcop
Connection: close

If I compare the two capture files, I can see that the HTTPS request is sent to MAC address of an Intel device (probably your proxy), while the POP3S request ist sent to a Netgear MAC address (probably your Internet router).

So, the HTTPS request is forwarded to the proxy. Looks like the iptables rules you posted are not complete.

Regards
Kurt

answered 08 Oct '13, 10:37

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 08 Oct '13, 13:18

The netgear is our router, you're right.

So, the HTTPS request is forwarded to the proxy. Looks like the posted iptables you posted is not complete. However, it could also be a wrong proxy config in the browser. Can you post a screen shot of that please?

I'm on Linux and when I go the proxy settings, it says

"Google Chrome is using your computer's system proxy settings to connect to the network."

In my /etc/network/interfaces I have

auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1

Now, the router runs ddwrt and here is the more complete set of rules from the router:

 echo "131072" > /sys/module/nf_conntrack/parameters/hashsize
 iptables -t mangle -A PREROUTING -p tcp -s 192.168.0.0/24 --dport 80 -d 64.18.218.22 -j ACCEPT
 iptables -t mangle -A PREROUTING -p tcp -s 192.168.0.0/24 --dport 80 -d 199.166.4.42 -j ACCEPT
 iptables -t mangle -A PREROUTING -p tcp -s 192.168.0.0/24 --dport 80 -d 192.168.0.0/24 -j ACCEPT
 iptables -t mangle -A PREROUTING -p tcp --dport 80 -s 192.168.0.118 -j ACCEPT
 iptables -t mangle -A PREROUTING -p tcp --dport 80 -s 192.168.0.24  -j ACCEPT
 iptables -t mangle -A PREROUTING -p tcp --dport 80 -s 192.168.0.23  -j ACCEPT
 iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 3
 ip rule add fwmark 3 table 2
 ip route add default via 192.168.0.23 dev br0 table 2
 prefix=/proc/sys/net/ipv4/netfilter/ip_conntrack
 echo 600 > ${prefix}_generic_timeout
 echo 1800 > ${prefix}_udp_timeout
 echo 1800 > ${prefix}_udp_timeout_stream
 echo 3600 > ${prefix}_tcp_timeout_established
 echo 120 > ${prefix}_tcp_timeout_syn_sent
 echo 60 > ${prefix}_tcp_timeout_syn_recv
 echo 120 > ${prefix}_tcp_timeout_fin_wait
 echo 120 > ${prefix}_tcp_timeout_time_wait
 echo 10 > ${prefix}_tcp_timeout_close
 echo 60 > ${prefix}_tcp_timeout_close_wait
 echo 30 > ${prefix}_tcp_timeout_last_ackG
(08 Oct '13, 11:02) surge

sorry bout the formatting. the forum interface is fighting me.

(08 Oct '13, 11:03) surge

well, those rules do not explain why the HTTPS traffic (TCP/443) is forwarded to the proxy. There must be more than just that. Can you please post the output of

iptables-save
ip route show table all
ip rule show

Some more questions:

  • Your client is Linux. Are there iptables rules and routing rules as well?
  • Where did you capture the traffic?

I guess you captured on the client. If so, there must be something on the client as well, because the client already sent the traffic to the proxy MAC (Intel MAC), so the iptables and routing rules on the router were not involved at all.

(08 Oct '13, 13:16) Kurt Knochner ♦

but going to Firefox magically helps. Then the trouble disappears and I can use that site again

hm... that sounds like a temporary network problem, like if there was the wrong ARP entry for your default gateway. While the problem occurs, please check on your client if the ARP entry for 192.168.0.1 shows the Netgear MAC address.

arp -an | grep 192.168.0.1

If it's not the ARP entry, please add the information I was asking for in my last comment.

(08 Oct '13, 14:00) Kurt Knochner ♦