Remove/Disable logging in unsafe HostnameVerifier and TrustManager about sslcontext-kickstart HOT 5 CLOSED

Hello,

Thank you for your input regarding the unsafe hostname verifier and trustmanager. My intention was to provide information to the enduser when they use it. It is unsafe and I thought it would be good for their monitoring by logging which client/server they allow. This this especially handy when they want to analyse the logs for an audit for example within an enterprise environment.

I can understand you and your frustration and there are multiple ways to solve this issue and you mentioned already one by setting the log level to debug in the library. There is also another way by turning off the logs for a specific class regardless of their log level. Have you tried it out?

If you are using logback your configuration would look like:

<configuration>
    <logger name="nl.altindag.ssl.hostnameverifier.UnsafeHostnameVerifier" level="OFF"/>
    <logger name="nl.altindag.ssl.trustmanager.UnsafeX509ExtendedTrustManager" level="OFF"/>
</configuration>

What logging implementation are you using? I can help you with the actually configuration.

from sslcontext-kickstart.

i am deploying code on an application server where i don't have control over the logging infrastructure. changing/disabling the logger is not an option for me.

for the moment i bypassed the issue by simply using a custom hostname verifier and trustmanager which does the same except for logging. if there would be official support to disable the logging or alternatively offer two implementations of the unsafe classes with and without logging this would allow me to get rid of local implementations.

two implementations could be used as simple as this:

default with logging:

.withTrustingAllCertificatesWithoutValidation()

without logging:

.withTrustingAllCertificatesWithoutValidationAndLogging()

and the same for hostnameverifier

from sslcontext-kickstart.

I have created a pull request which removes all logging within the UnsafeTrustManager and UnsafeHostnameVerifier. After rethinking this use case it indeed a bit verbose for the end-user to get all these warning logs as the end-user already has decided upfront to use the Unsafe variant so additional logs would be not needed to inform them. Please let me know if the adjusted code would do the trick for you

from sslcontext-kickstart.

looks good. thanks

from sslcontext-kickstart.

The changes will be available at version 7.0.2 today

from sslcontext-kickstart.