-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Igor,
On 10/23/18 05:35, Igor Cicimov wrote: > On Tue, Oct 23, 2018 at 8:12 AM Christopher Schultz < > ch...@christopherschultz.net> wrote: You are talking about a web > application connecting to an outside service like a REST service > via HTTPS, right? How many of these services could you possibly be > connecting to? Why don't you already know their CAs? > > >> Actually many. My point is I don't have to know their CA's >> *except* when they are self signed. So use a custom trust-store for this services with a self-signed certificate and use the default trust store for everything else. I don't really see a problem, here, conceptually. The real problem is that many software libraries don't come with the ability to easily switch to a separate trust store to connect to them. They just assume that you'll import their certificate into a system-wide trust store and move-on. I don't like that strategy one bit. >> So when I connect to an API partner with a certificate signed by >> a valid CA then the cert should be obviously validated without me >> putting the CA in the trusted store. Isn't this the way any >> other app would expect things to happen (except java obviously)? All applications I know of require you to import anything it doesn't already trust in order to trust those services (duh). The difference is that you think it should fall-back on the system trust store and Java does not (and I happen to agree with that strategy). You can code around it if you absolutely want your JVM to behave that wa y. >> Another reason is containers where we try to get the smallest >> possible image size. Why would I even bother changing and bloat >> my image just because I need to add CAs in my trust store when >> they have already been loaded via the installed ca-certificates >> package lets say? Much easier than maintaining my own trust store >> file. Unfortunately, Java uses trust store bundles and e.g. Linux packages everything as a directory of PEM-encoded DER files. Java simply can't use those as a default trust store. Again, you can write your own TrustManager to use those OS-provided certificates; Java doesn't provide such code out of the box. The cacerts file that comes with Java 8 is 113k. I don't think it's breaking your byte allotment for containers. >> I get what you are saying and it is a valid point too. But as I >> said previously how many occasions do you know or heard of that >> someone would want to remove a CA from the system store? It is >> also matter of policy though, do you start by trusting everyone >> (in this case all CAs) or no one. Symantec? Or all the other sub-CA's who probably never should have been in anyone's root trust store in the first place? For my money, I always use custom trust stores for individual external services. It protects me against all manner of Bad Things such as stupid CAs, MitM, etc. If you trust everything without question, you may make a connection you shouldn't have and give-up private data to a (truly, not technically) untrusted recipient. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPNmMACgkQHPApP6U8 pFiaahAAuL0M8hU+NzxiyKXDTTyrmwW0kMtxmhXqdmZDbIuQmVeJtX4zqH7t7bW7 dGcLomXFqnaj24jXWtg2F2yCi/xS5V9EaCypVKpgMOmr7Hd7V6FG5TTa1MNaDARL 34acLCbXi7/R934Vs6il5wQaJqT97b2sT4KfwJ8qdb3nxNK+UxpOqzrqlH7CVfKm GcNmUXDqSaOn6+a6vib5j+QTONMxC2tS8jqSmAHASPgqaTao/MO5KypoIe3wls0w 9B/HFjUPu29T8Nfesj8CX+MpR544DUCD5QPmBzAMfgkKFXCVcQYvQ58Bu2hWybL7 T/B3dAnBUqjDtuxgC+EQeaoxC72S6AYGvWbDzgCFrOyXWai2HWkQSHi949Oh+WjY XcaW1ykx888mFuvE/2GCC9tY/jfS+aoXwUhrnRJgZ2Qy2VQPHxPedap2xTELaD4k ijlCHq3DhjkUSa/2m96YWF964ub2RlH2auB32Rk2CVZ88PGdjCiEKCs5HTNSdoa+ tESYbRDeiZFkmBNRn6BeZ/fChH9ReUXoAy/ggC2V5/v+QZpLqdZ3iEMpRejUY/9x L73iNV29d+h+OXJv/1WAwajW4GuxZVkzJ2z4LWbjVSfOS3u9SQgI2kE8zuPgbXeR 5u3CpxUQAYtHLOpteefQF1peJcEiE7i9DlLE8j0zKuVwi0Q5Z+U= =gNYA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
