Siemens LOGO! SSL/TLS Protocol Error in Chrome and Edge: Fix

1. Problem Summary

Siemens LOGO! 8 logic modules (order code family 6ED1052) expose a TLS-protected web server on the Ethernet port for status display, variable monitoring, and remote parameter editing. After Microsoft Edge and Google Chrome enabled post-quantum key agreement for TLS 1.3 (Chromium 124, April 2024), operators began receiving an SSL protocol error (browser message ERR_SSL_PROTOCOL_ERROR, "This site can't provide a secure connection") when navigating to https://<logo-ip>. The LOGO! closes the TCP socket without producing a ServerHello. The connection succeeds only when the client browser is forced to negotiate a classical X25519 key share. This article documents the cause, the client-side workarounds, the Siemens firmware remediation path, and a verification procedure.

2. Affected Hardware

Verify the firmware revision on the device by selecting LOGO! → Diagnostics → Product Information → Module Info in LOGO!Soft Comfort, or by inspecting the bottom of the LOGO! web server home page (text Firmware FS:xx). The exact firmware build that includes the TLS ClientHello parser fix should be confirmed against the current Siemens Industry Online Support release notes for LOGO! 8.4.

3. Root Cause: Extended ClientHello and Post-Quantum TLS

TLS 1.3 (RFC 8446) negotiates the cryptographic parameters inside the initial ClientHello message. Starting with the Chromium 124 base (April 2024), Edge and Chrome advertise the X25519Kyber768 hybrid post-quantum key-share by default. The hybrid key-share entry adds approximately 1,100 bytes to the key_share extension, and Chrome also sends larger supported_groups, signature_algorithms, and psk_key_exchange_modes extensions. The total ClientHello length rises from roughly 1,200 bytes (classical X25519) to over 2,500 bytes when the post-quantum extension is sent.

The LOGO! 8 web server parses the ClientHello with a fixed-size scratch buffer. When the parser encounters a record length that exceeds the buffer, the TLS state machine returns TLS_HANDSHAKE_FAILED and the LOGO! closes the TCP socket with a FIN instead of an alert. The browser interprets the abrupt close as a protocol error and surfaces ERR_SSL_PROTOCOL_ERROR. Servers and browsers that fully implement RFC 8446 extension parsing tolerate the extra bytes; the lightweight TLS stack in the LOGO! 8 (mbedTLS / wolfSSL-derived) does not.

4. Symptoms

• Edge or Chrome displays: Can't connect securely to this page. This site can't provide a secure connection. ERR_SSL_PROTOCOL_ERROR.
• Firefox 125+ shows: SSL_ERROR_HANDSHAKE_FAILURE_ALERT when its own (separate) post-quantum rollout is enabled; on default settings it succeeds.
• Internet Explorer 11 connects successfully (classical X25519 key-share, no post-quantum extension).
• curl with OpenSSL 3.2+ connects successfully using --tlsv1.3 --curves X25519 (the OpenSSL client does not advertise X25519Kyber768 by default).
• Wireshark capture of the failed attempt shows a single ClientHello from the browser, no ServerHello, and a FIN from the LOGO! within 50-200 ms.
• PING, ICMP, and TCP port 443 reachability all succeed; the failure is purely TLS-layer.

5. Diagnostic Procedure

1. Confirm the LOGO! web server is reachable at the IP / link layer:

   ping <logo-ip>
   curl -v --tlsv1.3 http://<logo-ip>/

2. Capture the TLS exchange with Wireshark:

   wireshark -k -i <iface> -f "host <logo-ip> and tcp port 443"

   A failing attempt shows one ClientHello from the browser, no ServerHello, no TLS alert, and a FIN from the LOGO! within 50-200 ms.
3. Confirm the client is sending a post-quantum key-share. Wireshark: TLS → Handshake → ClientHello → Extensions → key_share → X25519Kyber768. The entry length is approximately 1,216 bytes.
4. Test with a non-Chromium browser (Firefox ESR 115, Internet Explorer 11). If the page loads in IE 11 but not in Edge, the buffer-overrun theory is confirmed and the LOGO! firmware is the cause.
5. Read the firmware version: LOGO! web server home → bottom of page → "Firmware FS:xx". The release that includes the post-quantum-tolerant TLS parser is part of the current LOGO! 8.4 firmware line; confirm the exact build against the current Siemens Industry Online Support release notes.
6. Optionally, use the Chromium --log-net-log flag to obtain a netlog.json file and inspect SOCKET_BYTES_RECEIVED after the ClientHello; a normal handshake produces more than 4,000 bytes, a failing LOGO! handshake produces 0.

6. Workaround 1 — Disable Post-Quantum Key Agreement via Microsoft Edge Group Policy

The Microsoft Edge policy Enable post-quantum key agreement for TLS controls the feature at machine scope. Setting the policy to 0 disables the X25519Kyber768 hybrid key-share and forces a classical X25519 key-share, which the LOGO! parser accepts.

1. Open the Group Policy Editor (gpedit.msc) on a Windows 10, Windows 11, or Windows Server 2019+ machine.
2. Navigate to Computer Configuration → Administrative Templates → Microsoft Edge.
3. Open the policy Enable post-quantum key agreement for TLS.
4. Set the policy to Disabled. The policy's registry value name is PostQuantumKeyAgreementEnabled.
5. Close and restart Edge. Browse to edge://policy and confirm the policy is listed as PostQuantumKeyAgreementEnabled: 0x0 (Disabled).

Equivalent registry setting for a non-domain machine (run regedit as Administrator):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"PostQuantumKeyAgreementEnabled"=dword:00000000

