Ahead of the coming release, four connection defaults in the Java drivers change from "unprotected unless you asked otherwise" to "protected unless you say otherwise". Each was a case where the driver either did less than its own configuration claimed, or offered no way to ask for more. They are on develop now.
This is a notice rather than a question: the release is close and these are security defaults, so they are going in. Every one of them has a named opt-out, so nothing becomes unreachable - a deployment that needs the old behaviour can have it by setting one parameter. What changes, and what to set if the old behaviour is wanted: 1. TLS transport - the server certificate is now checked against the host "ignore-common-name" was declared, documented and defaulted to false, and nothing read it. So the check never happened: with "verify-ssl" on, a certificate from a trusted issuer was accepted for any host at all, which is what an interposed machine needs. It is now honoured. A connection to a device whose certificate names something other than the address it answers on will now fail. Opt out: ignore-common-name=true (warns when set). New: trust-store-file / trust-store-password / trust-store-type, so a device carrying its own certificate can be trusted without turning verification off wholesale - previously the only route past a private CA was verify-ssl=false, which disables the chain check and the host check together. 2. ctrlX driver - stops trusting the certificate shipped inside the driver The driver trusted exactly one certificate, the Bosch factory default, bundled in its own jar - and not in addition to the platform authorities but instead of them. Anything holding that certificate and its key was trusted, for any host, and the connection's username and password travel over that channel. Because it was the only anchor, a device with a properly issued certificate could not be reached at all, which is presumably why the trust being wrong was never noticed. It also asked for a context named "SSL" rather than "TLS", and used a no-op hostname verifier. Connections to a device still on its factory certificate will now fail. Opt out: allow-factory-default-certificate=true (warns when set). New: server-certificate-file, trust-store-file / -password / -type, ignore-common-name - named as in the OPC UA driver and the TLS transport. 3. OPC UA driver - "security-policy" now defaults to Basic256Sha256, not NONE NONE signs nothing, encrypts nothing and authenticates nobody. This one has a second half worth stating, because the default alone would have achieved nothing. A protected channel needs the server's certificate before the channel opens. The discovery phase that would fetch it runs unprotected of necessity - and the driver then carried straight on to establish the session on that unprotected channel while selecting an endpoint by the configured policy. A connection asking for Basic256Sha256 got a session with neither signing nor encryption, and nothing reported it. That silent downgrade is what actually made the old default hard to escape, and it is now refused. A certificate learned from the peer it is meant to authenticate establishes nothing, so discovery cannot bootstrap this. The certificate has to be known in advance. A connection naming no certificate will now fail. Set: server-certificate-file, or trust-store-file; or discovery=false where the endpoint needs none; or security-policy=NONE to accept an unprotected channel. Also: insecure-certificate-verification=true accepts whatever the server presents, for a lab. 4. OPC UA driver - a password is no longer sent over an unprotected channel Over a channel that neither signs nor encrypts, the password is readable by anything on the path, and unlike a value it stays useful long after it is read. Opt out: allow-insecure-credentials=true (warns when set). Two related corrections that change behaviour without changing a default: - Endpoint selection required an endpoint to match the requested policy OR the requested message security, then took the lowest security level on offer. A server publishing a wide-open endpoint beside a protected one was therefore usually reached over the wide-open one. It now requires both to match and takes the strongest, preferring one whose user token policy protects the token. - The server's certificate was validated with checkClientTrusted, which asks whether a certificate is good for authenticating a client. Only the leaf was passed, so a chain reaching an anchor through an intermediate could not validate however trustworthy it was; and an unreadable certificate came back as null rather than failing. All three are fixed. A known limitation, unchanged by this work: With a protected policy and no "key-store-file", the driver generates a throwaway self-signed client certificate. That is harmless against a server which does not authenticate its clients and useless against one that does - and after change 3 it is where every connection without a key store lands. It is documented in the release notes rather than changed: what it should do instead is a design decision, not a defect with an obvious fix. One further change outside these three drivers, also peer-observable: The IEC 60870-5-104 driver now derives its S-format acknowledgements from the send sequence number of the frames it received, counted modulo 2^15 and carried in the upper fifteen bits of the control field, as the standard requires. It previously sent the received frame's receive sequence number plus one - the station reporting how much of our traffic it had taken in, which says nothing about how far we had read. A station that checks acknowledgements will see different, correct values. The frame format itself is unchanged and all 128 APDUs in the parser testsuite still round-trip byte for byte. Full detail per change is in RELEASE_NOTES under "Incompatible changes".
