Add support for eTLS detection

[weddige]

ETSI recently published the TLS 1.3 flavour eTLS: https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf

As eTLS compromises the DH key exchange it would be nice, if sslyze could report if a server supports eTLS.

There are two ways to detect eTLS with pros and cons:

Server certificate eTLS requres the server to include an otherName in the certificate. This is described in section 4.3.3 of ETSI TS 103 523-3.

DH public key Annex A of ETSI TS 103 523-3 describes a variant of eTLS that omits the information in the server certificate. This can be detected, if the public DH key does not change for two distinct connections.

The first solution is easier and provides more information, the second solution is more robust. Ideal would be to implement both.

[nabla-c0d3]

Thanks for the heads up. It seems unlikely to me that this standard will ever get any traction (I can’t imagine any of the major browsers implementing eTLS as they’re 100% against traffic interception) but I will leave this open just in case.

[weddige]

eTLS does not need to be implemented in the browser. From the point of view of the browser eTLS is 100% compatible to TLS 1.3.

But I agree with you to the extent that I don't expect it to be widespread in the near future either. However, it would be nice not to overlook the fact that a server supports eTLS.

[divad]

eTLS is not a 'flavour' of TLS at all, and is snake oil: https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it

[weddige]

and is snake oil

eTLS (or ETS by now) is not snake oil, but pure poison. That's why I want to recognize it in the scan.

[BerndPfe]

The only way to actually detect is the way and how it uses the key exchange. To determine "crippled" kex use, it might be necessary to look at recurring patterns for the EC. While standard TLS 1.3 uses random - and there are really many - initial parameters of a curve (mostly x25519) the eTLS should be "easy-to-recognize" by its recurring certain "selections". (this is the approach to just try some of then known params and to easily find out -> eTLS inspection appliances can decode the handshake and then find out about the key and cipher which is being used for the connection). To mark a server as "eTLS-crippled" finally it is first necessary to perform some statistics of its behaviours. It can NOT be found out by just looking into one connection as such.

[BerndPfe]

Another approach might be to observe a server "avoiding" to use/offer really strongest-possible curves. Or not even offering x25519 along with TLS 1.3. This would look already like a suspicious configuration to me insofar.

[weddige]

The only way to actually detect is the way and how it uses the key exchange.

A detection via behaviour would be of course ideal. However, eTLS is (in its standard implementation, see annex a) indicated in the certificate. This is something that should be also checked and is easy to implement to start with.

Another approach might be to observe a server "avoiding" to use/offer really strongest-possible curves. Or not even offering x25519 along with TLS 1.3. This would look already like a suspicious configuration to me insofar.

This would look suspicious (and maybe noteworthy), but is not connected to eTLS.

[nabla-c0d3]

Are there any servers reachable from the Internet that run eTLS? I could not find one. Otherwise, is there an easy way to run an eTLS server locally?

[weddige]

Unfortunately (or fortunately) I do not know of any. I would also rather expect it in an intranet and therefore not accessible from the internet. But so far I haven't encountered any implementation.

I would suggest to start with the otherName specified in the technical specification. The following code is only intended as an example, but you are welcome to use it:

import cryptography.x509
from cryptography.hazmat.backends import default_backend
import cryptography_vectors


with cryptography_vectors.open_vector_file('x509/custom/san_other_name.pem', 'rb') as f:
    cert = cryptography.x509.load_pem_x509_certificate(f.read(), default_backend())


ets_visibility_information_oid = cryptography.x509.ObjectIdentifier("0.4.0.3523.3.1")


def search_ets_visibility_information(cert):
    """Test a certificate for the CVE-2019-9191 vulnerability."""
    try:
        subject_alt_name = cert.extensions.get_extension_for_oid(
            cryptography.x509.oid.ExtensionOID.SUBJECT_ALTERNATIVE_NAME
        ).value
    except cryptography.x509.ExtensionNotFound:
        return
    for other_name in subject_alt_name.get_values_for_type(cryptography.x509.OtherName):
        if other_name.type_id == ets_visibility_information_oid:
            return other_name


search_ets_visibility_information(cert)

If this is an approach you agree with, I could also write a plugin based on it.

[hb9cwp]

Are there any servers reachable from the Internet that run eTLS? I could not find one. Otherwise, is there an easy way to run an eTLS server locally?

ETSI Tech Committee CYBER publishes kind of "reference implementations" for demo purposes with patched versions of OpenSSL and Apache that provide the toxic extensions for the Transport Layer Middlebox Security Protocol (TLMSP), as required by Extra Terrible Security (ETS, formerly eTLS) which does not provide per-session Forward Secrecy:

see repo "TS 103 523 MSP" https://forge.etsi.org/rep/cyber/103523_MSP for example in the subtrees "ETS" and "TLMSP":

MSP-httpd demonstrator
https://forge.etsi.org/rep/cyber/103523_MSP/tlmsp/CYBER.MSP-httpd This repository contains a HTTP server demonstrator for the mcTLS protocol. The demonstrator is implemented extending the Apache HTTP server.

TLMSP Apache Httpd https://forge.etsi.org/rep/cyber/103523_MSP/tlmsp/tlmsp-apache-httpd Apache HTTPD modified to support TLMSP (ETSI TS 103 523-2)

OpenSSL modified to support TLMSP (ETSI TS 103 523-2) https://forge.etsi.org/rep/cyber/103523_MSP/tlmsp/tlmsp-openssl https://forge.etsi.org/rep/cyber/103523_MSP/tlmsp/MSP-OpenSSL/wikis/home