After applying the policy, Edge must be fully closed (including background processes). edge://restart works in managed environments.

7. Workaround 2 — Disable Post-Quantum Key Agreement in Google Chrome

1. Install the Chrome administrative template (ADMX) from dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip if not already present.
2. Open Group Policy Editor and navigate to Computer Configuration → Administrative Templates → Google Chrome.
3. Open the policy Enable post-quantum key agreement for TLS.
4. Set the policy to Disabled (registry value PostQuantumKeyAgreementEnabled=0 at HKLM\Software\Policies\Google\Chrome).
5. Restart Chrome and verify at chrome://policy.

For a single-user machine where group policy is not available, the Chrome flag chrome://flags/#post-quantum-key-agreement can be set to Disabled. The flag is per-profile, is removed by browser updates, and is not recommended for production HMI stations.

8. Workaround 3 — Network-Level Key-Share Filter (Advanced)

A managed reverse proxy can be inserted between the HMI station and the LOGO! to terminate the TLS connection, re-handshake with the LOGO! using a classical key-share, and serve the LOGO! content back to the browser. Supported proxies include HAProxy 2.9+, nginx 1.25+ with ssl_conf_command Ciphersuites, and Squid 5.8+ with the tls-peer directive. This approach is the most resilient because it requires no configuration on the HMI station, but it is also the most expensive to deploy.

Sample HAProxy 2.9 haproxy.cfg fragment:

frontend ft_logo
    bind *:443 ssl crt /etc/ssl/logo.pem alpn h2,http/1.1
    default_backend bk_logo

backend bk_logo
    server logo1 192.168.0.10:443 ssl verify none sni str(logo.local)
    ssl-default-bind-options ssl-min-ver TLSv1.2
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

The proxy must present a certificate the HMI browser trusts. Use an internal CA (for example the Windows AD CS root) and distribute the root via GPO so the HMI station does not reject the proxy certificate.

9. Workaround 4 — Older Chromium Builds (Temporary Diagnosis Only)

An Edge or Chrome build older than Chromium 124 (for example Edge 123, Chrome 123) does not advertise the X25519Kyber768 hybrid key-share and connects to the LOGO! without any policy change. Use this only as a temporary diagnosis tool to confirm that the buffer-overrun theory matches the symptoms in your environment. Older Chromium builds have unpatched security advisories and must not be used in production.

10. Long-Term Solution: Firmware Update

The correct long-term solution is to update the LOGO! 8 firmware to a release that includes a TLS ClientHello parser capable of handling the post-quantum key-share. The exact firmware build that includes the fix is part of the current LOGO! 8.4 release line; consult the latest Siemens Industry Online Support release notes for the precise version string. As of the LOGO! 8.4 GA, all builds in this release line are designed to parse the enlarged ClientHello correctly.

Update procedure:

1. Open LOGO!Soft Comfort V8.4.0 (or the latest service pack) on the engineering workstation.
2. Connect to the LOGO! via Ethernet (Tools → Transfer → PC ↔ LOGO!).
3. Select Tools → Firmware Update. The available target firmware is filtered by module type and hardware revision; the LOGO! 8.4 release line is offered for every LOGO! 8 BM (6ED1052-1xx08-0BAx) and every LOGO! 8.3 / 8.4 BM (6ED1052-2xx08-0BAx).
4. Confirm the dialog. The LOGO! reboots twice and is offline for approximately 90 seconds.
5. Verify the post-update version at Module Info; the FS state should be the latest published in the Siemens release notes.
6. Test the connection in Edge with the post-quantum feature re-enabled. The page must load successfully.

After the firmware update, revert the Edge / Chrome PostQuantumKeyAgreementEnabled policy to Not configured (or Enabled) to restore post-quantum protection for the rest of the network.

11. Verification Procedure

1. Open Edge with the post-quantum policy re-enabled (or removed). Navigate to https://<logo-ip>.
2. The page must load without ERR_SSL_PROTOCOL_ERROR. The browser address bar shows a padlock. The certificate chain validates.
3. Wireshark capture confirms a complete TLS 1.3 handshake:
   • Client → ClientHello (X25519Kyber768 if post-quantum is enabled, classical X25519 if disabled)
   • LOGO! → ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished
   • Client → Finished + HTTP GET
4. Verify on the LOGO! page footer: Firmware FS: matches the latest published in the Siemens release notes.
5. Roll the Edge policy back to Not configured and re-test. The connection must remain successful with the firmware fix in place; if it does not, the installed firmware does not include the TLS parser fix and a later version is required.
6. From a Linux engineering workstation, run openssl s_client -connect <logo-ip>:443 -tls1_3 -groups X25519MLKEM768. The handshake must complete and return the LOGO! certificate chain.

12. Troubleshooting Matrix

13. Field Commissioning Checklist

• Document the LOGO! 6ED1052 part number, hardware revision (FS:xx), and firmware version before any change.
• Capture a Wireshark trace of the failing TLS handshake; store it with the maintenance log.
• Decide the deployment scope of the PostQuantumKeyAgreementEnabled=0 policy: lock down only the HMI OU; leave the rest of the network on the default (post-quantum enabled).
• Schedule a firmware update during the next planned downtime; the LOGO! is offline for about 90 seconds.
• After the firmware update, roll the policy back to Not configured and re-test from the HMI station.
• Add the LOGO! certificate to the HMI browser's trusted root if a customer CA is in use; otherwise accept the self-signed cert warning or upload a customer PEM.
• Repeat the verification steps in Section 11 with both Edge and Chrome and with both post-quantum enabled and disabled, to prove the firmware fix works regardless of client policy.

14. Frequently Asked Questions