Incorrect error message

[Glenn Glazer]

Hi, all.

Many thanks in advance for your time and consideration of the following issue.

I would file a Jira ticket, but when I click create, it tells me I'm not logged and to refresh the window, which doesn't work. 

Bug summary: cassandra-driver falsely reports version error when it can't connect.

To the problem at hand:

We are testing a managed Cassandra instance inside of our Azure tenant. The test client host and all of the real clients are on the same subnet.

For this, the server version is [cqlsh 6.2.1 | Cassandra 4.0.12 | CQL spec 3.4.5 | Native protocol v5] and the driver version is 3.29.3.

Executing the following code:

auth_provider = PlainTextAuthProvider(
                username=CASSANDRA_USERNAME,
                password=CASSANDRA_PASSWORD
            )

cluster = Cluster(
                contact_points=[CASSANDRA_IP],
                port=CASSANDRA_PORT,
                auth_provider=auth_provider,
                protocol_version=5
            )
            session = cluster.connect()

returned the error:

cassandra.cluster.NoHostAvailable: ('Unable to connect to any servers', {'10.20.6.92:9042': ProtocolError('This version of the driver does not support protocol version 21')}

Which is absolutely not the case. What the problem turned out to be is that we needed to add:

ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
ssl_context.check_hostname = False
ssl_context.verify_mode = ssl.CERT_NONE

and later adding  ssl_context=ssl_context to the Cluster kwargs. Then everything works fine without error. The problem had nothing to do with protocol versions at all.

Best,

Glenn

[Bret McGuire]

   Thanks for the question Glenn!

   So what's happening here is that Cassandra is configured to use SSL in it's connections while the Python driver is _not_ configured to use SSL (or at least wasn't until you added the SSLContext code snippet).  So when the driver receives communication from the server it tries to decode the bytes it receives just like it would decode any message normally; it doesn't try to decrypt it first.  That means that we're trying to decode pure (random) ciphertext as a Cassandra message... which will absolutely fail.

   I note that that's consistent with the error message regarding the drivers lack of support for protocol version 21; there is no protocol version 21 in either OSS Cassandra or DataStax DSE.  That value is coming from an interpretation of random ciphertext as the part of a message frame describing the protocol version.

   We see this kind of error frequently in cases like those described above (where one side is speaking SSL but the other side is not).  Given all of that I don't know that there's anything to actually fix here, but if somebody wants to correct me I'm happy to listen to other ideas!

   Thanks again!

   - Bret -

[Glenn Glazer]

Hi, Bret!

Thanks for getting back to me, and as a side note, I really appreciate the positive tone in your reply. 

So, clearly, it isn't possible in the general case to determine if text is encrypted or not. That would, after all, be a step towards breaking the encryption itself. However, there are approaches we could use.

The first one is to disambiguate the port numbers. Just as 7000 and 7001 are split between plaintext and SSL, we could split the native protocol port in two, perhaps add a 9043 to the existing 9042. Requests over 9042 would come back as plaintext and over 9043 as ciphertext (or vice-versa) and the client should not decrypt the first and do decrypt the second. This would eliminate the "

Another is that SSL can't happen without the TLS handshake. So, if a client starts with that, send them back encrypted data. If they don't, don't. On the client side if the SSLContext is there, decrypt, if not, don't. In fac 

A third option is letting the humans have some control if they know what is going on. Implement an override option to the Context()  constructor which overrides whatever the client thinks it is supposed to and sets decryption to always (True), never (False) and None defaulting to the current behavior.

A fourth option is for the client to have some way to ask the server if it is set up for SSL or not. This would lead to creating the SSLContext in an if clause and then carrying on with the constructor.

Something I wouldn't do is try a heuristic based on an entropy analysis of the incoming message. It is true that encrypted data is generally more random than plaintext, but this kind of analysis can be computationally expensive and it's not foolproof.

Best,

Glenn

--

[Glenn Glazer]

Apologies, in the port paragraph, 'This would eliminate the "' should be 'This would eliminate the "we don't agree on protocol problem"'.

Best,

Glenn

--