I think it was problem with my virtual machine that I saw same packets.Now I listened again and now I got duplicate ACK error and packets coming in and out are not the same. Wireshark output for first 4 packets which continue same way after 4th.
No. Time Source Destination Protocol Info 1 0.000000 192.168.0.166 62.75.148.60 TCP 60646 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=3365830876 TSER=0 WS=6 Frame 1 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: Vmware_c4:ae:b5 (00:0c:29:c4:ae:b5), Dst: AsustekC_10:2f:f7 (00:0e:a6:10:2f:f7) Internet Protocol, Src: 192.168.0.166 (192.168.0.166), Dst: 62.75.148.60 (62.75.148.60) Transmission Control Protocol, Src Port: 60646 (60646), Dst Port: https (443), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 2 0.000100 192.168.0.166 62.75.148.60 TCP 60646 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=3365830876 TSER=0 WS=6 Frame 2 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: AsustekC_10:2f:f7 (00:0e:a6:10:2f:f7), Dst: AewinTec_36:80:cc (00:0d:48:36:80:cc) Internet Protocol, Src: 192.168.0.166 (192.168.0.166), Dst: 62.75.148.60 (62.75.148.60) Transmission Control Protocol, Src Port: 60646 (60646), Dst Port: https (443), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 3 0.003513 192.168.0.166 62.75.148.60 TCP 60646 > https [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=3365830880 TSER=431756894 Frame 3 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: Vmware_c4:ae:b5 (00:0c:29:c4:ae:b5), Dst: AsustekC_10:2f:f7 (00:0e:a6:10:2f:f7) Internet Protocol, Src: 192.168.0.166 (192.168.0.166), Dst: 62.75.148.60 (62.75.148.60) Transmission Control Protocol, Src Port: 60646 (60646), Dst Port: https (443), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 4 0.003534 192.168.0.166 62.75.148.60 TCP [TCP Dup ACK 3#1] 60646 > https [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=3365830880 TSER=431756894 Frame 4 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: AsustekC_10:2f:f7 (00:0e:a6:10:2f:f7), Dst: AewinTec_36:80:cc (00:0d:48:36:80:cc) Internet Protocol, Src: 192.168.0.166 (192.168.0.166), Dst: 62.75.148.60 (62.75.148.60) Transmission Control Protocol, Src Port: 60646 (60646), Dst Port: https (443), Seq: 1, Ack: 1, Len: 0 >>Any idea what those two packets contain? >> >>Amos On Mon, Aug 8, 2011 at 5:27 PM, Deniz Eren <de...@denizeren.net> wrote: > Amos, I did as you said. It seems that the https packets entering > squid are going out without any change(I listened both sides with > tcpdump). But still I get "connetion reset error" from firefox. When I > listen with wireshark after I send my "Client Hello" request the > server which I am trying to connect sends me two https packets which > look like same except first one is normal but in the second one Reset > Flag is set. After these two packets come squid tries to connect to > server from beginning one more time. Do you have any idea where is the > problem and why the server I am connecting resets the connection? > > Good day to you.. > >> In src/client_side.cc the function called httpsAccept() is run on each >> new connection. >> >> Near the end it runs "commSetSelect(newfd, COMM_SELECT_READ, ..." to >> kick off the SSL negotiation. Which in turn starts the regular HTTPS >> receive handling. >> >> I think you need to do something at that point like: >> >> if (s->intercepted) { >> ... new call to handle SNI and lead on to tunnel creation. >> } else { >> commSetSelect(newfd, COMM_SELECT_READ, clientNegotiateSSL ...); >> } >> >> Then you configure a regular https_port with the "intercept" mode set >> and connections to it will run through your code. >> >> Amos >> >> >> ---------- Forwarded message ---------- >> From: Deniz Eren <de...@denizeren.net> >> Date: Wed, Jul 27, 2011 at 10:40 AM >> Subject: Re: SNI squid >> To: Amos Jeffries <squ...@treenet.co.nz> >> >> >> And also where should invoke tunnelStart()? I thought that >> commHandleRead(..) maybe will be the place, but since I don't know the >> structure well maybe you can offer the right place. In addition to >> this I am confused about the steps after tunnelStart() is ok. I tried >> to trace the proxy request and meanwhile run functions in squid, but I >> am still confused. >> >> Thanks in advance.. >> >> On Wed, Jul 27, 2011 at 8:48 AM, Deniz Eren <de...@denizeren.net> wrote: >>> Thanks Amos. >>> >>> On Wed, Jul 27, 2011 at 4:17 AM, Amos Jeffries <squ...@treenet.co.nz> wrote: >>>> On Tue, 26 Jul 2011 16:07:47 +0300, Deniz Eren wrote: >>>>> >>>>> Hi Amos; >>>>> >>>>> About 2-3 weeks ago I have started implementing SNI filter for squid. >>>>> You said that I will need to adjust TunnelStateData so that I can >>>>> create it with only a Comm::Connection object instead of a >>>>> ClientHttpRequest or HttpRequest object(purpose is to pass https >>>>> traffic without processing it). I am trying to do that but I got >>>>> stucked. Can you give me an idea about how to do it? >>>>> >>>>> I am using squid-3.1.14. >>>>> >>>>> Good day to you.. >>>> >>>> >>>> - new version of tunnelStart() which takes the connection details and >>>> generates a fake HTTP request. It will need to work without >>>> ClientHttpRequest as a data source >>>> >>>> The details for these new headers will need to be >>>> >>>> "Date: " squid_curtime >>>> "Host: " client.conn->local.ToHostname(...) [destination IP;port] >>>> "User-Agent: " visible_appname_string >>>> "Cache-Control: no-store, private" >>>> "Via: 0.9 " SquidConfig.visible_hostname >>>> if (forwarded_for) >>>> "X-Forwarded-For: " client.conn->remote.NtoA(...) [client IP] >>>> >>>> There might be others. Those are just the ones that come to mind >>>> immediately. >>>> >>>> >>>> >>>> - a handler to absorb the 200 or such reply which comes back IF sent to a >>>> peer. This will help with re-trying other paths/IPs for the domain. >>>> Probably a flag to indicate seen (or not) the full reply headers which >>>> modified readServer(). Currently it blind-relays every byte. You need it to >>>> read and absorb the initial bytes from "HTTP/" up to "\r\n\r\n" (exactly), >>>> and blind-relay everything else. >>>> >>>> There are bugs in retry on 4xx/5xx etc which I have to work on soon that >>>> also need this. So we may be able to collaborate on the fine details and >>>> testing here. >>>> >>>> OR, >>>> If you wish to simplify for now and avoid that reply handling change you >>>> can alter tunnelPeerSelectComplete() to drop all the serverDestinations >>>> array entries that have a (peerType != HIER_DIRECT). They can be set to >>>> NULL >>>> to discard. Just be careful there are no holes in the array afterward. >>>> >>>> >>>> Amos >>>> >>> >> >> >> >> -- >> Deniz Eren >> > > > > -- > Deniz Eren > -- Deniz Eren