On 30/05/14 21:12, Antoine Klein wrote:
> Ok I agree with you, i wasn't clear to describe my issue :/ I'll try
> to be more understandable.
>
> My company is a bus company, the Clients aren't specific, they are
> like lambda users. In fact, the WIFI is deployed in bus station so
> everybody can use this WIFI, and there is not authentification, just a
> page to accept terms of use.
OK so at least you have something for them to agree to. You have to
state there that the usage including content may be intercepted and
logged - certainly if the laws in your country require you to.
>
> I don't need to decrypt SSL, I just need to use Delay Pool, so I
> believed it wasn't possible to apply a Delay Pool without decrypt SSL
> on HTTPS request, anyway i didn't find how to do that. The cache is an
> option but really not necessary.
I see nothing on the delay pools page to suggest that you need to
decrypt https to make it work.
>
> No it's not a firewall of the NSA :) , anyway i don't believe, it's my
> boss who explained me that, the firewall inspect the packets, and he
> confirms that it's not illegal else they wouldn't do that.
You can't intercept the /content/ of https packets without an MITM attack.
>
> In my mine, i think when a WIFI user wants to connect on HTTPS page,
> the request detect a MITM attack but the certificate assure that it's
> normal and secure because godaddy know that we are a trusted company.
> After that, the request on the proxy is redirected on specific squid
> port, squid decipher the SSL request and it create a new https request
> on the web with its certificates from user request.
SSL does not work like this! If a user requests site
https://mylittlepony.com, they expect the SSL certificate's subject name
to be "mylittlepony.com" not whatever the domain you got for your
godaddy certificate. If the subject name of the cert does not match the
visited site, there will always be a warning in the browser. You also
cannot use the Godaddy cert as a CA cert as the certificate basic
constraints on a commercially issued cert prevent it from being used as
a CA.
You need to create your own CA with a private key, then, and only then,
can you use those two to issue certs, signed by your private key, with
the subject name of each site the clients visit. The clients will still
get a warning as your CA cert is not in their built-in list of trusted CAs.
That is all there is to it. You will in no way be able to get rid of
warnings in the browser without both bumping and dynamic cert
generation, plus your CA (*NOT* GoDaddy's) installed on the clients.
The only way you could do this (and no even marginally savvy user would
ever trust it) would be to used a "browser-in-browser" frame
portal/web-services proxy. This is way out of scope for this list.
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.)
Cheers
Alex
>
> 2014-05-30 11:44 GMT-04:00 Alex Crow <alex_at_nanogherkin.com>:
>> Hi Antoine,
>>
>> Replies below:
>>
>>
>> On 30/05/14 15:44, Antoine Klein wrote:
>>> Ok i'm really sorry, i don't understand the english very well...
>>> I read again the discussion but i am confused :/
>>>
>>> Before this project i had not any knowledge about certificates and SSL
>>> connexions but i did several research on the subject, especially on
>>> squid wiki.
>>> I also read again the documentation here :
>>> http://wiki.squid-cache.org/Features/SslBump
>>> http://wiki.squid-cache.org/Features/DynamicSslCert
>>> http://wiki.squid-cache.org/Features/HTTPS
>>> But nothing concern trusted signed certificate :/
>>>
>>> My company wishes to offer to its clients a public WIFI, i need to use
>>> squid for the delay pool, and possibly the cache. There is already a
>>> warning given on the connexion where we have to accept terms of use
>>> which warns the user.
>>
>> Who are your "clients" - by which I mean not only what devices/browsers but
>> also what relationship do they have to your company?
>>
>> I think (anyone correct me if I'm wrong) that delay pools do not require you
>> to decrypt *anything*. To cache SSL replies, inspect for viruses/malware/bad
>> URL paths, you do need to do so, hence SSLBump.
>>
>>
>>> So, according to you, isn't it possible ?
>>> I think it's strange, because the WIFI is deployed, and the connexion
>>> of clients passes by the firewall which already decipher packets.
>>
>> I have no idea what you are talking about here. How can your firewall
>> possibly decipher SSL communications between <some random Wifi Connected
>> device> and <some web server out on the internet>. Again, this would mean
>> that SSL would be utterly worthless (which despite recent developments, it
>> is not). Unless you gor your firewall from the NSA in which case I'd not
>> recommend advertising that fact on here!
>>
>>
>>
>>
>>> I don't understand why do you speak about dynamic certificate
>>> generation, does it concern my problem ? Because finally i have the
>>> certificate signed by godaddy and the private key of this certificate.
>>
>> I feel like you might be wasting your time (and money) if you paid for this,
>> You presumably have submitted a CSR for <foo.whatever.domain> to be signed
>> by Godaddy. and received a certificate (.pem/.p12/.crt whatever) back How do
>> you propose to use the certificate (which only certifies that domain) to
>> somehow provide client browsers with a valid certificate for whatever
>> https:// site they choose to visit? How would a cert for
>> <foo.whatever.domain> have any use for someone visiting
>> https://mylittlepony.com (example!). Or have we just completely missed the
>> point and this SSL stuff is just for your own web server behind squid - in
>> which case you have gone completely in the wrong direction and need to be
>> looking at setting up a "reverse prosy", which does not require SSLBump at
>> all and would indeed work with what you've just done.
>>
>>
>>> Anyway, thanks for your patience. :)
>>
>> I fear that even if mine does not run out then that of others may do so
>> first. You really need to state exactly what it is you are trying to
>> achieve, and this has so far IMHO not happened - and your English is
>> perfectly good enough to do so.
>>
>> Thanks
>>
>> Alex
>>
>
>
Received on Sat May 31 2014 - 15:50:00 MDT
This archive was generated by hypermail 2.2.0 : Sat May 31 2014 - 12:00:07 MDT