On 07/20/2018 03:04 AM, Eliezer Croitoru wrote: > I think we can use MD5/SHA1/SHA256 or even CRC32 to show the "freshness" of > the certificate.
Sorry, you lost me: I see no connection between the previous discussion about CA keys and your new statement about something you call certificate "freshness". > Also this way the ssl_db folder will be free of the burden of tight 600 or > 700 permissions. > > Did I got it right? The stored generated certificates include their private keys so the database should use tight permissions. Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rouss...@measurement-factory.com] > Sent: Thursday, July 19, 2018 11:29 PM > To: Eliezer Croitoru <elie...@ngtech.co.il>; 'Squid Users' > <squid-users@lists.squid-cache.org> > Subject: Re: [squid-users] question about squid and https connection . > > On 07/19/2018 12:08 PM, Eliezer Croitoru wrote: > >> So the ROOT CA key which squid is using is being used for all the fake >> certificates, why do we need so many copies of it? > > FWIW, I cannot think of any reason to store the CA certificate key in > the database of generated certificates. That key is only used to sign a > freshly generated certificate, and the certificate generator never > regenerates certificates, so I do not see the need to reuse that CA key. > > Alex. > > >> -----Original Message----- >> From: Alex Rousskov [mailto:rouss...@measurement-factory.com] >> Sent: Wednesday, July 18, 2018 11:45 PM >> To: Eliezer Croitoru <elie...@ngtech.co.il>; 'Squid Users' >> <squid-users@lists.squid-cache.org> >> Subject: Re: [squid-users] question about squid and https connection . >> >> On 07/18/2018 02:23 PM, Eliezer Croitoru wrote: >> >> >>> Every certificate have the same properties of the original one except >>> the "RSA key" part which it's certifiying. >> >> Assuming you are talking about the generated certificates for the same real >> certificate X, then yes, they will all have the same (mimicked) fields. >> Whether they will be signed by the same CA depends on Squid configuration. >> In my answers, I assumed that all those Squids are configured with the same >> CA (including the same private key). >> >> >>> So what I'm saying is that you cannot say that every certificate which >>> will be created with the same CA will be the same for two different >>> 2048 bits RSA keys. >> >> ... unless the keys are also the same, which was my and, AFAICT, OP >> assumption. >> >> Also, unless you are doing something nasty, it probably does not make sense >> to configure a bumping Squid with a public CA certificate that is identical >> to some other public CA certificate but has a different private key. In >> other words, if you are using 200 Squids with a single public CA >> certificate, then all those Squids should use the same private key. >> >> Alex. >> >> >> >>> -----Original Message----- >>> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] >>> On Behalf Of Alex Rousskov >>> Sent: Friday, July 13, 2018 2:01 AM >>> To: 'Squid Users' <squid-users@lists.squid-cache.org> >>> Subject: Re: [squid-users] question about squid and https connection . >>> >>> On 07/12/2018 02:35 PM, Eliezer Croitoru wrote: >>> >>>> Every RSA key and certificate pair regardless to the origin server >>>> and the SSL-BUMP enabled proxy can be different. >>> >>> I cannot find a reasonable interpretation of the above that would >>> contradict what I have said. Yes, each unique certificate has its own >>> private key, but that is not what Ahmad was asking about AFAICT. >>> >>> >>>> Will it be more accurate to say that just as long as these 200 squid >>>> instances(different squid.conf and couple other local variables) use >>>> the same exact ssl_db cache directory then it's probable that they >>>> will use the same certificate. >>> >>> That statement is incorrect. Squids configured with different CA >>> certificates will generate different fake certificates for the same >>> real certificate. >>> >>> I assume that Ahmad was asking about a situation where 200 Squid >>> instances had the same configuration (including CA certificates). >>> >>> Please note that the certificate generator helper gets the signing >>> (CA) certificate as a parameter with each generation request (because >>> different Squid ports may use different CA certificates). Also, Squid >>> probably does not officially support sharing the certificate directory >>> across Squid instances (even if it works). >>> >>> >>>> Or these 200 squid instances are in SMP mode with 200 workers... If >>>> these 200 instances do not share memory and certificate cache then >>>> there is a possibility that the same site from two different sources >>>> will serve different certificates(due to the different RSA key which >>>> is different). >>> >>> 200 SMP workers or 200 identically-configured Squid instances will >>> generate the same fake certificates for the same real certificate. >>> "Stable certificates" is an important requirement for many distributed >>> Squid deployments. >>> >>> Alex. >>> >>> >>> >>>> -----Original Message----- >>>> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] >>>> On Behalf Of Alex Rousskov >>>> Sent: Thursday, July 12, 2018 11:27 PM >>>> To: --Ahmad-- <ahmed.za...@netstream.ps>; Squid Users >>>> <squid-users@lists.squid-cache.org> >>>> Subject: Re: [squid-users] question about squid and https connection . >>>> >>>> On 07/12/2018 01:17 PM, --Ahmad-- wrote: >>>> >>>>> if i have pc# 1 and that pc open facebook . >>>>> >>>>> then i have other pc # 2 and that other pc open facebook . >>>>> >>>>> >>>>> now as we know facebook is https . >>>>> >>>>> so is the key/ cert that used on pc # 1 is same as cert in pc # 2 to >>>>> decrypt the fb encrypted traffic ? >>>> >>>> Certificates themselves are not used (directly) to decrypt traffic >>>> AFAIK, but yes, both PCs will see the same server certificate >>>> (ignoring CDNs and other complications). >>>> >>>> >>>> >>>>> now in the presence of squid . >>>>> >>>>> if i used tcp connect method , will it be different than above ? >>>> >>>> If you are not bumping the connection, then both PCs will see the >>>> same real Facebook certificate as if those PCs did not use a proxy. >>>> >>>> If you are bumping the connection, then both PCs will see the same >>>> fake certificate generated by Squid. >>>> >>>> >>>> >>>>> say i used 200 proxies in same squid machine and i used to access FB from >>>>> the same pc same browser . >>>>> >>>>> will facebook see my cert/key i used to decrypt its traffic ? >>>> >>>> If you are asking whether Facebook will know anything about the fake >>>> certificate generated by Squid for clients, then the answer is "no, >>>> unless Facebook runs some special client code to deliver (Squid) >>>> certificate back to Facebook". >>>> >>>> In general, the origin server assumes that the client is talking to >>>> it directly. Clients may pin or otherwise restrict certificates that >>>> they trust, but after the connection is successfully established, the >>>> server may assume that it is talking to the client directly. A >>>> paranoid server may deliver special code to double check that >>>> assumption, but there are other, more standard methods to prevent >>>> bumping such as certificate pinning and certificate transparency cervices. >>>> >>>> >>>> >>>>> is the key/cert of FB to decrypt the https content is same on all >>>>> browsers on all computers ? >>>> >>>> If you are asking whether the generated certificates are going to be >>>> the same for all clients, then the answer is "yes, provided all those >>>> 200 Squids use the same configuration (including the CA certificate) >>>> and receive the same real certificate from Facebook". Squid's >>>> certificate generation algorithm generates the same certificate given >>>> the same configuration and the same origin server certificate. >>>> >>>> >>>> HTH, >>>> >>>> Alex. >>>> _______________________________________________ >>>> squid-users mailing list >>>> squid-users@lists.squid-cache.org >>>> http://lists.squid-cache.org/listinfo/squid-users >>>> >>> >>> _______________________________________________ >>> squid-users mailing list >>> squid-users@lists.squid-cache.org >>> http://lists.squid-cache.org/listinfo/squid-users >>> >> > _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
