Skip to content
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

Improved diagnostics for TLS trust failures #48911

Merged
merged 7 commits into from
Nov 20, 2019

Conversation

tvernum
Copy link
Contributor

@tvernum tvernum commented Nov 8, 2019

  • Improves HTTP client hostname verification failure messages
  • Adds "DiagnosticTrustManager" which logs certificate information
    when trust cannot be established (hostname failure, CA path failure,
    etc)

These diagnostic messages are designed so that many common TLS
problems can be diagnosed based solely (or primarily) on the
elasticsearch logs.

- Improves HTTP client hostname verification failure messages
- Adds "DiagnosticTrustManager" which logs certificate information
  when trust cannot be established (hostname failure, CA path failure,
  etc)

These diagnostic messages are designed so that many common TLS
problems can be diagnosed based solely (or primarily) on the
elasticsearch logs.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (:Security/Network)

Copy link
Member

@jkakavas jkakavas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will make both our and our users lifes so much easier 🙏 I left some comments and suggestions

}
final List<String> description = new ArrayList<>(names.size());
for (List<?> pair : names) {
if (pair == null || pair.size() != 2) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could this be changed to something like :

if ( pair != null && pair.size() == 2 && pair.get(0) instanceof Integer && pair.get(1) instanceof String) {
    final int type = ((Integer) pair.get(0)).intValue();
    final String name = (String) pair.get(1);
    if ( type == 2 ) {
          description.add("DNS:" + name);
    else if ( type == 7 ) {
        description.add("IP:" + name);
    }
}

it seems more concise, but just a suggestion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I replaced the inner-switch with if/else but I found the merged outer-if to be too complex to reason about, so I left the existing version.

final StringBuilder message = new StringBuilder();
final CertificateTrust trust = isTrusted(trustedIssuers, certificate);
message.append("self-issued [").append(certificate.getIssuerX500Principal().getName()).append("] and is ")
.append(trust.isTrusted() ? "trusted" : "not trusted")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the

the certificate is signed by (subject [CN=Test CA 1] fingerprint [A] {trusted issuer}) which is self-issued [CN=Test CA 1] and is trusted in this ssl context ([xpack.security.authc.realms.saml.saml1.ssl]) using certificates with fingerprint [X,Y,Z] but the same public key

somewhat hard to unpack. Could we add a sentence to the effect of "We trust the public key but not the certificate" ? I don't have a good suggestion atm.. :/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed it to

the certificate is signed by (subject [CN=Test CA 1] fingerprint [2b7b0416391bdf86502505c23149022d2213dadc] {trusted issuer}) which is self-issued; the [CN=Test CA 1] certificate is trusted in this ssl context ([xpack.security.authc.realms.saml.saml1.ssl]) because we trust a certificate with fingerprint [1f8ac10f23c5b5bc1167bda84b833e5c057a77d2] for the same public key

final Supplier<String> contextName = () -> {
final List<String> names = sslConfigurations.entrySet().stream()
.filter(e -> e.getValue().equals(configuration))
.limit(2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this because we don't care if we have more than 2 here as the name would be the same ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, a (possibly silly) micro-optimisation because the only cases we care about are 0/1/many

Copy link
Member

@jkakavas jkakavas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a typo I noticed in a string, LGTM

Co-Authored-By: Ioannis Kakavas <ikakavas@protonmail.com>
@tvernum
Copy link
Contributor Author

tvernum commented Nov 20, 2019

I realised I forgot to document the new setting. I will add that before merging.

@tvernum
Copy link
Contributor Author

tvernum commented Nov 20, 2019

@jkakavas Can you review the docs change please?

Copy link
Member

@jkakavas jkakavas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tvernum tvernum merged commit bbaa1f5 into elastic:master Nov 20, 2019
tvernum added a commit to tvernum/elasticsearch that referenced this pull request Nov 26, 2019
- Improves HTTP client hostname verification failure messages
- Adds "DiagnosticTrustManager" which logs certificate information
  when trust cannot be established (hostname failure, CA path failure,
  etc)

These diagnostic messages are designed so that many common TLS
problems can be diagnosed based solely (or primarily) on the
elasticsearch logs.

These diagnostics can be disabled by setting

     xpack.security.ssl.diagnose.trust: false

Backport of: elastic#48911
tvernum added a commit that referenced this pull request Nov 29, 2019
- Improves HTTP client hostname verification failure messages
- Adds "DiagnosticTrustManager" which logs certificate information
  when trust cannot be established (hostname failure, CA path failure,
  etc)

These diagnostic messages are designed so that many common TLS
problems can be diagnosed based solely (or primarily) on the
elasticsearch logs.

These diagnostics can be disabled by setting

     xpack.security.ssl.diagnose.trust: false

Backport of: #48911
@jakelandis jakelandis removed the v8.0.0 label Jul 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants