Allow the TCP inputs to support TLS #6873
Labels
Comments
ph
added a commit
to ph/beats
that referenced
this issue
May 4, 2018
We can now receive events on the TCP input with a TLS connection, the input uses existing type to make sure we have the same naming convention and code used by outputs that support TLS communication (Elasticsearch and Logstash). The configuration will look like this: ``` host: "localhost:9000" ssl.enabled: true ssl.verification_mode: full # default ssl.supported_protocols: [TLSv1.1] ssl.cipher_suites: [] ssl.certificate_authorities: ["/etc/cacert"] ssl.certificate: /etc/mycert.crt ssl.key: /etc/mycert.key ssl.client_authentification: required ``` One added configuration is `client_authentification`, this option is only used in the context of server and define how we will force the authentification, it support the three following options: - `required`: Assume that the client will provide a certificate and we will verify it. (default) - `optional`: If a certificate is given by the client. - `none`: We don't validate client certificate. *Note: This commit contains a script to generate certs from a self signed CA. Fixes: elastic#6873
This was referenced May 9, 2018
ph
added a commit
to ph/beats
that referenced
this issue
May 17, 2018
We can now receive events on the TCP input with a TLS connection, the input uses existing type to make sure we have the same naming convention and code used by outputs that support TLS communication (Elasticsearch and Logstash). The configuration will look like this: ``` host: "localhost:9000" ssl.enabled: true ssl.verification_mode: full # default ssl.supported_protocols: [TLSv1.1] ssl.cipher_suites: [] ssl.certificate_authorities: ["/etc/cacert"] ssl.certificate: /etc/mycert.crt ssl.key: /etc/mycert.key ssl.client_authentication: required ``` One added configuration is `client_authentication`, this option is only used in the context of server and define how we will force the authentification, it support the three following options: - `required`: Assume that the client will provide a certificate and we will verify it. (default) - `optional`: If a certificate is given by the client. - `none`: We don't validate client certificate. *Note: This commit contains a script to generate certs from a self signed CA. Fixes: elastic#6873
kvch
pushed a commit
that referenced
this issue
May 17, 2018
…#7056) We can now receive events on the TCP input with a TLS connection, the input uses existing type to make sure we have the same naming convention and code used by outputs that support TLS communication (Elasticsearch and Logstash). The configuration will look like this: ``` host: "localhost:9000" ssl.enabled: true ssl.verification_mode: full # default ssl.supported_protocols: [TLSv1.1] ssl.cipher_suites: [] ssl.certificate_authorities: ["/etc/cacert"] ssl.certificate: /etc/mycert.crt ssl.key: /etc/mycert.key ssl.client_authentication: required ``` One added configuration is `client_authentication`, this option is only used in the context of server and define how we will force the authentification, it support the three following options: - `required`: Assume that the client will provide a certificate and we will verify it. (default) - `optional`: If a certificate is given by the client. - `none`: We don't validate client certificate. *Note: This commit contains a script to generate certs from a self signed CA. Fixes: #6873
stevea78
pushed a commit
to stevea78/beats
that referenced
this issue
May 20, 2018
…elastic#7056) We can now receive events on the TCP input with a TLS connection, the input uses existing type to make sure we have the same naming convention and code used by outputs that support TLS communication (Elasticsearch and Logstash). The configuration will look like this: ``` host: "localhost:9000" ssl.enabled: true ssl.verification_mode: full # default ssl.supported_protocols: [TLSv1.1] ssl.cipher_suites: [] ssl.certificate_authorities: ["/etc/cacert"] ssl.certificate: /etc/mycert.crt ssl.key: /etc/mycert.key ssl.client_authentication: required ``` One added configuration is `client_authentication`, this option is only used in the context of server and define how we will force the authentification, it support the three following options: - `required`: Assume that the client will provide a certificate and we will verify it. (default) - `optional`: If a certificate is given by the client. - `none`: We don't validate client certificate. *Note: This commit contains a script to generate certs from a self signed CA. Fixes: elastic#6873
stevea78
pushed a commit
to stevea78/beats
that referenced
this issue
May 20, 2018
…elastic#7056) We can now receive events on the TCP input with a TLS connection, the input uses existing type to make sure we have the same naming convention and code used by outputs that support TLS communication (Elasticsearch and Logstash). The configuration will look like this: ``` host: "localhost:9000" ssl.enabled: true ssl.verification_mode: full # default ssl.supported_protocols: [TLSv1.1] ssl.cipher_suites: [] ssl.certificate_authorities: ["/etc/cacert"] ssl.certificate: /etc/mycert.crt ssl.key: /etc/mycert.key ssl.client_authentication: required ``` One added configuration is `client_authentication`, this option is only used in the context of server and define how we will force the authentification, it support the three following options: - `required`: Assume that the client will provide a certificate and we will verify it. (default) - `optional`: If a certificate is given by the client. - `none`: We don't validate client certificate. *Note: This commit contains a script to generate certs from a self signed CA. Fixes: elastic#6873
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current implementation of the TCP input only supports plain text connection; we should add support For TLS. I think we might be able to reuse some of the helpers method in the shared TLS config options used by the outputs. This work is linked to #6079
The text was updated successfully, but these errors were encountered: