I think we can use MD5/SHA1/SHA256 or even CRC32 to show the "freshness" of the certificate. Also this way the ssl_db folder will be free of the burden of tight 600 or 700 permissions. Did I got it right? Thanks, Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] Sent: Thursday, July 19, 2018 11:29 PM To: Eliezer Croitoru <eliezer@xxxxxxxxxxxx>; 'Squid Users' <squid-users@xxxxxxxxxxxxxxxxxxxxx> Subject: Re: 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:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, July 18, 2018 11:45 PM > To: Eliezer Croitoru <eliezer@xxxxxxxxxxxx>; 'Squid Users' <squid-users@xxxxxxxxxxxxxxxxxxxxx> > Subject: Re: 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-bounces@xxxxxxxxxxxxxxxxxxxxx] >> On Behalf Of Alex Rousskov >> Sent: Friday, July 13, 2018 2:01 AM >> To: 'Squid Users' <squid-users@xxxxxxxxxxxxxxxxxxxxx> >> Subject: Re: 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-bounces@xxxxxxxxxxxxxxxxxxxxx] >>> On Behalf Of Alex Rousskov >>> Sent: Thursday, July 12, 2018 11:27 PM >>> To: --Ahmad-- <ahmed.zaeem@xxxxxxxxxxxx>; Squid Users >>> <squid-users@xxxxxxxxxxxxxxxxxxxxx> >>> Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxx >>> http://lists.squid-cache.org/listinfo/squid-users >>> >> >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users >> > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
