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: elie...@ngtech.co.il -----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
