Re: SNI squid

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 <deniz_at_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 <deniz_at_denizeren.net>
>> Date: Wed, Jul 27, 2011 at 10:40 AM
>> Subject: Re: SNI squid
>> To: Amos Jeffries <squid3_at_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 <deniz_at_denizeren.net> wrote:
>>> Thanks Amos.
>>>
>>> On Wed, Jul 27, 2011 at 4:17 AM, Amos Jeffries <squid3_at_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