Jetty warnings for SslContextfactory indicate risk of MITM?

Setup, Configuration and Use Runtime
1

Being a sucker for clean logfiles, I decided to dive into the source of some warnings that always show up in openhab.log:

[WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@1dc041a0[provider=null,keyStore=null,trustStore=null]
[WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@1dc041a0[provider=null,keyStore=null,trustStore=null]

In my configuration these warnings are generated by two add-ons: http and daikin.

Digging in the source code of Eclipse Jetty, I noticed the following pieces of code in sslContextfactory.java:

/**
 * Construct an instance of SslContextFactory with the default configuration.
 */
protected SslContextFactory()
{
    this(false);
}

/**
 * Construct an instance of SslContextFactory that trusts all certificates
 *
 * @param trustAll whether to blindly trust all certificates
 * @see #setTrustAll(boolean)
 */
public SslContextFactory(boolean trustAll)
{
    setTrustAll(trustAll);
    setExcludeProtocols(DEFAULT_EXCLUDED_PROTOCOLS);
    setExcludeCipherSuites(DEFAULT_EXCLUDED_CIPHER_SUITES);
}

/**
 * @param trustAll True if all certificates should be trusted if there is no KeyStore or TrustStore
 */
public void setTrustAll(boolean trustAll)
{
    _trustAll = trustAll;
    if (trustAll)
        setEndpointIdentificationAlgorithm(null);
}

/**
 * When set to "HTTPS" hostname verification will be enabled.
 * Deployments can be vulnerable to a man-in-the-middle attack if a EndpointIdentificationAlgorithm
 * is not set.
 *
 * @param endpointIdentificationAlgorithm Set the endpointIdentificationAlgorithm
 * @see #setHostnameVerifier(HostnameVerifier)
 */
public void setEndpointIdentificationAlgorithm(String endpointIdentificationAlgorithm)
{
    _endpointIdentificationAlgorithm = endpointIdentificationAlgorithm;
}

protected void checkTrustAll()
{
    if (isTrustAll())
        LOG_CONFIG.warn("Trusting all certificates configured for {}", this);
}

From what I can deduct out of this (and some of the XML-config documentation), it looks like SslContextFactory should be instantiated with true to disable the “trust all” behaviour and use a key store (or call setEndpointIdentificationAlgorithim with non-null parameter).
And because if no EndpointIdentificationAlgorithm is set it could become vulnerable to a man-in-the-middel-attack, I think this should be considered for future releases of the bindings.

Can anyone with (much) more knowledge about Jetty confirm or correct me?

2

Correct. The “default” client used by openHAB doesn’t have “trust all” enabled, add-on developers can chose to create another Jetty client instance that trusts all certificates. Some bindings (e.g. HTTP) use it to overcome issues with self-signed certificates.

1 Like
3

And just to elaborate on what @J-N-K said, if it’s made such that bindings like HTTP cannot support untrusted certificates it will break a lot of people’s systems who use this binding to integrate with servers that are local to their LAN. For example, I use the HTTP binding to control AdAware so I can easily flip off the ad protection if there’s a site I know I want to go to but don’t want to add to the whitelist.

If only trusted certs are allowed that means I’d have to go through the trouble of setting up a CA, importing that CA’s cert into Java’s trust store and then create and deploy certificates to self hosted services. And this is all for non-internet exposed web services where the risk of an adversary-in-the-middle attack is very low (after all, if they are already on your LAN, they have lots of other and better techniques to cause damage and move around).

The HTTP binding does have a per-Thing setting to ignore SSL errors which can be turned off and the binding will only allow connecting to servers with trusted certificates. Definitely disable this when working with externally hosted web servers and if you’ve both the skills and the inclination to establish and install trusted certs on your LAN web services. But a lot of users cannot do this and making it so those users can no longer interact with their self hosted services would be a high price to pay for only a little bit of added security.

2 Likes
4

Thanks both for the explanation, and sorry for the late response but COVID-19 got me…

2 Likes