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: elie...@ngtech.co.il -----Original Message----- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Amos Jeffries Sent: Wednesday, January 23, 2019 12:57 To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] 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@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
