Hi Chris, On Tue, Oct 23, 2018 at 8:12 AM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Igor, > > On 10/18/18 19:09, Igor Cicimov wrote: > > On Fri, Oct 19, 2018 at 2:14 AM Christopher Schultz < > > ch...@christopherschultz.net> wrote: Java has no notion of CAs, nor > > does any trust store, really. > > > > > >> Correct, but by loading all CAs in the trust store it kinda > >> does, indirectly. > > > >> A > > certificate is trusted if it is present in the trust store, full > > stop. It not need be a "CA". The oly thing being a CA gets you is > > ... in everyone's default trust stores. > > > > > > The system property javax.net.ssl.trustStore only sets the default > > trust store for the JVM and any components which choose to use it. > > For example, if you use HttpURLConnection without any explicit > > configuration, it will use that. Same with Apache httpclient. > > > > But both of those can be configured to use a different trust > > store, which case they will *not* fall-back to the built-in trust > > store (the one in JAVA_HOME/lib/security/cacerts. > > > >> Well I see couple of issues with this approach of the trsutstore > >> being the only source of truth. First is the obvious one, when > >> using a custom trust store I have to load *all* CA certificates > >> that already exist somewhere else on the server (and in multiple > >> places) in the trust store too otherwise no certificate will > >> ever get validated. > Why would you want to use a custom trust store that also includes the > whole list of trusted certs from the vendor? Either you want to > delegate everything to the vendor (e.g. Oracle) or you know who you > are connecting to, and you only need one cert (or a small selection of > them) in your trust store. > > I think the problem is that people rely on "the trust store for the > JVM" as the trust store for everything, which is a Bad Idea. Use > separate trust stores for different types of connections. > > > > When overriding the default trust store for the JVM, the trust > > store you specify should be the ONLY trust store consulted. It > > should not fall back. I can confirm this is the case on Java 8 - > > 11, at least the ones I happen to be using. Any other behavior > > would be a security problem. > > > >> Not sure I can agree with this reasoning too. All apps on the > >> server use the default system CA store so should we consider them > >> insecure? I see no harm of Java looking in the default > >> location(s) on the server when a cert can not be validated by > >> looking in the trust store. Otherwise as noted above in case of > >> custom trust store we need to load all those certificates anyway > >> ending up with same certificates stored in multiple places, > >> making the size of the trust store unnecessary big. > > 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 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)? 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. > The default trust store that ships with the JVM is really only good if > you want to connect to an arbitrary service and inherit all the certs > that e.g. Oracle trusts. That only makes sense if you don't know in > advance who you'll be connecting to. > > > The proper way to validate a certificate chain is to perform the > > following algorithm: > > > > 0. Start with the server's certificate (the leaf) 1. Is the > > certificate in the trust store? Yes: chain is valid; stop 2. Is the > > certificate signed by a cert in the trust store? Yes: chain is > > valid; stop 3. Is the certificate signed by the next cert in the > > chain? No: chain is invalid; stop 4. Move to the next cert in the > > chain 5. Go to step 1 > > > > So if you use an empty trust store and try to connect to > > https://www.google.com, you should find that you get an exception > > thrown. Something like this: > > > > Exception in thread "main" javax.net.ssl.SSLHandshakeException: > > sun.security.validator.ValidatorException: PKIX path building > > failed: sun.security.provider.certpath.SunCertPathBuilderException: > > unable to find valid certification path to requested target > > > > > >> To conclude, the way I would expect the trust store to be used > >> and the whole validation done: > > > >> 1. I use custom trust store because I need to load self signed > >> certificates that I need to validate when connecting to lets say > >> partner APIs that use self signed certificates and I know I can > >> trust > So... you just need to trust a self-signed certificate. That shouldn't > be a problem. > > >> 2. I would expect nothing else needed in this store as every > >> other valid certificate under the sun is already located in > >> default locations on the server Java is running on > And why do you need to be able to validate all those other > certificates if you are only connecting to one service? > > >> 3. In case JAVA_HOME/lib/security/cacerts is my trust store (the > >> default) I would expect Java to use the system store(s) too in > >> case a certificate can not be validated simply because a CA is > >> missing in the Java store. > > To behave otherwise would be a security problem: if you install your > own trust store, falling-back into the JVM's default trust store means > that trust is being misplaced. There would be no way to dis-trust any > certificate without physically deleting the certificate from the > system's default trust store. That may not be possible if the system > isn't writable by e.g. the application operator. > 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. > >> Example, DigiCert Global Root G2 CA is missing in the Java > >> versions older than 8u91 causing inexplicable PKIX exceptions but > >> can be found in the system store, both under /etc/ssl/certs and > >> /usr/share/ca-certificates which are (much) more frequently > >> updated with new certs than Java versions. > > Those errors aren't inexplicable: they occur because the certificate > is not trusted. Java doesn't use the system trust store, ever. You > can't even configure it to use the system's trust store. You'd have to > build a custom TrustManager and wire it into the system's trust store > yourself. > > If you want to trust both your own custom trust store plus the > platform default, you'll have to write code to make that happen. It's > possible, but it's not "free". [1] > > - -chris > > [1] > https://stackoverflow.com/questions/24555890/using-a-custom-truststore-i > n-java-as-well-as-the-default-one > <https://stackoverflow.com/questions/24555890/using-a-custom-truststore-in-java-as-well-as-the-default-one> > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvOPUoACgkQHPApP6U8 > pFh1EhAAtuI+UD5R6CcVL0NOoFZYqhoDppkMLaFAFTzu5PtCyFZXEX4sDZhzd1kp > RqZCLXhliAbACnYk2AlkNKEgIaSZNoi5NxozmFQGka1o/dcQQqvJvTxYp1txj5dM > LQSXDybEJeeHT10fAThuwnRaDcVaJdtv1ILri2/FsswP1ZBnjki5kXKiRBzBZyw5 > NSH/wJTm2cx7no6B2JdvckKXjExFdjO/TT8i6KOmcKjG80fjRUVbSpH3lXhV01nN > +tMQcJ/D3RVHLBR2tUKi/WhwVXgOxfx3Vkb43YAuOcrQYD+Fi0V2eQh7JdJhlvYD > EAGOs8bzOSFEDx3oQBsXSP0BwGlBCL//erxDI9iKtyzOBsxEJk+dU1fKalayj7l0 > VicN2p4smHnBbeYJDFuAGvSMywuLfxXNrJJ8gY/6bP30554ydDA5lDNdXmUmaR06 > gnGWX2ZaGqn6Icijdm8VpKUnwUA2gHzXPknFnOI806V6SWJzVEmnwg1913jBbq0T > FarSuVy+JuN/dkhIgBC90U9dstgnAhhjJBv920ia8wbjaCsewgpy74Yyf8UitU/Z > GJYnmKYAqk1KLjXXTXmM2KsncsbMCWwSba/OqbLtOQSQ2GtQ3qBbxQ/C+OgZacMj > Uysw7G6h8q0AeVRwN2wwDRwhfbmu2AsXN8dNSfSDU6bG6+kghE4= > =z9/7 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
