[CASSANDRA-17367] sstableloader ignores streaming encryption settings

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 4.0.4, 4.1-alpha1, 4.1
• Component/s: Tool/bulk load
• Bug Category: Correctness - Recoverable Corruption / Loss
• Severity: Normal
• Complexity: Normal
• Discovered By: User Report
• Platform: All
• Since Version: 4.0.0

Source Control Link

https://github.com/apache/cassandra/commit/0e249fd15ee209594e6d85db7e81a19c67d6ad6f

Test and Documentation Plan

run CI

• Assignee: Dmitry Potepalov
• Reporter: Dmitry Potepalov

Authors

Dmitry Potepalov

Reviewers

Berenguer Blasi, Brandon Williams

• Created: 09/Feb/22 10:34
• Updated: 27/May/22 19:25
• Resolved: 02/Mar/22 14:02

Description

Reproducible in Cassandra 4.x. If one configures encryption for streaming in config yaml fed to sstableloader like this

server_encryption_options:
    internode_encryption: all
    keystore: sstableloader.keystore.p12
    keystore_password: changeit
    truststore: sstableloader.truststore.jks
    truststore_password: changeit

then sstableloader should perform an SSL handshake on the streaming connections and encrypt the payload. But this does not happen. Judging by the TCPdump of the outgoing traffic on the internode port, sstableloader sends plaintext traffic. This is the TCP payload of the first packet that sstableloader sends after establishing TCP connection:

ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0

The first 4 bytes look like Cassandra protocol magic, not like a client hello.

I've discovered the issue while trying to migrate some data to a Cassandra 4 listening on the legacy ssl storage port (therefore, accepting only encrypted connections on that port). Streaming phase of the migration failed with a "connection closed" error, which hints that the connection was closed server-side.