New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSL Errors Level Downgrade #5109

Closed
TenGbps opened this Issue Sep 14, 2018 · 0 comments

Comments

Projects
None yet
2 participants
@TenGbps

TenGbps commented Sep 14, 2018

When a client cause a SSL error like
'CertPathValidatorException'
'CertificateExpiredException'

2018-09-14 10:09:04,226 ERROR: org.graylog2.plugin.inputs.transports.NettyTransport - Error in Input [GELF TCP/5b5addf0a16c995e75a84e45] (channel [id: 0x114d955b, /x.x.x.x:58652 =>
/x.x.x.x:10108])
Caused by: java.security.cert.CertPathValidatorException: validity check failed
        at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135) ~[?:1.8.0_162]
        at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:223) ~[?:1.8.0_162]
        at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140) ~[?:1.8.0_162]
        at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79) ~[?:1.8.0_162]
        at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292) ~[?:1.8.0_162]
        at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:357) ~[?:1.8.0_162]
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:270) ~[?:1.8.0_162]
        at sun.security.validator.Validator.validate(Validator.java:260) ~[?:1.8.0_162]
        at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[?:1.8.0_162]
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:279) ~[?:1.8.0_162]
        at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:130) ~[?:1.8.0_162]
        at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1966) ~[?:1.8.0_162]
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:237) ~[?:1.8.0_162]
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) ~[?:1.8.0_162]
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) ~[?:1.8.0_162]
        at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) ~[?:1.8.0_162]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_162]
        at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) ~[?:1.8.0_162]
        at org.jboss.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1393) ~[graylog.jar:?]
        at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1256) ~[graylog.jar:?]
        ... 19 more

The graylog log file be full very quickly.
So this is a problem because some one with a bad TLS configuration can write 50Go log easy.

Can you change the verbose level to DEBUG ?

  • Graylog Version: 2.4.6
  • Elasticsearch Version: 5.5.1
  • MongoDB Version: 2.6.12
  • Operating System: CentOS7
  • Browser version: Firefox 60 ESR

mpfz0r added a commit that referenced this issue Oct 1, 2018

Catch Netty exceptions and avoid logging stacktraces
To handle exceptions that happen in the server context,
we need to register our ExceptionLoggingChannelHandler as a childHandler.

In addition, make sure that the ExceptionLoggingChannelHandler is
always added to the top of the (bottom-up evaluated) pipeline.
Otherwise it might miss some exceptions.

Do not propagate the exception any further.
A full netty stacktrace does not help anyone.
One meaningful log message should be enough.
This last bit of the change fixes #5109

mpfz0r added a commit that referenced this issue Oct 2, 2018

Catch Netty exceptions and avoid logging stacktraces
To handle exceptions that happen in the server context,
we need to register our ExceptionLoggingChannelHandler as a childHandler.

In addition, make sure that the ExceptionLoggingChannelHandler is
always added to the top of the (bottom-up evaluated) pipeline.
Otherwise it might miss some exceptions.

Do not propagate the exception any further.
A full netty stacktrace does not help anyone.
One meaningful log message should be enough.
This last bit of the change fixes #5109

@kroepke kroepke closed this in #5168 Oct 3, 2018

kroepke added a commit that referenced this issue Oct 3, 2018

Catch Netty exceptions and avoid logging stacktraces (#5168)
To handle exceptions that happen in the server context,
we need to register our ExceptionLoggingChannelHandler as a childHandler.

In addition, make sure that the ExceptionLoggingChannelHandler is
always added to the top of the (bottom-up evaluated) pipeline.
Otherwise it might miss some exceptions.

Do not propagate the exception any further.
A full netty stacktrace does not help anyone.
One meaningful log message should be enough.
This last bit of the change fixes #5109
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment