Validate S7CommPlus TLS (V2/V3) against real hardware

[gijzelaerr]

Problem

Newer S7-1200/1500 firmware with "secure PG/PC communication" enabled requires TLS. Both thomas-v2 and lircy support TLS connections. We have TLS code on the fix-tls-layering-v2 branch but it has not been validated against real TLS-enabled hardware.

Scope

• Test TLS handshake against a real S7-1500 with secure communication enabled
• Validate V2 (integrity + anti-replay) and V3 (TLS) protocol paths
• Ensure certificate handling works (Siemens uses per-device certs)

Priority

Critical — without TLS, S7CommPlus is unusable on modern firmware configurations.

[tommasofaedo]

TLS validated against real hardware — S7-1200 "G2" FW V4.1 (secure PG/PC comms enabled)

I ran the fix-tls-layering-v2 branch (PR #775) against a real TLS-required S7-1200 (FW V4.1, "Only allow secure PG/PC and HMI communication" enabled). Summary: the TLS transport layer works end-to-end, and the S7CommPlus data layer works over it, with one functional bug in browse() and a few minor issues.

✅ Validated working

Area	Result
TLS 1.3 handshake (MemoryBIO / SSLObject over TPKT-COTP DT)	TLS_AES_256_GCM_SHA384, TLSv1.3
OMS keying material capture (keylog approach)	32 bytes captured — the export_keying_material workaround holds on real hardware
Data framing after CreateObject	ProtocolVersion.V2 over TLS, accepted by the PLC
get_cpu_state()	RUN — repeatable, many EXPLOREs per connection
list_datablocks()	returns Data_block_1 (DB25)
_explore_type_info_container() (large multi-fragment reassembled PDU)	15 type objects
Full symbolic browse (I/Q/M) with correct types	see below

Symbol tree over TLS (with the reconnect fix in the bug section):

IArea.input_1    BOOL    (access_sequence 50.A)
QArea.output_1   BOOL    (51.9)
MArea.merker_1   BOOL    (52.9)
MArea.mtag_byte  BYTE    (52.B)
MArea.mtag_word  WORD    (52.D)
MArea.mtag_dword DWORD   (52.E)
MArea.mtag_bool  BOOL    (52.10)

Types (incl. %MB/%MW/%MD) resolve directly from the type-info container — no oracle/FDICT needed. Cross-checked against TIA Portal.

🐛 Bug: browse() fails on this PLC (RST-after-read not handled)

browse() does list_datablocks() (EXPLORE, ok) → _read_typeinfo_rid() (a symbolic GetMultiVariables read) → _explore_type_info_container() (EXPLORE). The middle step triggers the PLC's TCP RST that read_symbolic()'s own docstring documents:

TCP RST after first I/Q/M read... Workaround: reconnect before each I/Q/M read.

browse() doesn't apply that workaround, so the final EXPLORE runs on a dead socket:

S7ConnectionError('Not connected')
  at _explore_type_info_container -> send_request -> _tls_flush_outgoing -> _iso_conn.send_data

Proven fix direction: reconnecting before the container EXPLORE makes browse() return the full, correct tree above. A robust fix would reconnect around the symbolic reads (native I/Q/M areas need no read at all, so they come through after a single reconnect; per-DB type-info reads would each need a fresh connection on RST-happy firmware).

Related minor issue: connected stays True after the RST (the lib detects it only on the next send), so callers can't guard with if client.connected.

Minor issues

• Misleading warning on a healthy session. CreateObject returns a non-zero value (0x60228000012B0011) on this PLC even though the TLS session is fully functional (get_cpu_state etc. all work). The logged warning "CreateObject returned error … PLC may require TLS (use_tls=True)" is misleading when TLS is already active — worth downgrading or rewording.
• explore_xml() returns None on this PLC (explore_id=0). Non-fatal.
• db_read(25, 0, 2) on the optimized Data_block_1 fails (PLC returned error 0x2FABFC400 → Read returned no data). Optimized DBs need symbolic access; if that's expected, a clearer error would help.

Environment

• S7-1200 "G2", FW V4.1, secure PG/PC comms enabled (plaintext refused).
• Branch fix-tls-layering-v2 @ 755c163, Python 3.12, CPython ssl (TLS 1.3).
• No client cert required (PLC did not send CertificateRequest); CERT_NONE.

---

Happy to send a small PR if useful: reconnect around the symbolic reads in browse() (so it completes on RST-happy firmware like this one), plus downgrading/rewording the misleading CreateObject warning when TLS is already active. I can validate any change on this G2 over TLS. Just say the word and I'll open it against fix-tls-layering-v2.

[tommasofaedo]

Went ahead and opened #801 with the browse() reconnect fix (+ the CreateObject warning downgrade) against fix-tls-layering-v2. Validated live on the same G2 over TLS — browse() now returns the full I/Q/M tree instead of raising Not connected. No rush to merge; happy to adjust to whatever shape you prefer.