JVM security properties warning

[Daniel Jeliński]

(adding back net-dev)

Hi Autumn,
Thanks for the clarifications.

The JDK usually doesn't do any logging unless asked to; I don't think
a misused property warrants a warning on stderr.

I think we can add a set of system properties to configure caching.
Would you be interested in that? We originally used security
properties because DNS spoofing was a big concern; it's much less of a
concern today. Alas, we can't match the names of the security
properties - the naming convention dictates that all new system
property names start with "jdk." or "java.".

Our documentation can mislead users into thinking that they could
configure caching using system properties. I filed
https://bugs.openjdk.org/browse/JDK-8323089 for that.

Regards,
Daniel

pon., 29 sty 2024 o 18:43 Capasso, Autumn <autumcap at amazon.com> napisał(a):
>
> Hi Daniel,
> I wanted to thank you so much for all the information you took the time to provide I really appreciate it. We noticed many developers had misconfigured security properties and seem unsure of how to use them on Github, and Stackoverflow we are purposing a mechanism to warn developers through stderr  about misconfigured Security properties that have been mistaken for system properties. Developers think they’re changing a System property and they not get their desired effect. I created a JBS issue that I have included in this email. We would like to focus on the DNS cache TTL property. During our investigation of this issue we noticed many developers had misconfigured security properties. One example is a search on Github for -Dnetworkaddress.cache.ttl: https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code<https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code> this search illustrates how developers mistake security settings for system properties and end up with misconfigurations.
>
> Thank you so much,
> Autumn
>
> On 1/5/24, 6:32 AM, "Daniel Jeliński" <djelinski1 at gmail.com <mailto:djelinski1 at gmail.com>> wrote:
>
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
>
>
>
> Hi Autumn,
> Thanks for bringing it up here.
> The documentation could definitely use some improvement; we could make
> the property documentation link to the Security class, which in turn
> documents the use of the java.security file. We should also remove
> these security properties from the system properties list
> (https://docs.oracle.com/en/java/javase/21/docs/api/system-properties.html <https://docs.oracle.com/en/java/javase/21/docs/api/system-properties.html>).
>
>
> I'm not sure about exposing the DNS configuration as system
> properties. The configuration can already be set using undocumented
> system properties, but only if the corresponding security property is
> not set (so, for example, sun.net.inetaddr.ttl will work, but
> sun.net.inetaddr.negative.ttl will not). There's probably a reason why
> these properties are not documented, others could explain.
>
>
> As I'm sure you found out already, the default TTL is 30 seconds for
> successful lookups, 10 seconds for failed lookups. What kind of values
> would you use to reduce the DNS pressure?
>
>
> If you're looking to reduce the DNS activity, there are many other
> options to choose from:
> - use a local caching DNS resolver like systemd-resolved
> - cache the resolved InetAddress instance on the application level
> - use a custom address resolution service provider (requires JDK 18+,
> see https://openjdk.org/jeps/418 <https://openjdk.org/jeps/418>)
> - use the hosts file
> - use a local caching DNS server
>
>
> The default JDK resolver uses the standard C APIs to resolve DNS
> hostnames, and has no access to the TTL information returned by the
> server. Further, negative caching does not differentiate between a
> negative response and a DNS failure. For that reason you should prefer
> using caches that have access to that information.
>
>
> Let me know if that helps.
> Regards,
> Daniel
>
>
> czw., 4 sty 2024 o 22:45 Capasso, Autumn <autumcap at amazon.com <mailto:autumcap at amazon.com>> napisał(a):
> >
> > We began investigating this issues when we noticed many developers had misconfigured security properties. One example is a search on github for Dnetworkaddress.cache.ttl: https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code <https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code> this search illustrates the how developers mistake security settings for system properties and end up with misconfigurations. We see developers are misconfiguring networkaddress.cache.ttl and networkaddress.cache.negative.ttl settings, Often in the effort to increase the TTL for entries in the DNS cache, they mistakenly change the networkaddress.cache.ttl on the command line which does nothing. This means teams don’t actually end up raising the DNS cache TTL. Inadvertently leaving the cache TTL too low places more pressure on DNS servers. We would be open to at first narrowing the scope from all security properties to just the DNS cache properties and doing a proof of concept. We’ve also gotten the suggestion of implementing it by adding system property overrides for those DNS security properties.
> >
> >
> >
> > Thank you in advance,
> >
> > Autumn Capasso
> >
> >
> >
> >
>
>
>