Re: [squid-users] Install Godaddy certificate on squid to use ssl-bumping functionnality

> Just use delay pools as described in the docs. The "bugs" will not be showstoppers, they might just bias the pools unexpectedly but given you'll have lots of random clients it will probably even out.

It's the first thing i did, so it works for HTTP Request, but there is
nothing in the documentation which explain the delay pools for HTTPS.
What do I have to do about port 443 ? I must redirect it on Squid to
use the delay pools, so to which port ?

> I can't understand how you've been persuaded to accept a project that you should have been doing months of research on and then agree to deliver in days (not knowing what was actually possible). Did you over-promise you your boss? If so, don't!

In fact, I do an internship to finish my studies. My boss suggested me
this project, and I accepted, I just had theoric knowledge about
network and it was very interessant.
I never promise anything and he know that I'm inexperienced so it's
cool, I have no pressure and I haven't any delay to finish this
project but I just asked if there is a more simple solution.
Nevertheless, I want to find a solution quickly if possible :)

Antoine

2014-06-02 16:57 GMT-04:00 Alex Crow <alex_at_nanogherkin.com>:
>
> On 02/06/14 15:12, Antoine Klein wrote:
>>
>> Ok I'm understanding !
>>
>> Finally I'm going to change strategy, if it isn't possible to decrypt
>> HTTPS without warning for client, I shall make differently.
>
> You will have to, as it's impossible to do so without interfering with the
> user's client devices.
>
>
>>
>> So there is two solutions, the first one is to use Squid without
>> deciphering SSL request. So Amos you explained that but I don't
>> understand what bugs is encountered. So in this case, how can I
>> configure Squid ? I didn't find example and I have already asked for
>> that but i was told it would be impossible, but they were not sure.
>
>
> Just use delay pools as described in the docs. The "bugs" will not be
> showstoppers, they might just bias the pools unexpectedly but given you'll
> have lots of random clients it will probably even out.
>
>
>>
>> The second solution consists in not using Squid, but to apply a QoS
>> differently, but I need a QoS like the Squid delay pool, do you know
>> if it is possible ? Alex you already spoken to me about LARTC, but I
>> need to find a solution quickly, so I fear that it was too long to
>> understand the Linux QoS possibilities.
>
>
> How about Shorewall, pfSense, etc? No-one here probably has the time to give
> you an out-of box setup that will suit you. I know for sure I don't. You
> also have a pre-existing firewall and given it looks fairly magical it
> should be able to do per-ip QoS (at least if you just drop the Squid before
> it hits the FW)
>
> I can't understand how you've been persuaded to accept a project that you
> should have been doing months of research on and then agree to deliver in
> days (not knowing what was actually possible). Did you over-promise you your
> boss? If so, don't!
>
> I never promise to deliver anything. I give an estimate that is bases on
> "(((Time I expect to take this given I know everything *3) + (Time I think
> I'll need to find something out when I find I don't know everything *3)) *
> (Time it will take me to reconcile what people said they want vs what thet
> actually need *3) * 3)". If an external supplier is involved multiply the
> whole lot by *at least* 10.
>
> That works out to about 2 months for what your average client/boss/marketing
> person says will take a week...
>
> Cheers
>
> Alex
>
>
>
>
>
>
>
>>
>> Regards.
>>
>> 2014-06-02 10:06 GMT-04:00 Antoine Klein <klein.anto_at_gmail.com>:
>>>
>>> Ok I'm understanding !
>>>
>>> Finally I'm going to change strategy, if it isn't possible to decrypt
>>> HTTPS
>>> without warning for client, I shall make differently.
>>>
>>> So there is two solutions, the first one is to use Squid without
>>> deciphering
>>> SSL request. So Amos you explained that but I don't understand what bugs
>>> is
>>> encountered. So in this case, how can I configure Squid ? I didn't find
>>> example and I have already asked for that but i was told it would be
>>> impossible, but they were not sure.
>>>
>>> The second solution consists in not using Squid, but to apply a QoS
>>> differently, but I need a QoS like the Squid delay pool, do you know if
>>> it
>>> is possible ? Alex you already spoken to me about LARTC, but I need to
>>> find
>>> a solution quickly, so I fear that it was too long to understand the
>>> Linux
>>> QoS possibilities.
>>>
>>> Regards.
>>>
>>>
>>> 2014-05-31 12:54 GMT-04:00 Amos Jeffries <squid3_at_treenet.co.nz>:
>>>
>>>> On 1/06/2014 3:49 a.m., Alex Crow wrote:
>>>> <snip>
>>>>>
>>>>> But given all you really need is QoS, why don't you either (a) dispense
>>>>> with Squid and just to QoS on the firewall for your Wifi subnet or (b)
>>>>> put a transparent firewall between your clients and the Squid server
>>>>> that does QoS? Or just see if Squid delay pools work for SSL (I think
>>>>> they *do*, the traffic still passes via Squid as a CONNECT request -
>>>>> it's just that Squid can't "see" or proxy the plaintext content.)
>>>>>
>>>> I second all of the above. In particular that the built-in QoS features
>>>> of the firewall or router device neworking config is far better place to
>>>> be doing the delay actions than Squid.
>>>>
>>>> In regards to delay pools and HTTPS. As far as I know the pools work
>>>> without decrypting, although you may encounter one of a handful of bugs
>>>> which trigger over or under counting of bytes (depending on the bug
>>>> hit). So you may need a special delay pool configured with a hack on the
>>>> speed value of port 443 traffic to make the user-visible speed what they
>>>> expect.
>>>>
>>>> Amos
>>>>
>>>
>>>
>>> --
>>> Antoine KLEIN
>>
>>
>>
>

-- 
Antoine KLEIN