Amos, Thanks for the feedback. Now that we write about the subject in clear text it's making things a bit clear. I wasn't sure about the purpose of the helpers to begin with. As you wrote before, for specific use cases these X.509 properties are what this specific organization need to verify. >From my point of view most users(non-technical) are yet to understand these properties good enough and these are things that us and our kids needs to learn about the Internet: "not every Encrypted traffic means secure!". Specifically Let's encrypt makes sure that the world of encryption will be more popular and there for more secure. So +*2 for them but still the point stays with then that encryption might not always be the right way. SFTP ,MS and OpenSSL + others proved that encryption is a must in our world but not always the right answer. ..Also DNSSec and/or EDNS makes this picture much clear. Eliezer * If I missed someone it's because there are too many to say thank you to/for. ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Amos Jeffries Sent: Wednesday, January 23, 2019 12:57 To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA? On 23/01/19 7:59 pm, Eliezer Croitoru wrote: > OK so, > > Every Root CA have differ level of certification. > For example there are Root CA's which are allowed to sign only for encryption > ...and basic domain ownership validation which can be verified against a Domain Regristrar. > Compared to this there are couple other level's of Certificates like what is name "EV" (the one of banks and such critical ORG's). > Let's encrypt brings to domain ownership the ability to being verified as the domain owner or it's proxy. > > The Root CA that the bank of America uses has the license to offer not only encryption but also: > * Ensures the identity of a remote computer > * Proves your identity to a remote computer > * Protects e-mail messages > * Ensures software came from software publisher > * Protects software from alteration after publication > * Allows data to be signed with the current time > > Compared to Let's encrypt that is an intermediate CA with the next license: > * Protects e-mail messages > * Ensures the identity of a remote computer > * Proves your identity to a remote computer > * Allows data to be signed with the current time > * Allows data on disk to be encrypted > * 2.23.140.1.2.1 > * 1.3.6.1.4.1.44947.1.1.1 > * Document Signing > Those listed things above sound like the X.509 certificate 'use' properties are what you actually need to be checking. Am I right? > Which doesn't includes: > * Ensures software came from software publisher > > Which is critical for ISO bounded web services. > > In another words: > If the certificate is not EV ie the name of the corporation or business it means that it's not ISO compliance regarding > paying using a credit/visa/other card. > > So if you are going to pay to someone over the Internet only pay if you know and validated the identity of the owner and\or orginzation. > This concept was introduced to prevent phishing and other things. > One of the exception I have seen is Paypal main site which does have EV named license/certificate but the name is not embedded into the certificate so I prefer not to buy in this specific site but buy locally. > A validator which checks for existence or non-existence of certain X.509 permissions would be the better approach instead of a curated whitelist of CA names. That way; * you are not limited to whitelisting and its inherent "human error" or incompleteness component biasing for/against any particular CAs, * you can publish the required criteria for transparency, * CAs can choose for themselves whether they adjust certs permissions to be blocked or un-blocked without involving any tricky politics to lower your required standard of proof. Some CAs might for example have a special root CA with restricted policies to comply with the ISO requirement, and another for their wider use. Amos _______________________________________________ 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
